Turns out this is a much more vexing problem
then I had anticipated. ClassLoaders always
attempt delegation to the parent ClassLoader
first, and the methods that could prevent
this behavior are all final.
Result? You can't create a ClassLoader that
loads an old version of a class, if there
is a newer version in your classpath. Everything
seems to be working nicely until you notice
that the dynamically loaded instance you have
is the new version, not the old.
However, you can call defineClass() and
just hand it the byte[] read from the
legacy .jar file.
Unfortunately, this
approach seems to lead unavoidably to a
java.lang.VerifyError, which has the clear
and meaningful description: 'Thrown when the
"verifier" detects that a class file, though
well formed, contains some sort of internal
inconsistency or security problem.'
Clear as mud. Thanks.
I think I'm at a brick wall on writing this
unit test. I'm going to revert to refactoring
and writing the documentation. I feel that
with the addition of the serialVersionUID
check, this version becomes *at it's worst*
as good as OIS.defaultReadObject(). Further,
it can be demonstrated empirically, though
not easily unit tested, that it is capable of
version safe deserialization from 1.1.3.
-------------------------------------------------------------------
Who owns your data?
Proprietary protocols and file formats are dangerous.
-------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
