Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#357 JDK 6.0 regression

Snapshot
closed-fixed
Rob Manning
Core (461)
5
2015-01-08
2006-03-13
No

Squirrel doesn't work well with JDK 6.0 beta preview,
especially on the plug-in side; see attached stack traces.

Any chance to win an Ultra-20 Sparc workstation ?
https://mustang.dev.java.net/regchal/

Discussion

  • errors and stack traces

     
    Attachments
  • Rob Manning
    Rob Manning
    2006-03-13

    • status: open --> closed-rejected
     
  • Rob Manning
    Rob Manning
    2006-03-13

    Logged In: YES
    user_id=1287991

    Dmitri,

    Yes I noticed this as well. I also noticed it is a problem
    for applets in the commercial product that I work on.
    I don't have the time right now to boil this down into
    a simple test case to submit. The source is open, so if you
    want to do it, feel free. The stack trace is a very good
    indicator of what code should go into your test. I have a
    feeling that this is a showstopper for many applications
    that use the URLClassLoader. I see this as an issue with
    the JDK, not SQuirreL, so I'm going to close it.

    If you get any feedback from Sun should you decide
    to submit, please pass it along on the dev mailing list.

    Rob

     
  • Rob Manning
    Rob Manning
    2006-07-07

    Logged In: YES
    user_id=1287991

    The regression I filed with Sun is here:

    http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6446627

    Even though it's a different stack, they claim it was a
    duplicate of this bug here:

    http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=4b36eaa1ca5486ffffffffbb35095bd31206e:YfiG?bug_id=6434149

    In any case, it's in Sun's hands now. Not being able
    to
    read serialized classes with arrays of objects seems like
    it is a pretty serious bug and could break lots of things.
    So I imagine they'll do their best to get it fixed before
    the release of 1.6.0. Meanwhile, having this ability
    allows us to not have to hard-code our clone()
    implementations. I might reconsider this limitation and
    provide a work-around (implementing hard-coded references
    to fields in assignFrom for various classes) if Sun fails
    to fix this before releasing 1.6.0. Let's just hope that
    doesn't happen. For now, stick with the latest 1.5.0
    when running SQuirreL.

    Rob

     
  • Rob Manning
    Rob Manning
    2006-07-07

    • status: closed-rejected --> closed-wont-fix
     
  • Rob Manning
    Rob Manning
    2006-09-10

    • labels: --> Core
    • assigned_to: nobody --> manningr
     
  • Rob Manning
    Rob Manning
    2006-09-10

    Logged In: YES
    user_id=1287991

    Ok, so there appears to be a permanent fix for this issue
    that involves changing the way we interact with the
    ClassLoader. Below is the evaluation from the Sun bug
    researcher (in it's entirety) - it describes the solution
    to the problem that I'm going to implement in Utilities.java

    Rob

    [Begin Sun Bug Report Evaluation]

    Just to be clear, this is not a bug in ObjectInputStream--
    the problem is that when the user's anonymous subclass of
    ObjectInputStream overrides resolveClass to load
    deserialized classes from the specific class loader, it uses
    the ClassLoader.loadClass instance method, which does not
    (necessarily) support loading array classes, instead of
    using the static three-argument Class.forName method (like
    ObjectInputStream's own implementation of resolveClass
    uses). The Class.forName methods do support loading array
    classes using the same array class name syntax returned by
    Class.getName and thus also by ObjectStreamClass.getName.

    [When you want to reflectively load a class by name
    initiated using a specific class loader, you should not
    invoke that loader's public loadClass method directly--
    instead, you should always use the static three-argument
    Class.forName method. The ClassLoader.loadClass instance
    method is more intended for delegation from one class loader
    to another within a class loading operation (although this
    is a common confusion and not well described in the
    documentation). In other words, replace L.loadClass(N) with
    Class.forName(N,false,L). The Class.forName invocation may
    eventually end up invoking loadClass on the specified
    loader, but only after taking care of some other aspects of
    the VM's standard symbolic class name resolution process--
    the significant bit in this case being the support for
    loading/creation of array classes.]

    The fact that the ClassLoader.loadClass usage sometimes
    worked with array class names in previous versions was
    considered a bug (unintentional behavior) that got fixed in
    Mustang-- and it did not previously actually "work" fully
    reliably anyway, which is part of the reason that this "bug"
    was fixed. There is some related discussion in the text of
    CR 4976356, and for some further discussion related to
    serialization usage, see this JINI-USERS post:

    http://archives.java.sun.com/cgi-bin/wa?A2=ind0604&L=jini-users&P=1084
    

    Even though this issue is not a bug in ObjectInputStream,
    the fact of the difference in behavior of
    ClassLoader.loadClass is currently open as 6434149, so this
    CR has been marked as a duplicate of that one.

    [End]

     
  • Rob Manning
    Rob Manning
    2006-09-10

    • status: closed-wont-fix --> closed-fixed