Jynx 0.2 contained an ugly workaround for a bug I couldn’t fix for quite a while. The bug can be described as follows: suppose you defined code of a Java class `A` and compiled it dynamically:<\/p>\n
A = JavaCompiler().createClass(\"A\", A_source)<\/pre>\nWhen you attempt to build a subclass<\/p>\n
class B(A): pass<\/pre>\na `NoClassDefFoundError` exception was raised:<\/p>\n
Traceback (most recent call last):\r\n File \"C:\\lang\\Jython\\jcompile.py\", line 185, in <module>\r\n class B(A):pass\r\n at java.lang.ClassLoader.defineClass1(Native Method)\r\n at java.lang.ClassLoader.defineClass(ClassLoader.java:621)\r\n at java.lang.ClassLoader.defineClass(ClassLoader.java:466)\r\n at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)\r\n at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)\r\n at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)\r\n at java.lang.reflect.Method.invoke(Method.java:597)\r\njava.lang.NoClassDefFoundError: org\/python\/core\/PyProxy (wrong name: A)<\/pre>\nIn that case the Jython runtime failed to create a proxy class for `B` while locating `PyProxy` which is a Jython core interface. From the traceback it wasn’t clear how to locate the error and I started to debug into Jython from Netbeans.<\/p>\n
This is what happened: Jynx defines a `ByteClassLoader` class which is custom class loader for dynamic compilation of `A`. When `A` is loaded with `loadClass` a `findClass` method is called to locate `A` and this method had to be overwritten. The `ByteClassLoader` was bound to `A` automatically and used by Jython to locate interfaces such as `org.python.core.PyProxy`. This didn’t work and explains the failure. A possible fix is to respond to classes which cannot be dealt with from `ByteClassLoader` and delegate a `findClass` call to the parent class loader.<\/p>\n
Curiously Jython stopped using `ByteClassLoader` after I changed the inheritance hierarchy from<\/p>\n
class ByteClassLoader(ClassLoader):\r\n def __init__(self, code):\r\n super(ByteClassLoader, self).__init__(ClassLoader.getClassLoader())\r\n ...<\/pre>\nto<\/p>\n
class ByteClassLoader(URLClassLoader):\r\n def __init__(self, code):\r\n super(ByteClassLoader, self).__init__([], ClassLoader.getSystemClassLoader())\r\n ...<\/pre>\nThe `URLClassLoader` provides the opportunity to add `URLs` at runtime and therefore modifying the `CLASSPATH` dynamically.<\/p>\n
No disk dumps in Jynx 0.3<\/h3>\n
Prior to Jynx 0.3<\/a> a workaround has been dumping `A` to disk and load the class from there. We discussed the subtle nuances of selecting the right class loader and loading `A` from disk moved the machinery into a correct state. This wasn’t only cumbersome but a hurdle when a programmer intended to work within a Java sandbox. With Jynx 0.3 I feel prepared to explore Java integration with Jynx on GAE-J.<\/p>\n","protected":false},"excerpt":{"rendered":"Broken class loaders Jynx 0.2 contained an ugly workaround for a bug I couldn’t fix for quite a while. The bug can be described as follows: suppose you defined code of a Java class `A` and compiled it dynamically: A … Continue reading