On Sep 9, 2008, at 10:19 PM, Jochen Theodorou wrote: > 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...
Well, my Rhino-in-Spring project uses serialization to create deep copies of continuations. I have a similar mechanism in a proprietary system I work on for living. I routinely override replaceObject/ resolveObject to provide stubbing of named objects, for one thing. Now that you say it, a override of resolveClass() using thread context class loader would also be in order :-) >> 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... I'd encourage you to keep using ObjectInputStream subclass with a resolveClass(). That's your best bet unless Sun is willing to break backwards compatibility and use thread context class loader in input streams. Attila. -- home: http://www.szegedi.org weblog: http://constc.blogspot.com twitter:http://twitter.com/szegedi --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
