Loading ...
Sorry, an error occurred while loading the content.

Re: [JSX-ideas] Re: Problem with IBM JDK & readObject (another test)

Expand Messages
  • Wolf Geldmacher
    Hi Brendan, to round this up from my side: I tried the following: class ObjIn extends JSX.ObjIn { public ObjIn(InputStream in) throws IOException { super(in);
    Message 1 of 10 , Nov 1, 2001
    • 0 Attachment
      Hi Brendan,

      to round this up from my side:

      I tried the following:

      class ObjIn extends JSX.ObjIn
      {
      public
      ObjIn(InputStream in)
      throws IOException
      {
      super(in);
      }

      protected Class
      resolveClass(ObjectStreamClass v)
      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 to
      > work the same as the way you subclassed it. This should fix it,
      > although it is not entirely correct...

      In what way is this "not entirely correct"? (Just curious..)

      > Just to summarise:
      > (1). It's an internal problem - the null is coming from the JVM
      > internals:

      Agree.

      >
      > (2). It's an internal problem - jdb doesn't usually hang!

      Agree.

      > (3). It's an internal problem - "tt" is not prepared.

      Agree.

      > (4). It's an internal problem - forName(name) fixes it. This
      > differs in two ways: different classloader, and it initializes it.

      Can't quite see why "different classloader". Initialization is the
      point, though.

      > CURRENT GUESS:
      > 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 agree with you, that this is an internal problem of the IBM JVM.
      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
      http://java.sun.com/docs/books/jls/second_edition/html/execution.doc.html
      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.

      Cheers,
      Wolf.
    Your message has been successfully submitted and would be delivered to recipients shortly.