Re: freemarker plus javarebel problems...caching?

Hi!

You don't need to compile against the javarebel.jar, specially for this
reason we publish the JavaRebel SDK distribution including the
javarebel-sdk.jar, which is open source under Apache License 2.0. You can
get it from here:
http://zt-oss.googlecode.com/files/javarebel-sdk-1.2.zip

You are of course free to host it anywhere you please or redistribute it or
whatever.

Jevgeni Kabanov


Attila Szegedi-3 wrote:
> 
> Hey, Jevgeni -- I've had a bit of a time to look into this this  
> weekend. Technically, it seems trivial to add a class reload listener  
> to FreeMarker using JavaRebel's API.
> 
> I only have a question of legal nature: we host a copy of all our 3rd  
> party dependency JAR files on SourceForge in order to allow people to  
> compile FreeMarker without having them do their own jarfile hunt. Our  
> build.xml just pulls these from sf.net and compiles FreeMarker source  
> against them. Would you mind if we hosted javarebel.jar, or at least a  
> stripped down version of it with only those .class files we require  
> for compilation?
> 
> Attila.
> 
> On May 16, 2008, at 3:19 PM, 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=/
> _______________________________________________
> 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--tp17238997p20056448.html
Sent from the freemarker-user mailing list archive at Nabble.com.


-------------------------------------------------------------------------
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=/