Jochen Theodorou wrote: > Now this gives me several problems... for once I would like to have more > control over the serialization and deserialization process, but with the > standard deserialization there is no chance it seems.
We have had to deal with a similar problem in JRuby, where in our cases deserialization of Ruby objects requires a JRuby runtime object to be attached to them. Since we support multiple JRuby runtimes co-existing in the same JVM and within the same classloader space, threadlocals are not an option. So ultimately, there's no simple way to provide our runtime for the instantiation of Ruby objects. > to at last document the problem I would like to know a bit more about > how the class loader is chosen. If I know it right, then it goes to the > frame before Class.forName was called and uses the class loader of the > calling class there. That means in this frame I would have to have my > Groovy class... which can not happen, because our stacks are bigger. So > the code usually ends up in in the class loader knowing the Groovy > runtime, and that loader does not know the scripts, which are defined in > a class loader being child of that loader.... or even deeper. From looking at ObjectInputStream, it appears to pass the result of a native method latestUserDefinedLoader() to Class.forName, which according to its javadoc looks for the first non-null classloader up the execution stack. So yes, it seems like having unrelated frames there would be a problem. I presume this does is not impacted by all the intervening Java classes because they're loaded via the bootstrap classloader, which would mean they have a null classloader. > I wonder how invokedynamic would behave here... does invokedynamic add > stack frames? if not, then there is a chance that Class.forName would > work again. If its adding stack frames, then I see no chance. invokedynamic would have no additional frames between the call site and the target method, but only after it's been bootstrapped. This would mean that initially (and whenever the site gets flushed) it would have at least an extra frame there for the bootstrap method. - Charlie --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
