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 ?
errors and stack traces
Logged In: YES
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.
The regression I filed with Sun is here:
Even though it's a different stack, they claim it was a
duplicate of this bug here:
In any case, it's in Sun's hands now. Not being able
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.
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
[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:
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.
Log in to post a comment.