sounds tricky. given this 'black box' approach, there aren't many guarantees.
first concern would be that you're *sure* that your de-ser exception is *not* due to a platform issue (different compiler, compiler version, etc)
that said, .. in theory, you
should be able to do this, providing you have .class files for
at least class#1 ... (so you can get the serialversionuid that you'll need to deserialize it).
if there's a way to skip this step, i don't know what it might be [a custom loader workaround could be a lot of fruitless work if class1 is substantially "an unknown"]
but if you have .class files for either/both classes, you could try a quick hack like
1) bootstrap code: incorporate a Serializable class1/2 sub-class with the prior definition of class1 serialversionuid into your bootstrap code
2) catch de-ser exception,
3) try de-ser again with your bootstrap class
However, if you are considering writing a custom loader as a true bootstrap loader (to manage runtime loading of class(es) etc) *because* this is the only point where you can implement new code ... before i attempted that, i would try reverse-engineering the existing class resources - there may be other alternatives like writing a separate
thread to monitor, lock, and convert the class2 obj into something readable by class1 ... or arranging the classpath to load your wrapper-logic before class2
rev engineering w reflection/introspection etc sb much easier than writing and
testing a custom classloader for full app