Re: freemarker plus javarebel problems...caching?

Perfect!

Thanks,
   Attila.

On Oct 19, 2008, at 5:17 PM, Jevgeni Kabanov wrote:

> 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
>
> On Sun, Oct 19, 2008 at 4:52 PM, Attila Szegedi <[email protected]>  
> 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=/