[Mulgara-dev] Java 6 failures and errors

[Paul Gearon]

While the core Mulgara code works fine (except for a trivial issue in
the SPI), I'm still having some issues with these resolvers.  The
errors have been quite strange, so I'm appealing for help, if anyone
has the time.

The first problem is in the Jar resolver.  These errors are caused
when the resolver attempts to call java.net.URL.openStream() on a jar
file URL.  It works the first time this is called, but on subsequent
calls on that URL (not the same URL instance, but a separated object
constructed from the same string).  The exception that comes up is:
message="zip file closed"
java.lang.IllegalStateException: zip file closed
  at java.util.zip.ZipFile.ensureOpen(ZipFile.java:403)
  at java.util.zip.ZipFile.getEntry(ZipFile.java:148)
  at java.util.jar.JarFile.getEntry(JarFile.java:206)
  at sun.net.www.protocol.jar.URLJarFile.getEntry(URLJarFile.java:107)
  at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:114)
  at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:130)
  at java.net.URL.openStream(URL.java:1009)
  at org.mulgara.resolver.jar.JarContent.newInputStream(JarContent.java:146)
...

Notice that this is in the openStream method. In other words, there is
no opportunity for client code to "open" anything beforehand. I am
wondering if there is come kind of internal cache that was introduced
in Java 6, and the cached connection has already been opened and
closed again, but I've yet to prove this theory. The Javadoc
explicitly says that there is a new connection object every time - but
the javadoc hasn't changed between Javas 5 and 6, while the behavior
has, so I don't necessarily trust the javadoc.


The second problem is in the HTTP resolver.  The problem comes up
while using the Apache commons-httpclient library.  Since we were on
an old version of the library, I thought this was a good excuse to
update to the latest, and see if this fixed it.  I'm pleased to say
the update went well, but the problem still exists.

The problems all occur when testing HTTPS connections.  The first
exception is caused by an AccessControlException:
java.security.AccessControlException: access denied
(java.lang.RuntimePermission loadLibrary.keychain)
  at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
  at java.security.AccessController.checkPermission(AccessController.java:546)
  at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
  at java.lang.SecurityManager.checkLink(SecurityManager.java:818)
  at java.lang.Runtime.loadLibrary0(Runtime.java:817)
  at java.lang.System.loadLibrary(System.java:1030)
  at com.apple.crypto.provider.HmacCore.<clinit>(HmacCore.java:26)

This happens at the bottom of a deep stack of method calls in the
com.sun.net.ssl.internal.ssl package, which attempted to load
javax.crypto.Mac (the reason for the System.loadLibrary is because
it's using reflection to load up a module).  Of course, this is all
working fine in Java 5.

A similar error occurs in another test when the system complains:
message="Could not initialize class com.apple.crypto.provider.HmacMD5"
java.lang.NoClassDefFoundError: Could not initialize class
com.apple.crypto.provider.HmacMD5

Again, at the bottom of a similar stack in
com.sun.net.ssl.internal.ssl and javax.crypto.Mac.

The strange thing here, is that this class DOES exist, and it's in the
same location as it was for Java 5!  That is:
$JAVA_HOME/lib/etc/apple_provider.jar

Complete details are available to anyone who cares to run the tests on Java 6.

Any suggestions?

Regards,
Paul Gearon