commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <>
Subject Re: JavaFlow in OSGi
Date Fri, 23 Feb 2007 14:58:35 GMT
>>> I would like to know that if ContinuationClassloader is compatible
>>> with the standard ClassLoader mechanism in OSGi runtime environments
>>> (like Knopflerfish,etc....).
>> What's the exact meaning of "compatible" here?
> As I understand that Javaflow has a typical class ...bytecode.Stack
> object which serves as a "virtual" stack in the memory and over it,  
> we have a full control.  The class looks like every normal class  
> has to be either treated statically with the Javaflow ant task, or  
> loaded by javaflow's ContinuationClassLoader which instruments the  
> code at runtime. Thus, you can replay the stack whenever it is  
> needed. The problem with this approach is that in OSGi, the  
> classloading is crucial and cannot be easily replaced by a  
> different classloading mechanism.

Ehm ...I am far from being an OSGi expert but I recall that this  
should not be a problem least according to the discussion we  
had over at Cocoon.

> My question is that can ContinuationClassloader can live together  
> with the OSGi standard Classloader peacefully?

As of now I can only say "maybe" ...or "probably". As I have never  
tried that myself.

But maybe the real question is - does it have to? As far as I know  
OSGi already support reloading ....maybe the right way is to have a  
look how OSGi loads the classes and then hook in there. I would be  
very interested in pursuing this question further.

> Well, I also think that how this class could work among different Java
> VMs. The layout of the stack heavily depends on the implementation  
> of the
> JVMs. Without verifying, I assume that if you have a Sun VM and a  
> VM using the GNU Classpath, this is very likely to fail. Are my  
> arguements absolutely wrong?

Well... yes, they are wrong :)

I suggest you read this paper to  
understand the mechanism behind javaflow.

As long as the the class layout stays the same - what is on the stack  
should also stay the same. This is dependent on the underlying byte  
code - not the jvm implementation of it. (Although different  
compilers could create different class layouts) But every jvm should  
do the same on the same class layout - otherwise we all have a big  
problem ;)

Just make sure to keep the original .class alongside with the  
continuation and you should be fine - even across different jvms.




To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message