Re: freemarker plus javarebel problems...caching?

Okay folks, JavaRebel integration is one of new features for 2.3.15.  
We're using the open source API to JavaRebel; if it's in the  
classpath, FreeMarker adds a class reloader listener and selectively  
invalidates its class introspection caches when something is reloaded.

If you want to give it a try before we release 2.3.15, you can grab a  
build from Bamboo:

<http://freemarker.org:8085/download/FM-BRANCH23/artifacts/build-104/Library/freemarker.jar 
 >

(Also, this is not *yet* forward-ported to 2.4.0)

Attila.

On 2008.05.16., at 15:19, ekabanov wrote:

>
> 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 the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/