Groovy runs code in static initializers during compile

[Aaron Digulla]

Quoting Aaron Digulla <digulla@...>:

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

Any update on this one?

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

[Tom Nichols]

FWIW, doesn't the Java compiler exhibit the same behavior?  A quick
test, and I cannot do this:

public class Test {
  static {
    throw new RuntimeException();
  }
}

or the same in a non-static initializer block- Javac cannot compile it:

$ javac Test.java
Test.java:2: initializer must be able to complete normally
        static {
               ^
1 error

If you change the code to:
if( false) throw new RuntimeException();
it will compile.  I was under the impression that exceptions "should
not" be thrown from initializers.  Aaron, I'm not sure if you could
re-design to avoid this, but I'm guessing you already considered that?
-Tom

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

    http://xircles.codehaus.org/manage_email

[Alexandru Popescu ☀]

On 4/25/07, Tom Nichols <tmnichols@...> wrote:

> FWIW, doesn't the Java compiler exhibit the same behavior?  A quick
> test, and I cannot do this:
>
> public class Test {
>   static {
>     throw new RuntimeException();
>   }
> }
>
> or the same in a non-static initializer block- Javac cannot compile it:
>
> $ javac Test.java
> Test.java:2: initializer must be able to complete normally
>         static {
>                ^
> 1 error
>
> If you change the code to:
> if( false) throw new RuntimeException();
> it will compile.  I was under the impression that exceptions "should
> not" be thrown from initializers.  Aaron, I'm not sure if you could
> re-design to avoid this, but I'm guessing you already considered that?
> -Tom
>

Tom I would say that you are totally right. According to the JLS 8.7:

[quote]
It is a compile-time error for a static initializer to be able to
complete abruptly (§14.1, §15.6) with a checked exception (§11.2). It
is a compile-time error if a static initializer cannot complete
normally (§14.20).
[/quote]

./alex
--
.w( the_mindstorm )p.
_____________________________________
  Alexandru Popescu, OSS Evangelist
TestNG/Groovy/AspectJ/WebWork/more...
  Information Queue ~ www.InfoQ.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

[Charles Oliver Nutter-2]

Alexandru Popescu ☀ wrote:
> Tom I would say that you are totally right. According to the JLS 8.7:
>
> [quote]
> It is a compile-time error for a static initializer to be able to
> complete abruptly (§14.1, §15.6) with a checked exception (§11.2). It
> is a compile-time error if a static initializer cannot complete
> normally (§14.20).
> [/quote]

This doesn't mean javac is running the static initializer, it's just
detecting that there is no successful path through it. Like if you have
a throw or return followed by any other code, javac will tell you that
code is unreachable.

- Charlie

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

    http://xircles.codehaus.org/manage_email

[Alexandru Popescu ☀]

On 4/25/07, Charles Oliver Nutter <charles.nutter@...> wrote:

> Alexandru Popescu ☀ wrote:
> > Tom I would say that you are totally right. According to the JLS 8.7:
> >
> > [quote]
> > It is a compile-time error for a static initializer to be able to
> > complete abruptly (§14.1, §15.6) with a checked exception (§11.2). It
> > is a compile-time error if a static initializer cannot complete
> > normally (§14.20).
> > [/quote]
>
> This doesn't mean javac is running the static initializer, it's just
> detecting that there is no successful path through it. Like if you have
> a throw or return followed by any other code, javac will tell you that
> code is unreachable.
>

True... but also the code was wrong.

./alex
--
.w( the_mindstorm )p.

> - Charlie
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

[Tom Nichols]

Okay maybe you're right... I tried this:
public class Test {
    static {
        if( System.currentTimeMillis() > 1 ) throw new RuntimeException();
    }
}
Which seems to compile OK.

On 4/25/07, Charles Oliver Nutter <charles.nutter@...> wrote:
> This doesn't mean javac is running the static initializer, it's just
> detecting that there is no successful path through it. Like if you have
> a throw or return followed by any other code, javac will tell you that
> code is unreachable.

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

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Quoting Tom Nichols <tmnichols@...>:

> FWIW, doesn't the Java compiler exhibit the same behavior?

No. I'm not throwing an exception but my code installes a shutdown  
hook in the VM. In this case, the VM is the one of Eclipse (the one  
which runs the Groovy plugin). Which means that the compiled classes  
can never be garbage collected.

I've solved the issue for now by adding a static variable ACTIVE =  
false so the code doesn't execute when it is compiled (if (!ACTIVE)  
return). But the compiler should not try to load/resolve classes while  
it compiles because that will result in odd side effects.

This makes me wonder how the Java compiler handles this situation. It  
does know about classes on the classpath but it somehow doesn't use a  
classloader to inspect them :-/

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 Alexandru Popescu ? <the.mindstorm.mailinglist@...>:

> Tom I would say that you are totally right. According to the JLS 8.7:
>
> [quote]
> It is a compile-time error for a static initializer to be able to
> complete abruptly (§14.1, §15.6) with a checked exception (§11.2). It
> is a compile-time error if a static initializer cannot complete
> normally (§14.20).
> [/quote]

Well, this code is still valid, then:

public class Test {
   static {
     throwUp ();
   }

   static void throwUp () { throw new RuntimeException (); }
}

And my case is not that I'm throwing exceptions but that Groovy calls  
"throwUp" while it compiles this code!

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

[glaforge]

I'm resurecting an old thread, but I noticed we now have a shutdown
hook you could probably use:

http://jira.codehaus.org/browse/GROOVY-1745

If that's what you're after...

On 4/20/07, Aaron Digulla <digulla@...> wrote:

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

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

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

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Quoting Guillaume Laforge <glaforge@...>:

> I'm resurecting an old thread, but I noticed we now have a shutdown
> hook you could probably use:
>
> http://jira.codehaus.org/browse/GROOVY-1745
>
> If that's what you're after...

I need a hook into GroovyClassLoader.dispose(), not the VM. The hook  
in the VM is what is causing the trouble!

I've been able to create a test case:  
http://jira.codehaus.org/browse/GROOVY-1863

But in the end, this means that the Groovy compiler must not use  
reflection anywhere. I'll ask the Eclipse JDK guys how they solved this.

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

[glaforge]

On 4/30/07, Aaron Digulla <digulla@...> wrote:
> [...]
> I need a hook into GroovyClassLoader.dispose(), not the VM. The hook
> in the VM is what is causing the trouble!

Did you create a jira feature requestion for GCL#dispose()?

> I've been able to create a test case:
> http://jira.codehaus.org/browse/GROOVY-1863
>
> But in the end, this means that the Groovy compiler must not use
> reflection anywhere. I'll ask the Eclipse JDK guys how they solved this.

Great, that'd be interesting to know what they did.

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

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

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Quoting Guillaume Laforge <glaforge@...>:

>> [...]
>> I need a hook into GroovyClassLoader.dispose(), not the VM. The hook
>> in the VM is what is causing the trouble!
>
> Did you create a jira feature requestion for GCL#dispose()?

Not yet. I'm not 100% sure it's the right solution. Shall I open it  
anyway? It might become an unused feature...

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

[glaforge]

If you really think it's useful and needed, and if you think it's the
right solution, you should certainly create a JIRA issue.

On 4/30/07, Aaron Digulla <digulla@...> wrote:

> Quoting Guillaume Laforge <glaforge@...>:
>
> >> [...]
> >> I need a hook into GroovyClassLoader.dispose(), not the VM. The hook
> >> in the VM is what is causing the trouble!
> >
> > Did you create a jira feature requestion for GCL#dispose()?
>
> Not yet. I'm not 100% sure it's the right solution. Shall I open it
> anyway? It might become an unused feature...
>
> 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
>
>

--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy

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

    http://xircles.codehaus.org/manage_email

[lujop]

On 4/25/07, Alexandru Popescu ☀ <the.mindstorm.mailinglist@...> wrote:

> On 4/25/07, Charles Oliver Nutter <charles.nutter@...> wrote:
> > Alexandru Popescu ☀ wrote:
> > > Tom I would say that you are totally right. According to the JLS 8.7:
> > >
> > > [quote]
> > > It is a compile-time error for a static initializer to be able to
> > > complete abruptly (§14.1, §15.6) with a checked exception (§11.2). It
> > > is a compile-time error if a static initializer cannot complete
> > > normally (§14.20).
> > > [/quote]
> >
> > This doesn't mean javac is running the static initializer, it's just
> > detecting that there is no successful path through it. Like if you have
> > a throw or return followed by any other code, javac will tell you that
> > code is unreachable.

Yes, but this error not only affect "bad" code. For example in a
little prototype I  initialized Hibernate JPA in a static field... And
every time I did a  compile the hibernate initialization process was
launched. And It's not a short one ;)

Cheers,

--
Joan Jesús Pujol Espinar
http://www.joanpujol.cat
http://lujop.deviantart.com

[Charles Oliver Nutter-2]

Guillaume Laforge wrote:
> If you really think it's useful and needed, and if you think it's the
> right solution, you should certainly create a JIRA issue.

BTW guys, in working on classloader stuff for JRuby, I remembered there
exists the following method on Class:

forName(String name, boolean initialize, ClassLoader loader)

where initialize says whether to initialize the class or not. I'm not
sure if that would work for the Groovy compiler or if you need more than
that, but it seems to fit the requirements I've heard.

- Charlie

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

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Joan Pujol schrieb:

> Yes, but this error not only affect "bad" code. For example in a
> little prototype I  initialized Hibernate JPA in a static field... And
> every time I did a  compile the hibernate initialization process was
> launched. And It's not a short one ;)

I've come up with a workaround but it's very clumsy:

public static ACTIVE = false
private final static SomeClass foo = init ()

private static SomeClass init ()
{
        if (!ACTIVE) return null
        return new SomeClass
}

In main(), you can set ACTIVE to true and the code will start to work.
Only when Groovy compiles it, the class is not created.

This gets especially ugly when there are lots of ways to start your app
(like in my case: JUnit tests, tools, GWT apps).

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

[lujop]

Hello,

Or you can use the typical   private constructor/static private
instance/getInstance

Cheers,

On 4/30/07, Aaron Digulla <digulla@...> wrote:

> Joan Pujol schrieb:
>
> > Yes, but this error not only affect "bad" code. For example in a
> > little prototype I  initialized Hibernate JPA in a static field... And
> > every time I did a  compile the hibernate initialization process was
> > launched. And It's not a short one ;)
>
> I've come up with a workaround but it's very clumsy:
>
> public static ACTIVE = false
> private final static SomeClass foo = init ()
>
> private static SomeClass init ()
> {
>         if (!ACTIVE) return null
>         return new SomeClass
> }
>
> In main(), you can set ACTIVE to true and the code will start to work.
> Only when Groovy compiles it, the class is not created.
>
> This gets especially ugly when there are lots of ways to start your app
> (like in my case: JUnit tests, tools, GWT apps).
>
> 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
>
>

--
Joan Jesús Pujol Espinar
http://www.joanpujol.cat
http://lujop.deviantart.com

[Alexandru Popescu ☀]

On 4/30/07, Charles Oliver Nutter <charles.nutter@...> wrote:

> Guillaume Laforge wrote:
> > If you really think it's useful and needed, and if you think it's the
> > right solution, you should certainly create a JIRA issue.
>
> BTW guys, in working on classloader stuff for JRuby, I remembered there
> exists the following method on Class:
>
> forName(String name, boolean initialize, ClassLoader loader)
>
> where initialize says whether to initialize the class or not. I'm not
> sure if that would work for the Groovy compiler or if you need more than
> that, but it seems to fit the requirements I've heard.
>

Yep... I was thinking about this too... but I am not yet 100% sure it
will solve the problems.

./alex
--
.w( the_mindstorm )p.

> - Charlie
>
> ---------------------------------------------------------------------
> 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]

Joan Pujol schrieb:

> Or you can use the typical   private constructor/static private
> instance/getInstance

Ah yes: For my case, this code must be synchronized. That's why I'm
using "private final static" (automatically and correctly synchronized
by the Java VM).

Using a getInstance would mean that I would have to synchronize it (->
every access would be slow).

And since someone will surely come up with it: This code *does not* work:

private static Type type = null

public static Type getInstance () {
     if (type == null) {
         synchronized (Type.class) {
             if (type == null) {
                 ... create type here ...
             }
         }
     }
     return type
}

See http://www-128.ibm.com/developerworks/java/library/j-dcl.html why
this is dangerous.

Maybe it would really be a good idea to add a "singleton" keyword to
Groovy. And chance this would be implemented?

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

[Tom Nichols]

WOW I never knew that!!!  With the frequency that it's done, I can't
believe I've never heard anyone point out that it doesn't actually
work.  Just wow.

So would this help at all:
http://www.oreillynet.com/onjava/blog/2007/01/singletons_and_lazy_loading.html
or would you still be in the same place?

Thanks for sharing that little gem.
-Tom

On 5/1/07, Aaron Digulla <digulla@...> wrote:

> And since someone will surely come up with it: This code *does not* work:
>
> private static Type type = null
>
> public static Type getInstance () {
>      if (type == null) {
>          synchronized (Type.class) {
>              if (type == null) {
>                  ... create type here ...
>              }
>          }
>      }
>      return type
> }
>
> See http://www-128.ibm.com/developerworks/java/library/j-dcl.html why
> this is dangerous.

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

    http://xircles.codehaus.org/manage_email