Groovy runs code in static initializers during compile

[Aaron Digulla]

I'm a big fan of static initializers (aka singletons). In Groovy, I  
when an exception can be thrown in a static initializer, I see this  
when the plugin compiles the code:

java.lang.ExceptionInInitializerError
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:169)
        at ch.globus.mda.MdaDatabase$_createK001_closure1.class$(MdaDatabase.groovy)
        at  
ch.globus.mda.MdaDatabase$_createK001_closure1.doCall(MdaDatabase.groovy:172)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at  
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at  
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at  
org.codehaus.groovy.runtime.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:69)
        at  
org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:713)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:560)
        at  
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:97)
        at ch.globus.mda.MdaDatabase$_createK001_closure1.doCall(MdaDatabase.groovy)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at  
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at  
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at  
org.codehaus.groovy.runtime.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:69)
        at  
org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:713)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:560)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:450)
        at groovy.lang.Closure.call(Closure.java:188)
        at groovy.lang.Closure.call(Closure.java:183)
        at groovy.util.BuilderSupport.doInvokeMethod(BuilderSupport.java:179)
        at groovy.util.BuilderSupport.invokeMethod(BuilderSupport.java:95)
        at org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:136)
        at  
org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:111)
        at  
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:187)
        at ch.globus.mda.MdaDatabase.createK001(MdaDatabase.groovy:22)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at  
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at  
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at  
org.codehaus.groovy.runtime.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:69)
        at  
org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:713)
        at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:664)
        at org.codehaus.groovy.runtime.Invoker.invokeStaticMethod(Invoker.java:158)
        at  
org.codehaus.groovy.runtime.InvokerHelper.invokeStaticMethod(InvokerHelper.java:126)
        at  
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeStaticMethodN(ScriptBytecodeAdapter.java:228)
        at  
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeStaticMethod0(ScriptBytecodeAdapter.java:235)
        at ch.globus.mda.MdaDatabase.<clinit>(MdaDatabase.groovy:15)
        at sun.misc.Unsafe.ensureClassInitialized(Native Method)
        at  
sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
        at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
        at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
        at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
        at java.lang.reflect.Field.get(Field.java:358)
        at  
org.codehaus.groovy.control.ResolveVisitor.getTimeStamp(ResolveVisitor.java:275)
        at  
org.codehaus.groovy.control.ResolveVisitor.isSourceNewer(ResolveVisitor.java:298)
        at  
org.codehaus.groovy.control.ResolveVisitor.resolveToScript(ResolveVisitor.java:327)
        at  
org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:248)
        at  
org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:775)
        at  
org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:128)
        at  
org.codehaus.groovy.control.CompilationUnit$5.call(CompilationUnit.java:595)
        at  
org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:833)
        at  
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:480)
        at  
org.codehaus.groovy.eclipse.core.compiler.GroovyCompiler.compile(GroovyCompiler.java:158)
        at  
org.codehaus.groovy.eclipse.core.compiler.GroovyCompiler.compile(GroovyCompiler.java:89)
        at  
org.codehaus.groovy.eclipse.core.model.GroovyProject.compileGroovyFile(GroovyProject.java:496)
        at  
org.codehaus.groovy.eclipse.core.GroovyCore.sourceChanged(GroovyCore.java:106)
        at  
org.codehaus.groovy.eclipse.editor.GroovyReconcilingStrategy.reconcile(GroovyReconcilingStrategy.java:78)
        at  
org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:71)
        at  
org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:204)
Caused by: java.lang.NullPointerException
        at  
net.sf.ehcache.CacheManager.replaceCacheWithDecoratedCache(CacheManager.java:838)
        at ch.globus.basics.cache.GroovyCache.init(GroovyCache.java:44)
        at ch.globus.basics.cache.GroovyCache.<init>(GroovyCache.java:32)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at  
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at  
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at  
org.codehaus.groovy.runtime.MetaClassHelper.doConstructorInvoke(MetaClassHelper.java:562)
        at groovy.lang.MetaClassImpl.doConstructorInvoke(MetaClassImpl.java:1756)
        at groovy.lang.MetaClassImpl.invokeConstructor(MetaClassImpl.java:758)
        at groovy.lang.MetaClassImpl.invokeConstructor(MetaClassImpl.java:688)
        at org.codehaus.groovy.runtime.Invoker.invokeConstructorOf(Invoker.java:163)
        at  
org.codehaus.groovy.runtime.InvokerHelper.invokeConstructorOf(InvokerHelper.java:140)
        at  
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeNewN(ScriptBytecodeAdapter.java:243)
        at ch.globus.mda.MdaMwst.<clinit>(MdaMwst.groovy:24)
        ... 63 more

This tells me that it's unsafe to use singletons in Groovy if they are  
"complex" (for example, when they depend on runtime configuration). Is  
this a bug in the compiler or a general limitation of Groovy?

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Russel Winder]

On Thu, 2007-04-19 at 16:34 +0200, Aaron Digulla wrote:
> I'm a big fan of static initializers (aka singletons). In Groovy, I  
> when an exception can be thrown in a static initializer, I see this  
> when the plugin compiles the code:

A static initializer is not the same thing as Singleton Pattern.

--
Russel.
====================================================
Dr Russel Winder                [phone]
41 Buckmaster Road              [phone]
London SW11 1EN, UK             russel@...

[Jochen Theodorou]

Aaron Digulla schrieb:
> I'm a big fan of static initializers (aka singletons). In Groovy, I when
> an exception can be thrown in a static initializer, I see this when the
> plugin compiles the code:
> java.lang.ExceptionInInitializerError
>     at java.lang.Class.forName0(Native Method)
>     at java.lang.Class.forName(Class.java:169)
[...]
> org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:71)
>
>     at
> org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:204)
>
> Caused by: java.lang.NullPointerException
>     at
> net.sf.ehcache.CacheManager.replaceCacheWithDecoratedCache(CacheManager.java:838)
>     at ch.globus.basics.cache.GroovyCache.init(GroovyCache.java:44)
[...]
> This tells me that it's unsafe to use singletons in Groovy if they are
> "complex" (for example, when they depend on runtime configuration). Is
> this a bug in the compiler or a general limitation of Groovy?

hmm... I am currently asking myself if we need to resolve the classes we
create when we compile. I know I had once a strange problem with this,
but I think that was with the ReflectorLoader, which is very special
anyway.

hmm... the build seems to be ok with that change...

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Quoting Jochen Theodorou <blackdrag@...>:

>> This tells me that it's unsafe to use singletons in Groovy if they  
>> are "complex" (for example, when they depend on runtime  
>> configuration). Is this a bug in the compiler or a general  
>> limitation of Groovy?
>
> hmm... I am currently asking myself if we need to resolve the classes
> we create when we compile. I know I had once a strange problem with
> this, but I think that was with the ReflectorLoader, which is very
> special anyway.

I would really like a quick fix to this issue: Ehcache will register a  
shutdown hook in the Java VM every time the static initializer is  
compiled. This means that for every compile, a tiny 5MB memory chunk  
is added to PermGen *permanently*. That means that Eclipse will crash  
within a minute or so because every key press will run the compiler  
once.

I'd also like to take this opportunity to ask for a Groovy  
enhancement: The singleton pattern is a widely used one but Java  
doesn't exactly support it out of the box. There is a big minefield  
around there with synchronization issues, lazy initialization loops,  
etc. Would it be possible to add some support in Groovy for this? Like:

@Singleton
SomeClass xxx = { ... code to setup the singleton ... }

or

SomeClass xxx = singleton { ... code to setup the singleton ... }

In both cases, the singleton should be initialized lazily and  
thread-safe, and it should not be possible to modify the value of xxx  
after the first init.

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Jochen Theodorou wrote:
> hmm... I am currently asking myself if we need to resolve the classes we
> create when we compile. I know I had once a strange problem with this,
> but I think that was with the ReflectorLoader, which is very special
> anyway.
>
> hmm... the build seems to be ok with that change...

You shouldn't need to resolve them. JRuby's compiler just leaves them as
byte[] and dumps them to disk without ever loading them.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Charles Oliver Nutter schrieb:

> Jochen Theodorou wrote:
>> hmm... I am currently asking myself if we need to resolve the classes
>> we create when we compile. I know I had once a strange problem with
>> this, but I think that was with the ReflectorLoader, which is very
>> special anyway.
>>
>> hmm... the build seems to be ok with that change...
>
> You shouldn't need to resolve them. JRuby's compiler just leaves them as
> byte[] and dumps them to disk without ever loading them.

depends on the usage, or not? The normal mode in groovy is to not to
write them to disc, so I think there are some differences to Ruby here.
Anyway, I removed the call to resolveClass, normally the problem should
go away now, unless the plugin loads the classes at some point.

hmm... which might happen, when the next compilation step is done... I
am not sure. It is really bad, that a classloader does not allow us to
ask for a class without loading it...

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Quoting Charles Oliver Nutter <charles.nutter@...>:

>> hmm... I am currently asking myself if we need to resolve the  
>> classes we create when we compile. I know I had once a strange  
>> problem with this, but I think that was with the ReflectorLoader,  
>> which is very special anyway.
>>
>> hmm... the build seems to be ok with that change...
>
> You shouldn't need to resolve them. JRuby's compiler just leaves them
> as byte[] and dumps them to disk without ever loading them.

Maybe this code was added because the Groovy compiler sometimes  
generates illegal bytecode? I've seen a few cases where a classfile  
couldn't be verified even though Groovy could compile it.

Just wondering: Wouldn't it be more smart to verify the class *before*  
writing it to a .class file instead of verifying it every time it is  
loaded? There is probably a very good reason to do that ... ;-)

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Quoting Jochen Theodorou <blackdrag@...>:

> hmm... which might happen, when the next compilation step is done... I
> am not sure. It is really bad, that a classloader does not allow us to
> ask for a class without loading it...

Things would be more simple if there was a shutdown/destroy-hook in  
the classloader. Many libraries like Spring, Ehcache and DB drivers  
have to clean up after themselves but the only way is to attach  
themselves to the VM which is not a good idea when you install them in  
a container like Tomcat or OSGi which is supposed to run forever and  
load/unload plugins on demand.

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Quoting Jochen Theodorou <blackdrag@...>:

> hmm... I am currently asking myself if we need to resolve the classes
> we create when we compile. I know I had once a strange problem with
> this, but I think that was with the ReflectorLoader, which is very
> special anyway.

How do I get this fix? I need it in the Eclipse plugin.

It would be nice to have it in the Maven plugin as well but since the  
code there is executed just once, I don't have a big problem with it.

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Aaron Digulla schrieb:

> Quoting Jochen Theodorou <blackdrag@...>:
>
>> hmm... I am currently asking myself if we need to resolve the classes
>> we create when we compile. I know I had once a strange problem with
>> this, but I think that was with the ReflectorLoader, which is very
>> special anyway.
>
> How do I get this fix? I need it in the Eclipse plugin.
>
> It would be nice to have it in the Maven plugin as well but since the
> code there is executed just once, I don't have a big problem with it.

I would suggest you patch it by hand to see if the problem is still
there. This means get GroovyClassLoader from SVN, compile it, replace
the classes for it in the groovy.jar of the plugin and see what happens.

or maybe I misunderstood you... is the static initializer in a java class?

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Jochen Theodorou wrote:

> Charles Oliver Nutter schrieb:
>> Jochen Theodorou wrote:
>>> hmm... I am currently asking myself if we need to resolve the classes
>>> we create when we compile. I know I had once a strange problem with
>>> this, but I think that was with the ReflectorLoader, which is very
>>> special anyway.
>>>
>>> hmm... the build seems to be ok with that change...
>>
>> You shouldn't need to resolve them. JRuby's compiler just leaves them
>> as byte[] and dumps them to disk without ever loading them.
>
> depends on the usage, or not? The normal mode in groovy is to not to
> write them to disc, so I think there are some differences to Ruby here.
> Anyway, I removed the call to resolveClass, normally the problem should
> go away now, unless the plugin loads the classes at some point.
>
> hmm... which might happen, when the next compilation step is done... I
> am not sure. It is really bad, that a classloader does not allow us to
> ask for a class without loading it...

But Groovy does have an offline compilation mode, yes? So in general, if
you're not going to load the class for use, don't load it at all. That's
how the JRuby compiler works....compile is one step, "loadClasses" or
"writeClasses" are others. Compile doesn't actually load any code at all.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Aaron Digulla wrote:
> Maybe this code was added because the Groovy compiler sometimes
> generates illegal bytecode? I've seen a few cases where a classfile
> couldn't be verified even though Groovy could compile it.
>
> Just wondering: Wouldn't it be more smart to verify the class *before*
> writing it to a .class file instead of verifying it every time it is
> loaded? There is probably a very good reason to do that ... ;-)

Of course, but that requires either passing it through an offline
verifier (maybe something in ASM?) or loading the class...with the
result that static initializers are invoked and dependency classes are
loaded too.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Jochen Theodorou schrieb:

>> How do I get this fix? I need it in the Eclipse plugin.
>>
>> It would be nice to have it in the Maven plugin as well but since the
>> code there is executed just once, I don't have a big problem with it.
>
> I would suggest you patch it by hand to see if the problem is still
> there. This means get GroovyClassLoader from SVN, compile it, replace
> the classes for it in the groovy.jar of the plugin and see what happens.
>
> or maybe I misunderstood you... is the static initializer in a java class?

No, it's Groovy code. I'll try this on Monday and report my findings.

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Charles Oliver Nutter schrieb:
[...]
> But Groovy does have an offline compilation mode, yes? So in general, if
> you're not going to load the class for use, don't load it at all. That's
> how the JRuby compiler works....compile is one step, "loadClasses" or
> "writeClasses" are others. Compile doesn't actually load any code at all.

you mean it does not load classes it had compiled, but you do load
classes that you need for your compilation, or not? Well maybe not, I
don't know... but in Groovy, when I subclass a class, that I don't
compile, I need to load that class.

bye blackdrag
--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Jochen Theodorou wrote:

> Charles Oliver Nutter schrieb:
> [...]
>> But Groovy does have an offline compilation mode, yes? So in general,
>> if you're not going to load the class for use, don't load it at all.
>> That's how the JRuby compiler works....compile is one step,
>> "loadClasses" or "writeClasses" are others. Compile doesn't actually
>> load any code at all.
>
> you mean it does not load classes it had compiled, but you do load
> classes that you need for your compilation, or not? Well maybe not, I
> don't know... but in Groovy, when I subclass a class, that I don't
> compile, I need to load that class.

Why do you need to do that? ASM shouldn't require the class be loaded to
generate bytecode for a subclass. But if you're doing some additional
inspection of that class, then yeah I suppose you would have to load it.
  Perhaps you could try to load it as byte[] via classloader resources
instead, passing the result to ASM to inspect it rather than using Java
reflection? Obviously if you use reflection the class has to be loaded.

And yes, the JRuby compiler only loads what it needs to compile, but of
course Ruby classes it compiles don't actually turn into Java classes in
the way Groovy classes do (or at least, not in the current compiler).

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Charles Oliver Nutter schrieb:

> Jochen Theodorou wrote:
>> Charles Oliver Nutter schrieb:
>> [...]
>>> But Groovy does have an offline compilation mode, yes? So in general,
>>> if you're not going to load the class for use, don't load it at all.
>>> That's how the JRuby compiler works....compile is one step,
>>> "loadClasses" or "writeClasses" are others. Compile doesn't actually
>>> load any code at all.
>>
>> you mean it does not load classes it had compiled, but you do load
>> classes that you need for your compilation, or not? Well maybe not, I
>> don't know... but in Groovy, when I subclass a class, that I don't
>> compile, I need to load that class.
>
> Why do you need to do that? ASM shouldn't require the class be loaded to
> generate bytecode for a subclass.

asm not, but I need to know the full class name for example. And not
only that, how can I check that a class is final or abstract when not
loading them somehow. The problem now is that we load the class by using
loadClass from the classloader, which causes a static initializer to be
used. A possible way around might be to lookup them as a .class file,
but that limits it to classfiles (virtual or real files)

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Jochen Theodorou wrote:
> asm not, but I need to know the full class name for example. And not
> only that, how can I check that a class is final or abstract when not
> loading them somehow. The problem now is that we load the class by using
> loadClass from the classloader, which causes a static initializer to be
> used. A possible way around might be to lookup them as a .class file,
> but that limits it to classfiles (virtual or real files)

Maybe that's not a bad limitation? It seems like a better deal than
loading the class when static initializers could potentially blow up.
And I'd wager javac does something similar...you can't compile stuff in
javac unless you've got the physical class files locally, right?

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Quoting Jochen Theodorou <blackdrag@...>:

>>> you mean it does not load classes it had compiled, but you do load  
>>>  classes that you need for your compilation, or not? Well maybe  
>>> not, I don't know... but in Groovy, when I subclass a class, that  
>>> I don't compile, I need to load that class.
>>
>> Why do you need to do that? ASM shouldn't require the class be  
>> loaded to generate bytecode for a subclass.
>
> asm not, but I need to know the full class name for example. And not
> only that, how can I check that a class is final or abstract when not
> loading them somehow. The problem now is that we load the class by
> using loadClass from the classloader, which causes a static initializer
> to be used. A possible way around might be to lookup them as a .class
> file, but that limits it to classfiles (virtual or real files)

Would it be possible to add shutdown hooks to the GroovyClassLoader?

That would solve my problem because I could shutdown Ehcache (it would  
then remove its VM shutdown hook and GC would work again).

As for the classloading issue: I think that others also have the  
problem that they need to analyze a class without actually loading it  
(a Virus scanner, for example). Maybe BCEL  
(http://jakarta.apache.org/bcel/) would help?

And before you argue that you don't want Groovy to have too many  
dependencies: In Java, the compiler is it's own JAR (tools.jar); it's  
not part of the runtime. So if the 500KB is too much, split the Groovy  
RT into a part which can just execute compiled code and one which can  
also compile groovy files on the fly. Not all projects need both  
capabilities. And maybe you can also strip unnecessary parts from BCEL  
when you include it to make it smaller.

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Alexandru Popescu ☀]

On 4/23/07, Jochen Theodorou <blackdrag@...> wrote:

> Charles Oliver Nutter schrieb:
> > Jochen Theodorou wrote:
> >> Charles Oliver Nutter schrieb:
> >> [...]
> >>> But Groovy does have an offline compilation mode, yes? So in general,
> >>> if you're not going to load the class for use, don't load it at all.
> >>> That's how the JRuby compiler works....compile is one step,
> >>> "loadClasses" or "writeClasses" are others. Compile doesn't actually
> >>> load any code at all.
> >>
> >> you mean it does not load classes it had compiled, but you do load
> >> classes that you need for your compilation, or not? Well maybe not, I
> >> don't know... but in Groovy, when I subclass a class, that I don't
> >> compile, I need to load that class.
> >
> > Why do you need to do that? ASM shouldn't require the class be loaded to
> > generate bytecode for a subclass.
>
> asm not, but I need to know the full class name for example. And not
> only that, how can I check that a class is final or abstract when not
> loading them somehow. The problem now is that we load the class by using
> loadClass from the classloader, which causes a static initializer to be
> used. A possible way around might be to lookup them as a .class file,
> but that limits it to classfiles (virtual or real files)
>

I don't remember right now the ASM API, but I think it is possible to
handle it a byte[] and then just use visitors for reading all the
needed information. If it doesn't then too bad :-).

./alex
--
.w( the_mindstorm )p.
_____________________________________
  Alexandru Popescu, OSS Evangelist
TestNG/Groovy/AspectJ/WebWork/more...
  Information Queue ~ www.InfoQ.com

> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> Groovy Tech Lead (http://groovy.codehaus.org)
> http://blackdragsview.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Quoting Aaron Digulla <digulla@...>:

> Jochen Theodorou schrieb:
>
>>> How do I get this fix? I need it in the Eclipse plugin.
>>>
>>> It would be nice to have it in the Maven plugin as well but since  
>>> the code there is executed just once, I don't have a big problem  
>>> with it.
>>
>> I would suggest you patch it by hand to see if the problem is still  
>>  there. This means get GroovyClassLoader from SVN, compile it,  
>> replace the classes for it in the groovy.jar of the plugin and see  
>> what happens.
>>
>> or maybe I misunderstood you... is the static initializer in a java class?
>
> No, it's Groovy code. I'll try this on Monday and report my findings.

I still see that the static initialized is executed (log4j write a  
warning to stdout) but no stacktrace anymore. So it's better but not  
perfect.

I added "new RuntimeException().printStackTrace()" to my code to see  
what happens; the stacktrace is attached to this mail.

Any idea how to fix this, too?

Regards,

--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/

java.lang.RuntimeException
        at ch.globus.basics.cache.GroovyCache.getCacheManager(GroovyCache.java:56)
        at ch.globus.basics.cache.GroovyCache.init(GroovyCache.java:50)
        at ch.globus.basics.cache.GroovyCache.<init>(GroovyCache.java:33)
        at ch.globus.basics.cache.GroovyCache.<init>(GroovyCache.java:20)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at org.codehaus.groovy.runtime.MetaClassHelper.doConstructorInvoke(MetaClassHelper.java:562)
        at groovy.lang.MetaClassImpl.doConstructorInvoke(MetaClassImpl.java:1756)
        at groovy.lang.MetaClassImpl.invokeConstructor(MetaClassImpl.java:758)
        at groovy.lang.MetaClassImpl.invokeConstructor(MetaClassImpl.java:688)
        at org.codehaus.groovy.runtime.Invoker.invokeConstructorOf(Invoker.java:163)
        at org.codehaus.groovy.runtime.InvokerHelper.invokeConstructorOf(InvokerHelper.java:140)
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeNewN(ScriptBytecodeAdapter.java:243)
        at ch.globus.ct.CtCode.<clinit>(CtCode.groovy:90)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:169)
        at ch.globus.ct.CtDatabase$_createK002_closure1.class$(CtDatabase.groovy)
        at ch.globus.ct.CtDatabase$_createK002_closure1.doCall(CtDatabase.groovy:21)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.groovy.runtime.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:69)
        at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:713)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:560)
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:97)
        at ch.globus.ct.CtDatabase$_createK002_closure1.doCall(CtDatabase.groovy)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.groovy.runtime.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:69)
        at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:713)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:560)
        at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:450)
        at groovy.lang.Closure.call(Closure.java:188)
        at groovy.lang.Closure.call(Closure.java:183)
        at groovy.util.BuilderSupport.doInvokeMethod(BuilderSupport.java:179)
        at groovy.util.BuilderSupport.invokeMethod(BuilderSupport.java:95)
        at org.codehaus.groovy.runtime.Invoker.invokeMethod(Invoker.java:136)
        at org.codehaus.groovy.runtime.InvokerHelper.invokeMethod(InvokerHelper.java:111)
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodN(ScriptBytecodeAdapter.java:187)
        at ch.globus.ct.CtDatabase.createK002(CtDatabase.groovy:20)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.groovy.runtime.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:69)
        at org.codehaus.groovy.runtime.MetaClassHelper.doMethodInvoke(MetaClassHelper.java:713)
        at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:664)
        at org.codehaus.groovy.runtime.Invoker.invokeStaticMethod(Invoker.java:158)
        at org.codehaus.groovy.runtime.InvokerHelper.invokeStaticMethod(InvokerHelper.java:126)
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeStaticMethodN(ScriptBytecodeAdapter.java:228)
        at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeStaticMethod0(ScriptBytecodeAdapter.java:235)
        at ch.globus.ct.CtDatabase.<clinit>(CtDatabase.groovy:15)
        at sun.misc.Unsafe.ensureClassInitialized(Native Method)
        at sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25)
        at sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122)
        at java.lang.reflect.Field.acquireFieldAccessor(Field.java:918)
        at java.lang.reflect.Field.getFieldAccessor(Field.java:899)
        at java.lang.reflect.Field.get(Field.java:358)
        at org.codehaus.groovy.control.ResolveVisitor.getTimeStamp(ResolveVisitor.java:275)
        at org.codehaus.groovy.control.ResolveVisitor.isSourceNewer(ResolveVisitor.java:298)
        at org.codehaus.groovy.control.ResolveVisitor.resolveToScript(ResolveVisitor.java:327)
        at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:248)
        at org.codehaus.groovy.control.ResolveVisitor.resolveFromModule(ResolveVisitor.java:475)
        at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:248)
        at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:226)
        at org.codehaus.groovy.control.ResolveVisitor.transformVariableExpression(ResolveVisitor.java:657)
        at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:538)
        at org.codehaus.groovy.control.ResolveVisitor.transformPropertyExpression(ResolveVisitor.java:627)
        at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:540)
        at org.codehaus.groovy.ast.expr.Expression.transformExpressions(Expression.java:79)
        at org.codehaus.groovy.ast.expr.ArgumentListExpression.transformExpression(ArgumentListExpression.java:85)
        at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:553)
        at org.codehaus.groovy.ast.expr.ConstructorCallExpression.transformExpression(ConstructorCallExpression.java:78)
        at org.codehaus.groovy.control.ResolveVisitor.transformConstructorCallExpression(ResolveVisitor.java:722)
        at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:550)
        at org.codehaus.groovy.control.ResolveVisitor.transformDeclarationExpression(ResolveVisitor.java:747)
        at org.codehaus.groovy.control.ResolveVisitor.transform(ResolveVisitor.java:542)
        at org.codehaus.groovy.control.ResolveVisitor.visitExpressionStatement(ResolveVisitor.java:839)
        at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:70)
        at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:83)
        at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitBlockStatement(ClassCodeVisitorSupport.java:102)
        at org.codehaus.groovy.control.ResolveVisitor.visitBlockStatement(ResolveVisitor.java:845)
        at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:82)
        at org.codehaus.groovy.control.ResolveVisitor.visitMethod(ResolveVisitor.java:181)
        at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:838)
        at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:36)
        at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:787)
        at org.codehaus.groovy.control.ResolveVisitor.startResolving(ResolveVisitor.java:128)
        at org.codehaus.groovy.control.CompilationUnit$5.call(CompilationUnit.java:595)
        at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:833)
        at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:480)
        at org.codehaus.groovy.eclipse.core.compiler.GroovyCompiler.compile(GroovyCompiler.java:158)
        at org.codehaus.groovy.eclipse.core.compiler.GroovyCompiler.compile(GroovyCompiler.java:89)
        at org.codehaus.groovy.eclipse.core.model.GroovyProject.compileGroovyFile(GroovyProject.java:496)
        at org.codehaus.groovy.eclipse.core.GroovyCore.sourceChanged(GroovyCore.java:106)
        at org.codehaus.groovy.eclipse.editor.GroovyReconcilingStrategy.reconcile(GroovyReconcilingStrategy.java:78)
        at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:71)
        at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:204)


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email