EHCache and Quartz phone home during startup

One might call EHCache (the Java caching library everybody loves) ET-Cache, since it keeps phoning home during startup. While probably just implemented as a usability feature, I find it quite nefarious, especially since Quartz (the job queuing library everybody loves) does *exactly* the same.

The culprit lies in net.sf.ehcache.util.UpdateChecker and org.quartz.util.UpdateChecker.

Information sent to Terracotta HQ include:

  • a client ID taken from your local IP
  • os.name
  • java.vm.name
  • java.version
  • os.arch
  • QuartzVersion
  • EhCache version
  • something about source
  • uptime-secs
  • patch level from Quartz/EhCache

Needless to say, this is something that should not be enabled by default, and only with a big opt-in questionnaire… This also sparks the question if the cache doesn’t send *more* information home than just the update information? It is after all a product designed to send information across the network—what is one extra node more in the grand scheme of things? Has anybody audited the code for nefarious code?

In any case: to disable phoning home everybody should start their applications with the following command line parameters:

  • -Dnet.sf.ehcache.skipUpdateCheck=true
  • -Dorg.terracotta.quartz.skipUpdateCheck=true

Or you can configure it in your ehcache.xml according to the user manual. Quartz is similarly configurable in the quartz.properties.

According to Alex Miller, a former Terracotta employee, it is not evil and a price we need to pay to use open source software.

I disagree strongly: this undermines the premise of trustworthy open source. The download page doesn’t mention the phoning home, neither does the announcement of ehcache 2.2 (last july), it is summarily mentioned in the configuration part of the manual, which you typically don’t read when you just upgrade your dependency to the latest version and see that everything still works as usual. The same goes for Quartz: it was apparently added in quartz 1.7.3, but no mention of this in the release notes. Neither of the possibility to disable phoning home which was added in quartz 1.8.

In my opinion, this is unacceptable behavior for any open source product, which severely undermines the trust we spent building in the last couple of years making open source a viable alternative to closed software.

SHAME ON YOU TERRACOTTA!

Oracle tells JCP EC to fuck off and bow to its will

In the published minutes of the JCP EC meeting in Bonn last October, the complete (might I say epic) failure of Oracle’s Java Community stewardship becomes visible (emphasis mine):

Doug asked Oracle to acknowledge that it was asking the ECs to condone breaking the JSPA rules. He said that if he was put in a position where he had to condone breaking the rules he would have to resign. Ken said that he understood, and would regret it if Doug resigned, but pointed out the importance of allowing the conversation to go forward.

Doug Lea resigned from the JCP EC on 22 October 2010.

How is that for being positive and constructive?

Atlassian Ultimate Wallboard competition comes to an end

Last month we submitted an internal project at Topicus into an international competition hosted by Atlassian concerning so called Wallboards. Wallboards are (agile) information radiators which show stuff like build status, sprint planning and other interesting metrics. While we didn’t win the competition (congratulations Vodafone Web Team!), we are glad to have participated in this competition!

Our board was heavily inspired by the Panic Status Board, and we took their premise and went a bit overboard. Our dashboard (dubbed “Topicus Board”) shows our project status: production server status, average request times, number of concurrent users, requests per minute, Hudson build status, number of unit tests, server uptime, deployed application versions, a list of servers with status indication (up/down), etc. Added to that we show departure times of trains of our local train station (the Topicus offices are next to the Deventer central station), SVN commits and mantis issues, Google calendar events and the local weather.

We built our board with Java using Apache Wicket (raise your hand if you thought we’d use something else ;-) , jquery (wiquery), CSS3 and HTML5. The board animates the living daylights out of our Dell workstation (Intel embedded graphics and Linux drivers don’t work too great). The code is open source (GPL) and available from https://github.com/dashorst/dashboard.

When we started with the project Atlassian hosted a contest for the ultimate wallboard, so we figured to enter the competition, and get ourselves a nice deadline. The competition closed November 24th. And today the results finally came in. Unfortunately our wallboard didn’t take the grand prize for being the ultimate wallboard, but we did manage to get a honorable mention:

This wallboard also boasts a very clean and simple design with sexy animations. Products stats, builds and issue details are complimented by local railway schedules, twitter, weather, and google calendars — including birthdays and beer time!

Judge Dick Wall added:

Features like tracking transport delays, the excellent two speed ticker at the bottom, and the polish of the CSS animations all stand out in this demo.

We thank Atlassian for hosting this competition and hope they’ll host one next year.

OS X and Java developer sources

With the Java 6 update 22, Apple not only set the internets on fire regarding their deprecation of Java, they also made it very hard for the core Java users on their platform to actually use the old ball and chain: developers, developers, developers.

It is quite hard to discover where the Apple gods decided to land the new goods, so I figured to write everything up in one blog post for posterity (and my own memory—having to go on another google hunt to do these tasks again would kill me).

First you need to download the developer packages from the connect.apple.com website. This requires a free account so just register and promise your first born (as I understand it, no waving of dead chickens is necessary).

You can download the developer package from this location: Apple Java downloads

Install the package and start up your favorite IDE. Now find the settings where you can tell the IDE where to find the Java sources and paste in the following for Java 6 Update 22:

/Library/Java/JavaVirtualMachines/1.6.0_22-b04-307.jdk/Contents/Home/src.jar

Navigating to that folder using Eclipse is pointless as the .jdk extension signifies a package and Eclipse’s navigator doesn’t allow “Show package contents”.

Eclipse 3.4 with openjdk 6 on OS X 32-bit CoreDuo

With the invaluable help of David Green, I was able to run Eclipse on openjdk 6 on my first gen MacBook Pro (you know, those left behind by Apple, running on a 32 bit CoreDuo processor… good to know that Apple supports the early adapters).

With this script that I adapted from David’s blog I was able to start Eclipse 3.4 (Version: 3.4.2
Build id: M20090211-1700) with Landon Fullers openjdk 6 build:

export JAVA_HOME=/Developer/Java/openjdk6-b16-24_apr_2009-r1
export PATH=$JAVA_HOME/bin:$PATH

java -server -Djava.library.path=$HOME/bin/jnilib -Dswt.library.path=$HOME/bin/jnilib -Xms128m -Xmx768m \
    -XX:MaxPermSize=192m -Dosgi.requiredJavaVersion=1.5 -Dorg.eclipse.swt.internal.carbon.smallFonts \
    -cp /Applications/eclipse/Eclipse.app/Contents/MacOS/../../../plugins/org.eclipse.equinox.launcher_1.0.101.R34x_v20081125.jar \
    org.eclipse.equinox.launcher.Main -os macosx -ws carbon -arch x86 -showsplash \
    -launcher /Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse -name Eclipse \
    --launcher.library /Applications/eclipse/Eclipse.app/Contents/MacOS/../../../plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.101.R34x_v20080731 \
    -startup /Applications/eclipse/Eclipse.app/Contents/MacOS/../../../plugins/org.eclipse.equinox.launcher_1.0.101.R34x_v20081125.jar \
    -launcher /Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse \
    -keyring $HOME.eclipse_keyring -consoleLog -showlocation -vm $JAVA_HOME

The script misses the shebang, since my hosting provider thinks that I’m trying to execute some serverside exploit…
You’ll have to extract a couple of shared libraries that are packaged in your Eclipse distribution:

jar xfv /Applications/eclipse/plugins/org.eclipse.swt.carbon.macosx_3.4.1.v3452b.jar
jar xfv /Applications/eclipse/plugins/org.eclipse.core.filesystem.macosx_*.jar os/macosx/liblocalfile_1_0_0.jnilib

You’ll have to rename all those libraries to give them a *.dylib extension.

Finally I had to point /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home to the openjdk 6 directory:

sudo mv /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home.old
sudo ln -s LOCATION_OF_OPENJDK /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home