Attila Szegedi schrieb: > On Sep 10, 2008, at 10:09 AM, Charles Oliver Nutter wrote: > >> Attila Szegedi wrote: >>> Well, overriding resolveClass() seems like a good solution to me. >>> What >>> problems do you have with that? >> I can give you one reason that it's not good enough, at least for the >> JRuby use case of needing to do our own initialization of objects as >> they're deserialized: I can't make others use our overridden OIS >> subclass, like app servers and so on. > > That's true -- I specifically said this only works when it's your code > doing the deserialization.
in Groovy, this is exactly my problem... I want the user to enable using serialization in way most equal to Java... but it won't do. > Yeah, serialization is seriously broken, > and there's not much you can do to fix it. Some runtime objects in a > JVM just don't lend themselves to be serialized - threads and class > loaders are prime examples. And since a class loader is part of a > class' identity, there you go... class loader + class = Class instance. If a Class can be serialized, there is a potential for keeping the identity. Also serialization may not only be used for persisting data on disc... it is also used for example for RMI. At last theoretically the client could then request the classes it would normally load through the class loader... of course I ma not talking here about stubs and skeletons > Even if someone would embark on a project to create a new pair of > serialization stream classes, that somehow can represent class loader > identity, it would be a very tough nut to crack, but here are some > ideas: > > * URLClassLoaders can be "serialized" by storing their URL lists. Of > course, if the URLs aren't global, then deserialization could fail if > the JAR files aren't in the same location. hmm... storing locations like this is troublesome. > Further, you would end up > with duplicate class loaders on multiple deserializations, except if > you'd happen to have a global registry of sorts. which the ObjectStreams do have, unless you reset them. > * A better idea would be to have a JNDI javax.naming or similar > context that might be passed to serialization/deserialization stream > to bind class loaders to names known in the JVM instance, and have the > ObjectStreamClass also contain the JNDI name of the class' loader. > It'd turn into a headache for "anonymous" class loaders created to > load generated code though, but... true.... storing the bytecode would be another idea ;) > * ... on subject of generated code, I think a language runtime > creating classes on-the-fly for purposes of holding compiled code > could have those classes define writeReplace to have their instances > replaced with a code generator object. The code generator would in > turn need to have a readResolve method to generate the class, > instantiate it, and return it. Maybe utilize a global cache keyed by > SHA-1 digest of the code to eliminate duplicates. impossible in Groovy I think... once compiled the source is lost. And once a class is defined, the bytecode is lost too. Just like in Java bye blackdrag -- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
