Charles Oliver Nutter schrieb: > 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.
I see... and it sounds as if you did not find a better solution too. >> 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. oh, ok, so I looked at the wrong method.... Class.forName(String) is related, but not the same. Which reminds me... I didn't work much with frameworks using java standard serialization, but is it possible, that no such frame work really exists? I mean without doing tricks like my modified ObjectInputStream class. At last the readObject calls can not be part of that... > 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. dark corners in Java ;) >> 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. which means that it wouldn't work the first time. Because the bootstrap method is surely defined in a class loader which is not null. And if it does not work the first time, then it will not work at all, because I will get an exception and stop program execution.... unless bootstrap methods are skipped of course! But this opens for me an interesting aspect, a possible cause of trouble... whenever such stack frame based logic is applied we have a potential problem with the bootstrap method... 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 -~----------~----~----~----~------~----~------~--~---
