Re: freemarker plus javarebel problems...caching?

1) Class immutability is not required by the JVM spec. For example if you
check out
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/Instrumentation.html#redefineClasses(java.lang.instrument.ClassDefinition[])
you can see, that "The redefinition must not add, remove or rename fields or
methods, change the signatures of methods, or change inheritance. These
restrictions maybe be lifted in future versions. " There is actually no
place in JVM/Java specs that say class interfaces cannot change. In fact if
you check out java1.6u10 it has some functionality to deal with the cases
when the reflection results change, so you can hardly say that JavaRebel
violates anything. It is just a common assumption that framework developers
made before it was actually practically possible to redefine classes.

2) You can do both. You can let users call setAssumeMutableClasses(true) and
we can set e.g. "javax.vm.reloadable=true" to let frameworks know that a
reloading agent is running (wouldn't want to tie this to JavaRebel only).
Will this work?

Sorry for the crappy reply style, Nabble sucks :(

Jevgeni Kabanov


Attila Szegedi-3 wrote:
> 
> 
> On 2008.05.16., at 12:53, Daniel Dekany wrote:
> 
>> Thursday, May 15, 2008, 12:48:11 PM, ekabanov wrote:
>>
>>> Well, it's not the only product that allows HotSwap -- IBM J9 has  
>>> some
>>> support and Weblogic 10.3 features something called FastSwap. By  
>>> making
>>> wrong assumptions you are just hurting your own users in the long  
>>> run.
>>
>> I'm pretty much sure that BeansWrapper didn't made a wrong assumption
>> here.
>> It's JavaRebel that breaks a contract of the Java platform. Most
>> Java code will assume that the classes are immutable; this is just a
>> basic thing in the Java philosophy.
> 
> Not just in philosophy - class object immutability is required by the  
> JVM specification. What JavaRebel does is installs a native agent  
> library into the JVM, which results in pretty much custom,  
> implementation specific behavior arising during JVM operation, and is  
> actually inconsistent with JVM specification. FreeMarker does assume  
> it runs on JVM. JavaRebel makes the JVM it is loaded in break the JVM  
> spec, so it's strictly speaking no longer a *Java* VM anymore, and it  
> shows.
> 
>>> And the fix is very easy, just reset the cache when you don't find
>>> some property or method and retry once.
>>
>> If it's easy to fix it, then sure, why not... but I guess it's not
>> easy, since there are some priority rules to resolve ambiguities, like
>> to resolve method overloading ambiguities, Map VS Bean property
>> ambiguities, etc. Anyway, Attila knows this better than me, he will
>> tell...
> 
> Well, if we just ditch the cached info for the class, it might start  
> working for previously nonexisting properties. However, we sometimes  
> do caching on wrapper instance level too - i.e. we create a  
> SimpleMethodModel or OverloadedMethodModel that is bound to an  
> instance. A change in method signatures could invalidate these in a  
> hard-to-debug ways, and since we aren't tracking  all wrapper  
> instances we create, we can't just reach in and patch them up.
> 
> We *could* add a assumeMutableClasses property to BeansWrapper, so  
> when someone runs under JavaRebel he could call  
> setAssumeMutableClasses(true). Actually -- if JavaRebel were to define  
> some system property we can detect, we could do it automatically.
> 
> Attila.
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft 
> Defy all challenges. Microsoft(R) Visual Studio 2008. 
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> FreeMarker-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user
> 
> 

-- 
View this message in context: http://www.nabble.com/freemarker-plus-javarebel-problems...caching--tp17238997p17274520.html
Sent from the freemarker-user mailing list archive at Nabble.com.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/