uPortal 3 uses the new (JDK5+) Java scripting APIs via Cernunnos, the scripting language used in the data import/export scripts. This has been working great and is a huge step forward for the uPortal project. I've been building uPortal 3 on my Apple computer since development started and it has been working great.
Until I installed the Apple JDK6 Update.
Now I've been itching for JDK6 on my Mac for a while. I have little interest in the OS integration Apple does with the JDKs since I don't use it to develop code for OS X. I develop server-side web applications, all I need is the base JDK. So finally, around a year after Sun released JDK6, Apple gets their version out. I eagerly install the update, Eclipse still works, Tomcat starts and uP3 runs, we're all happy.
A few days later I grab the latest updates from the uPortal trunk and go to re-build and re-initialize the portal's database. It fails importing the data .... didn't this just work at the office? Didn't this just work here a few days ago?
Wondering if this is a new issue or not I grab the 3.0.0 release package and run initportal, it fails there too! All my attempts to run any of the Cernunnos scripts fail with the following stack trace:
So the next question is what the heck does uP3 depend on that is compiled to the JDK6 .class file format? Of course the UnsupportedClassVersionError is useless since it doesn't tell you what class file is bad or where it is loading it from!
The next step is adding the -verbose:class option to the Ant script that runs the Cernunnos scripts. This makes the JVM print out each class and the file it is loaded from, thats a lot of text but the only way to track this down. Re-running the script with the verbose option yields the culprit:
apple.applescript.AppleScriptEngineFactory
What the heck? Apple includes a scripting library for JDK6 only in the classpath for JDK5? They do this by default after installing their JDK6 update? This is not cool. The class is in the /System/Library/Java/Extensions/AppleScriptEngine.jar file which is added in the system's JDK extensions folder, apparently ALL Apple JDKs load ALL the jars from this directory. That makes it a bad place for a .jar that isn't compatible with all the JDKs on the system.
The solution I ended up coming up with is to move the AppleScriptEngine.jar into the JDK6 extensions directory:
This move fixed the problem and all is happy (mostly) in the land of Java on the Mac.
No comments:
Post a Comment