Re: freemarker plus javarebel problems...caching?

Well, speed is not really an issue here, is it? I assume that the
point of JavaRebel is to speed up the development process, isn't it?

If it's primarily for development/testing, why not just start the
universe again on each request, instantiate a new Configuration
object, with new TemplateLoaders and ObjectWrappers each time and it's
probably still fairly fast just for testing, as opposed to re-
starting an application server.

JR



On Fri, May 16, 2008 at 2:53 PM, Attila Szegedi <[email protected]> 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
>

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