Re: [JSX-ideas] Re: Problem with IBM JDK & readObject (another test)
- Hi Brendan,
to round this up from my side:
I tried the following:
class ObjIn extends JSX.ObjIn
throws IOException, ClassNotFoundException
// Assumes that this class was loaded by the same ClassLoader
// that is required to load the class to resolve.
return Class.forName(v.getName(), true, getClass().getClassLoader());
and it worked. Replacing the "true" by a "false" reproduces
the known problem exactly.
> I've just changed JSX's default implementation of resolveClass toIn what way is this "not entirely correct"? (Just curious..)
> work the same as the way you subclassed it. This should fix it,
> although it is not entirely correct...
> Just to summarise:Agree.
> (1). It's an internal problem - the null is coming from the JVM
> (2). It's an internal problem - jdb doesn't usually hang!
> (3). It's an internal problem - "tt" is not prepared.Agree.
> (4). It's an internal problem - forName(name) fixes it. ThisCan't quite see why "different classloader". Initialization is the
> differs in two ways: different classloader, and it initializes it.
> CURRENT GUESS:I agree with you, that this is an internal problem of the IBM JVM.
> Java's own Serialization (JOS) may initialize the class at some other
> point, without relying on the classloader to do it. But JSX doesn't
> do this other initialization, which is why JOS works, but JSX
> doesn't. The correct solution is simply for JSX to trigger
> initialization at some other point - or when it is loaded (which is
> what we are doing now). Actually, I feel pretty sure about this
> guess, now. It fits well. Let me check the JOS source... oh well,
> no I can't see it doing it anywhere; it may be a side effect of
> some other call which is not obvious.
I'm using it, because IBM's JVM implementation is faster and
because for some time it was the only implementation that did
allow reasonable debugging on the Linux platform.
Guess: Some of the performance increase of IBM's JVM may
come from different strategies within the JVM - like delaying the
initialization of a class until it really is required - and this is, in the
case at hand, causing the problem, because JSX is actually using
and partly reimplementing methods that are considered to be
"internal to the implementation", at least by IBM.
I checked up on the specification and lo & behold: Chapter 12.3
clearly states, that this behaviour is legal, i.e. that an implementation
may choose to delay parts of the initialization as long as the
language semantics are preserved.
Thanks again for your support.