Archive for the ‘java’ Category

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

Tuesday, June 2nd, 2009

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

Cross platform exploit brought to you by Java

Wednesday, May 20th, 2009

From Slashdot:

‘This means you can write a 100% reliable exploit in pure Java. This exploit will work on all the platforms, all the architectures and all the browsers,’
And the Java critics said total platform independence was impossible!

(yes I know that this is only affecting OS X Java, the quote was just too good to waste).

Speeding up hibernate startup time using terracotta?

Friday, September 26th, 2008

I’m in the middle of creating a conversion utility from one database to another, and I have to reinitialize my Hibernate configuration quite often. When you have a couple of hundred entities that need configuring, starting up Hibernate can take a long time. My initial thought was to serialize the SessionFactory and deserialize it upon each startup.

I didn’t try this yet, but something tells me this won’t work. Call it a nagging feeling. However, it should be possible to run the SessionFactory in a Terracotta cluster and keep that server alive, and connect my conversion utility on startup with the Terracotta cluster. This should make startup times a snap.

Mind you: this is just a thought experiment. If someone has done this before, leave a note!

Eclipse + OS X = unhappy

Thursday, April 3rd, 2008

Eclipse and OS X (10.4 Tiger) makes me unhappy. Today I witnessed something really stupid. I have allocated 768MB for Eclipse (eclipse.ini) and to my amazement, Eclipse was beach balling (being unresponsive for you non-OS X-ers). This beach balling was due to the simple fact that the Java garbage collector was reading in pages from the swap file in order to throw everything away. Woohoo! This took of course over 2 minutes.

I doubt that Java will ever become a consumer technology with this kind of shit.

Why exception messages suck

Thursday, December 13th, 2007

One of my pet peeves is that library builders take special care to check for errors or exception conditions, but fail miserably to communicate what is wrong and how to fix it. The case today: json-lib (2.1).

I’m trying to use it to serialize a bean to JSON format and to compare it to a JSON serialized bean (it is easier to check text instead of the debugger trees). But the json-lib tells me that there is a cycle in the bean.

Caused by: net.sf.json.JSONException: There is a cycle in the hierarchy!
	at net.sf.json.util.CycleDetectionStrategy$StrictCycleDetectionStrategy.handleRepeatedReferenceAsObject(CycleDetectionStrategy.java:73)
	at net.sf.json.JSONObject._fromBean(JSONObject.java:658)
	at net.sf.json.JSONObject.fromObject(JSONObject.java:182)
	at net.sf.json.JSONObject._processValue(JSONObject.java:2426)
	at net.sf.json.JSONObject._setInternal(JSONObject.java:2447)
	at net.sf.json.JSONObject.setValue(JSONObject.java:1189)
	at net.sf.json.JSONObject._fromBean(JSONObject.java:725)
	at net.sf.json.JSONObject.fromObject(JSONObject.java:182)
	at net.sf.json.JSONObject._processValue(JSONObject.java:2426)
	at net.sf.json.JSONObject._setInternal(JSONObject.java:2447)
	at net.sf.json.JSONObject.setValue(JSONObject.java:1189)
	at net.sf.json.JSONObject._fromBean(JSONObject.java:725)
	at net.sf.json.JSONObject.fromObject(JSONObject.java:182)
	at net.sf.json.JSONObject._processValue(JSONObject.java:2426)
	at net.sf.json.JSONObject._setInternal(JSONObject.java:2447)
	at net.sf.json.JSONObject.setValue(JSONObject.java:1189)
	at net.sf.json.JSONObject._fromBean(JSONObject.java:725)
	at net.sf.json.JSONObject.fromObject(JSONObject.java:182)
	at net.sf.json.JSONObject._processValue(JSONObject.java:2426)
	at net.sf.json.JSONObject._setInternal(JSONObject.java:2447)
	at net.sf.json.JSONObject.setValue(JSONObject.java:1189)
	at net.sf.json.JSONObject._fromBean(JSONObject.java:725)
	at net.sf.json.JSONObject.fromObject(JSONObject.java:182)
	at net.sf.json.JSONObject.fromObject(JSONObject.java:145)

Very informative stack trace indeed.