OpenJDK weirdness on OSX Leopard

Posted by Marco Dinacci on 03 Oct 2012 0 comments

This post is to document a couple of issues encountered while deploying an OpenJDK 7 based app on OSX Leopard.
The first is a JVM crash caused by a supposedly closed bug in hotspot.
The crash happens when the sun.nio.cs.StreamDecoder.read is compiled at run-time, normally a fraction of a second after the application launches.
The only workaround I've found is to launch your application with the following line:

-XX:CompileCommand=exclude,sun/nio/cs/StreamDecoder,read

which tells hotspot not to compile that method.

The second issue is a NullPointerException in sun.net.www.ParseUtil.encodePath. Here's a partial stacktrace:

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
  at sun.net.www.ParseUtil.encodePath(ParseUtil.java:105)
  at sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:734)
  at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:819)
  at sun.misc.URLClassPath.getResource(URLClassPath.java:195)
  at java.net.URLClassLoader$1.run(URLClassLoader.java:358)
  at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
  at java.security.AccessController.doPrivileged(Native Method)
  at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
  at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
  at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
  at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
  ...

The line causing the NPE is:

char[] retCC = new char[path.length() * 2 + 16];

which means that somehow the path is null. As bizarre as it may seems this can be fixed using these two JVM options:

-XX:-UseLoopPredicate -XX:-LoopLimitCheck

which you may remember it was used to fix a nasty problem in hotspot in the first public release of Java 7.

Marco