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

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