Groovy runs code in static initializers during compile

[Scott Hickey-3]

Might be misplaced trust but we use Spring as factory for our Groovy singletons to avoid all of the well documented issues around Java singletons.
 
Scott

----- Original Message ----
From: Aaron Digulla <digulla@...>
To: dev@...
Sent: Tuesday, May 1, 2007 2:28:02 PM
Subject: Re: [groovy-dev] Groovy runs code in static initializers during compile

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





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

    http://xircles.codehaus.org/manage_email

[Charles Oliver Nutter-2]

Aaron Digulla wrote:

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

Every access will be "slower" but by such a tiny amount I don't think
you should worry about it, especially in the context of a dynlang that's
already much slower than Java. The truth is that yes, double-check
locking is broken and you have to synchronize every time, but it doesn't
really matter anymore. The JVM is superb about optimizing
synchronization now, and very rarely does it even impact performance. In
many cases, it doesn't even bother to synchronize unless multiple
threads actually access at the same time.

Just do the synchronization and avoid cute tricks.

- Charlie


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

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Quoting Scott Hickey <jshickey@...>:

> Might be misplaced trust but we use Spring as factory for our Groovy  
>  singletons to avoid all of the well documented issues around Java  
> singletons.

So what do I do when I'd like to avoid the overhead to setup Spring?

Currently, my tests run in 12.37s. When I add Spring, that goes up for  
4-5s just for loading the XML config and preparing everything, which  
is 30% overhead. IMHO, Spring shows all the weaknesses of Java but it  
tries to implement the solution in Java which gives a kind of  
Munchhausen effect and pollutes the solution.

Spring Java Config is a big step to improve the load times but it  
still doesn't solve all the issues. That's why I'd like a solution  
built into Groovy. A Singleton pattern which is easily recognizable,  
can be overridden for tests and avoids all the pitfalls. I was  
thinking along these lines:

singleton class Foo
{
     int y
     public Foo () { this.y = 1 }
     def x () { this.y }
}

assert Foo.x () == 1
try {
     def f = new Foo ()
     assert false, 'No Exception was thrown'
} catch (SingletonException e) {
     assert e.message == 'Class Foo is a singleton and cannot be instantiated'
}

This basically makes all methods in Foo "static": Groovy should create  
a single instance of this class when the first method is called and  
then use this instance of every call after that. For tests, we need  
another keyword:

class Test extends GroovyTestCase
{
     void setUp () {
         override singleton Foo = ...
     }
}

On the RHS of the assignment can be a class (which must extend Foo), a  
method (which must return a class that extends Foo) or a closure (same  
as method).

An extended syntax might be:

     override singleton Foo.x { 2 }
     assert Foo.x() == 2

Comments?

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 Tom Nichols <tmnichols@...>:

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

I didn't see any comment which suggests otherwise, so I guess it  
should work, at least with a Sun VM. AFAIK, the IBM VM uses a  
different scheme to synchronize classloading but even it should make  
sure that only one thread at a time loads a certain class (I think  
with the IBM VM, you can have the case that several threads load  
*different* classes at the same time).

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 Charles Oliver Nutter <charles.nutter@...>:

> Just do the synchronization and avoid cute tricks.

I agree with you 90% :-) The problem is that I run Java near the edge.  
I have a webapp here which returns a 2MB document. IE takes 45s just  
for the div.innerHTML assignment :-( On the Java side, I have a  
singleton method which is called 200'000 times for this document. If  
synchronization takes more than a few microseconds, it quickly adds  
up. In the end, the real problem is that Java poorly supports the  
singleton pattern. There should be a simple to way to say "run this  
code only once". As it is, you either have synchronization problems or  
you cannot override the singleton for tests.

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]

Aaron Digulla wrote:

> Quoting Charles Oliver Nutter <charles.nutter@...>:
>
>> Just do the synchronization and avoid cute tricks.
>
> I agree with you 90% :-) The problem is that I run Java near the edge. I
> have a webapp here which returns a 2MB document. IE takes 45s just for
> the div.innerHTML assignment :-( On the Java side, I have a singleton
> method which is called 200'000 times for this document. If
> synchronization takes more than a few microseconds, it quickly adds up.
> In the end, the real problem is that Java poorly supports the singleton
> pattern. There should be a simple to way to say "run this code only
> once". As it is, you either have synchronization problems or you cannot
> override the singleton for tests.

Have you actually seen that sync versus no sync makes a difference here?
Synchronization might take a few milliseconds, but only if HotSpot
actually decides to do it. In many (most?) cases it's able to determine
that it's not necessary.

Perhaps the problem is more about the 200,000 hits than whether the
singleton access is synchronized or not?

- Charlie

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

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

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

> Have you actually seen that sync versus no sync makes a difference
> here? Synchronization might take a few milliseconds, but only if
> HotSpot actually decides to do it. In many (most?) cases it's able to
> determine that it's not necessary.

The test-and-set operation is still expensive and it's not necessary  
if GCL would create the singletons. It would be a clean, fast and  
cheap solution that would always work.

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 5/2/07, Aaron Digulla <digulla@...> wrote:

> Quoting Charles Oliver Nutter <charles.nutter@...>:
>
> > Have you actually seen that sync versus no sync makes a difference
> > here? Synchronization might take a few milliseconds, but only if
> > HotSpot actually decides to do it. In many (most?) cases it's able to
> > determine that it's not necessary.
>
> The test-and-set operation is still expensive and it's not necessary
> if GCL would create the singletons. It would be a clean, fast and
> cheap solution that would always work.
>

I really think there are better argument then the one I will find to
proove that singletons cannot work safely, concurrently and
distributed (and I am assuming this because I haven't seen them in any
language).

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

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

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

    http://xircles.codehaus.org/manage_email

[Marcelo Fukushima]

i think the JLS guarantees that behaviour


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

> Quoting Tom Nichols <tmnichols@...>:
>
> > 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?
>
> I didn't see any comment which suggests otherwise, so I guess it
> should work, at least with a Sun VM. AFAIK, the IBM VM uses a
> different scheme to synchronize classloading but even it should make
> sure that only one thread at a time loads a certain class (I think
> with the IBM VM, you can have the case that several threads load
> *different* classes at the same time).
>
> 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
>
>

--
[]'s
Marcelo Takeshi Fukushima

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

    http://xircles.codehaus.org/manage_email

[Scott Hickey-3]

It sounds like your trying to manage test configuration and production configuration in your application code.

On our project, we have a prod-spring-config.xml and test-spring-config.xml . They both include a common-spring-config.xml .

In our unit test superclass, we specify the test-spring-config.xml. In that file, we wire can wire our beans with local jdbc connection for unit testing. We also built one of our high-overhead classes with a lazy-load flag that gets overriden to true using constructor injection with Spring. All of our tests don't run in 15 seconds so the Spring overhead isn't an issue. I think Spring was designed to solve exactly the issues you're running into.
 
Scott

----- Original Message ----
From: Aaron Digulla <digulla@...>
To: dev@...
Sent: Wednesday, May 2, 2007 3:05:21 AM
Subject: Re: [groovy-dev] Groovy runs code in static initializers during compile

Quoting Scott Hickey <jshickey@...>:

> Might be misplaced trust but we use Spring as factory for our Groovy  
>  singletons to avoid all of the well documented issues around Java  
> singletons.

So what do I do when I'd like to avoid the overhead to setup Spring?

Currently, my tests run in 12.37s. When I add Spring, that goes up for  
4-5s just for loading the XML config and preparing everything, which  
is 30% overhead. IMHO, Spring shows all the weaknesses of Java but it  
tries to implement the solution in Java which gives a kind of  
Munchhausen effect and pollutes the solution.

Spring Java Config is a big step to improve the load times but it  
still doesn't solve all the issues. That's why I'd like a solution  
built into Groovy. A Singleton pattern which is easily recognizable,  
can be overridden for tests and avoids all the pitfalls. I was  
thinking along these lines:

singleton class Foo
{
     int y
     public Foo () { this.y = 1 }
     def x () { this.y }
}

assert Foo.x () == 1
try {
     def f = new Foo ()
     assert false, 'No Exception was thrown'
} catch (SingletonException e) {
     assert e.message == 'Class Foo is a singleton and cannot be instantiated'
}

This basically makes all methods in Foo "static": Groovy should create  
a single instance of this class when the first method is called and  
then use this instance of every call after that. For tests, we need  
another keyword:

class Test extends GroovyTestCase
{
     void setUp () {
         override singleton Foo = ...
     }
}

On the RHS of the assignment can be a class (which must extend Foo), a  
method (which must return a class that extends Foo) or a closure (same  
as method).

An extended syntax might be:

     override singleton Foo.x { 2 }
     assert Foo.x() == 2

Comments?

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





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

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Quoting Alexandru Popescu ? <the.mindstorm.mailinglist@...>:

>> The test-and-set operation is still expensive and it's not necessary
>> if GCL would create the singletons. It would be a clean, fast and
>> cheap solution that would always work.
>
> I really think there are better argument then the one I will find to
> proove that singletons cannot work safely, concurrently and
> distributed (and I am assuming this because I haven't seen them in any
> language).

Just because it's hard, it's not impossible :-)

Singletons in other dynamic languages: Python  
(http://www.garyrobinson.net/singletonmixin.py), Ruby:  
(http://cwilliams.textdriven.com/articles/2006/10/31/patterns-in-ruby-singleton-pattern)

They have some advantages, though: In Python, every term (for example,  
an assignment, a statement, etc.) is atomic. The built-in  
multi-threading will only switch between terms. In Ruby, it's more  
simple to dynamically modify the class itself (similar to Groovy's  
MetaClass concept but less restrictions).

My key issue is: Singletons are mindbendingly hard in Java, riddled  
with errors and pitfalls and if we can, we should solve this. If we  
can add support in Groovy, all bugs can be fixed in a single place  
instead of finding, after you've written 100'000 KLOCs, that you've  
used a faulty pattern.

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

[graemer]

Sounds like you need to be using Grails with all of our Spring config
DSL, you don't need multiple config files ;-)

Cheers

On 5/2/07, Scott Hickey <jshickey@...> wrote:

> It sounds like your trying to manage test configuration and production configuration in your application code.
>
> On our project, we have a prod-spring-config.xml and test-spring-config.xml . They both include a common-spring-config.xml .
>
> In our unit test superclass, we specify the test-spring-config.xml. In that file, we wire can wire our beans with local jdbc connection for unit testing. We also built one of our high-overhead classes with a lazy-load flag that gets overriden to true using constructor injection with Spring. All of our tests don't run in 15 seconds so the Spring overhead isn't an issue. I think Spring was designed to solve exactly the issues you're running into.
>
> Scott
>
> ----- Original Message ----
> From: Aaron Digulla <digulla@...>
> To: dev@...
> Sent: Wednesday, May 2, 2007 3:05:21 AM
> Subject: Re: [groovy-dev] Groovy runs code in static initializers during compile
>
> Quoting Scott Hickey <jshickey@...>:
>
> > Might be misplaced trust but we use Spring as factory for our Groovy
> >  singletons to avoid all of the well documented issues around Java
> > singletons.
>
> So what do I do when I'd like to avoid the overhead to setup Spring?
>
> Currently, my tests run in 12.37s. When I add Spring, that goes up for
> 4-5s just for loading the XML config and preparing everything, which
> is 30% overhead. IMHO, Spring shows all the weaknesses of Java but it
> tries to implement the solution in Java which gives a kind of
> Munchhausen effect and pollutes the solution.
>
> Spring Java Config is a big step to improve the load times but it
> still doesn't solve all the issues. That's why I'd like a solution
> built into Groovy. A Singleton pattern which is easily recognizable,
> can be overridden for tests and avoids all the pitfalls. I was
> thinking along these lines:
>
> singleton class Foo
> {
>      int y
>      public Foo () { this.y = 1 }
>      def x () { this.y }
> }
>
> assert Foo.x () == 1
> try {
>      def f = new Foo ()
>      assert false, 'No Exception was thrown'
> } catch (SingletonException e) {
>      assert e.message == 'Class Foo is a singleton and cannot be instantiated'
> }
>
> This basically makes all methods in Foo "static": Groovy should create
> a single instance of this class when the first method is called and
> then use this instance of every call after that. For tests, we need
> another keyword:
>
> class Test extends GroovyTestCase
> {
>      void setUp () {
>          override singleton Foo = ...
>      }
> }
>
> On the RHS of the assignment can be a class (which must extend Foo), a
> method (which must return a class that extends Foo) or a closure (same
> as method).
>
> An extended syntax might be:
>
>      override singleton Foo.x { 2 }
>      assert Foo.x() == 2
>
> Comments?
>
> 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
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Graeme Rocher
Grails Project Lead
http://grails.org

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

    http://xircles.codehaus.org/manage_email

[Scott Hickey-3]

It's not a web app. Can I get SpringBuilder without Grails?
 
Scott

----- Original Message ----
From: Graeme Rocher <graemerocher@...>
To: dev@...
Sent: Wednesday, May 2, 2007 10:11:29 AM
Subject: Re: [groovy-dev] Groovy runs code in static initializers during compile

Sounds like you need to be using Grails with all of our Spring config
DSL, you don't need multiple config files ;-)

Cheers

On 5/2/07, Scott Hickey <jshickey@...> wrote:

> It sounds like your trying to manage test configuration and production configuration in your application code.
>
> On our project, we have a prod-spring-config.xml and test-spring-config.xml . They both include a common-spring-config.xml .
>
> In our unit test superclass, we specify the test-spring-config.xml. In that file, we wire can wire our beans with local jdbc connection for unit testing. We also built one of our high-overhead classes with a lazy-load flag that gets overriden to true using constructor injection with Spring. All of our tests don't run in 15 seconds so the Spring overhead isn't an issue. I think Spring was designed to solve exactly the issues you're running into.
>
> Scott
>
> ----- Original Message ----
> From: Aaron Digulla <digulla@...>
> To: dev@...
> Sent: Wednesday, May 2, 2007 3:05:21 AM
> Subject: Re: [groovy-dev] Groovy runs code in static initializers during compile
>
> Quoting Scott Hickey <jshickey@...>:
>
> > Might be misplaced trust but we use Spring as factory for our Groovy
> >  singletons to avoid all of the well documented issues around Java
> > singletons.
>
> So what do I do when I'd like to avoid the overhead to setup Spring?
>
> Currently, my tests run in 12.37s. When I add Spring, that goes up for
> 4-5s just for loading the XML config and preparing everything, which
> is 30% overhead. IMHO, Spring shows all the weaknesses of Java but it
> tries to implement the solution in Java which gives a kind of
> Munchhausen effect and pollutes the solution.
>
> Spring Java Config is a big step to improve the load times but it
> still doesn't solve all the issues. That's why I'd like a solution
> built into Groovy. A Singleton pattern which is easily recognizable,
> can be overridden for tests and avoids all the pitfalls. I was
> thinking along these lines:
>
> singleton class Foo
> {
>      int y
>      public Foo () { this.y = 1 }
>      def x () { this.y }
> }
>
> assert Foo.x () == 1
> try {
>      def f = new Foo ()
>      assert false, 'No Exception was thrown'
> } catch (SingletonException e) {
>      assert e.message == 'Class Foo is a singleton and cannot be instantiated'
> }
>
> This basically makes all methods in Foo "static": Groovy should create
> a single instance of this class when the first method is called and
> then use this instance of every call after that. For tests, we need
> another keyword:
>
> class Test extends GroovyTestCase
> {
>      void setUp () {
>          override singleton Foo = ...
>      }
> }
>
> On the RHS of the assignment can be a class (which must extend Foo), a
> method (which must return a class that extends Foo) or a closure (same
> as method).
>
> An extended syntax might be:
>
>      override singleton Foo.x { 2 }
>      assert Foo.x() == 2
>
> Comments?
>
> 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
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--
Graeme Rocher
Grails Project Lead
http://grails.org

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

[graemer]

Yes it can, you just need to grails-core-0.5.jar JAR obtainable from
http://dist.codehaus.org/grails/

Then just use the BeanBuilder class as per:
http://grails.org/Spring+Bean+Builder

You can have logic that does stuff like:

def beans = new BeanBuilder()

if(environment == "development") {
    bb.dataSource(org.apache.commons.dbcp.BasicDataSource) {
                    driverClassName = "org.hsqldb.jdbcDriver"
                    url =  "jdbc:hsqldb:mem:grailsDB"
                    username = "sa"
                    password =  ""
            }
}
else {
  // production data source here
}

def applicationContext = bb.createApplicationContext()

Cheers

On 5/2/07, Scott Hickey <jshickey@...> wrote:

> It's not a web app. Can I get SpringBuilder without Grails?
>
> Scott
>
> ----- Original Message ----
> From: Graeme Rocher <graemerocher@...>
> To: dev@...
> Sent: Wednesday, May 2, 2007 10:11:29 AM
> Subject: Re: [groovy-dev] Groovy runs code in static initializers during compile
>
> Sounds like you need to be using Grails with all of our Spring config
> DSL, you don't need multiple config files ;-)
>
> Cheers
>
> On 5/2/07, Scott Hickey <jshickey@...> wrote:
> > It sounds like your trying to manage test configuration and production configuration in your application code.
> >
> > On our project, we have a prod-spring-config.xml and test-spring-config.xml . They both include a common-spring-config.xml .
> >
> > In our unit test superclass, we specify the test-spring-config.xml. In that file, we wire can wire our beans with local jdbc connection for unit testing. We also built one of our high-overhead classes with a lazy-load flag that gets overriden to true using constructor injection with Spring. All of our tests don't run in 15 seconds so the Spring overhead isn't an issue. I think Spring was designed to solve exactly the issues you're running into.
> >
> > Scott
> >
> > ----- Original Message ----
> > From: Aaron Digulla <digulla@...>
> > To: dev@...
> > Sent: Wednesday, May 2, 2007 3:05:21 AM
> > Subject: Re: [groovy-dev] Groovy runs code in static initializers during compile
> >
> > Quoting Scott Hickey <jshickey@...>:
> >
> > > Might be misplaced trust but we use Spring as factory for our Groovy
> > >  singletons to avoid all of the well documented issues around Java
> > > singletons.
> >
> > So what do I do when I'd like to avoid the overhead to setup Spring?
> >
> > Currently, my tests run in 12.37s. When I add Spring, that goes up for
> > 4-5s just for loading the XML config and preparing everything, which
> > is 30% overhead. IMHO, Spring shows all the weaknesses of Java but it
> > tries to implement the solution in Java which gives a kind of
> > Munchhausen effect and pollutes the solution.
> >
> > Spring Java Config is a big step to improve the load times but it
> > still doesn't solve all the issues. That's why I'd like a solution
> > built into Groovy. A Singleton pattern which is easily recognizable,
> > can be overridden for tests and avoids all the pitfalls. I was
> > thinking along these lines:
> >
> > singleton class Foo
> > {
> >      int y
> >      public Foo () { this.y = 1 }
> >      def x () { this.y }
> > }
> >
> > assert Foo.x () == 1
> > try {
> >      def f = new Foo ()
> >      assert false, 'No Exception was thrown'
> > } catch (SingletonException e) {
> >      assert e.message == 'Class Foo is a singleton and cannot be instantiated'
> > }
> >
> > This basically makes all methods in Foo "static": Groovy should create
> > a single instance of this class when the first method is called and
> > then use this instance of every call after that. For tests, we need
> > another keyword:
> >
> > class Test extends GroovyTestCase
> > {
> >      void setUp () {
> >          override singleton Foo = ...
> >      }
> > }
> >
> > On the RHS of the assignment can be a class (which must extend Foo), a
> > method (which must return a class that extends Foo) or a closure (same
> > as method).
> >
> > An extended syntax might be:
> >
> >      override singleton Foo.x { 2 }
> >      assert Foo.x() == 2
> >
> > Comments?
> >
> > 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
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
>
> --
> Graeme Rocher
> Grails Project Lead
> http://grails.org
>
> ---------------------------------------------------------------------
> 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
>
>

--
Graeme Rocher
Grails Project Lead
http://grails.org

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

    http://xircles.codehaus.org/manage_email

[Aaron Digulla]

Quoting Scott Hickey <jshickey@...>:

> It sounds like your trying to manage test configuration and  
> production configuration in your application code.

Exactly. I just can't use Spring because that would be too expensive.

And there are corner cases, which Spring just can't handle. For  
example, I have a test case which gets a "read only" database  
connection (the connection will rollback after the test). So for my  
current project, I would probably need > 20 config files (one for each  
test, sometimes five).

Right now, I can see what's going on in one place. Everything is  
local. All objects are sealed and don't know much about each other.  
Debugging is simple. When I add Spring to this, I'd get a nightmare in  
XML, slower startup times, and all the information would spread all  
over the place.

Plus I'd need to define 200 interface classes, so I could even do the wiring.

Conclusion: Spring isn't a solution in my book. It just gave us an  
idea of the hell in which we were living without noticing. Projects  
like Rails show that you can do without an injection framework, AOP  
and all this crap. If Groovy can't match that, Ruby will win.

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 Graeme Rocher <graemerocher@...>:

> Sounds like you need to be using Grails with all of our Spring config
> DSL, you don't need multiple config files ;-)

I hope to have a look at grails this week. I've just finished writing  
20KLOC of code in two months in Groovy+GWT (two completely new tools  
for me) and I'm starting to cool down, now :-)

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 Guillaume Laforge <glaforge@...>:

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

They wrote their own code to examine classes. Here is the reply:

-----------------------------------------------------------------
The Eclipse Java compiler, like most Java compilers, reads .java files, and
it reads .class files if necessary to get information about already-compiled
classes.  To get a sense of how it thinks about code, take a look at the
classes in org.eclipse.jdt.internal.compiler.*, in the org.eclipse.jdt.core
plug-in.  It doesn't use reflection, and it doesn't load classes at all
(except for the classes that make up its own implementation).  The language
of the compiler is unrelated to the language of the code being compiled,
except that they happen to be the same.  Indeed, the first Java compilers
were not written in Java and did not run on Java virtual machines; I think
the compiler that eventually became Eclipse started out written in
Smalltalk, although I might be mistaken about that.

Compilers do not in general load user code, for reasons exactly such as the
one you encountered.  It's also in general unnecessary and unsafe, not to
mention that it causes bad performance.  It would create the potential for
classloader conflicts, if the user code had a class whose name and package
were the same as one of the compiler implementation classes.  And in the
case of compiling for a different platform than what you're running on, it
could simply be impossible.

And imagine if, instead of throwing an exception, your code actually *did*
something, like say formatting a hard drive or withdrawing the cesium rods
from the reactor.  (Hey, don't laugh, somewhere that code must exist, right?
They don't use a big hand crank.)  "Uh, sorry about the meltdown, boss, I
was just trying to compile some test code, and I guess the compiler must
have loaded and executed the classes in the reactor controller jar file."
-----------------------------------------------------------------

(http://www.eclipse.org/newsportal/article.php?id=20544&group=eclipse.tools.jdt#20544, password  
protected).

I find the "bad performance" interesting.

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]

Interesting.
Perhaps we could reuse ASM for super-fast crawling in class files to
find all the relevant information we need.

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

> Quoting Guillaume Laforge <glaforge@...>:
>
> >> 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.
>
> They wrote their own code to examine classes. Here is the reply:
>
> -----------------------------------------------------------------
> The Eclipse Java compiler, like most Java compilers, reads .java files, and
> it reads .class files if necessary to get information about already-compiled
> classes.  To get a sense of how it thinks about code, take a look at the
> classes in org.eclipse.jdt.internal.compiler.*, in the org.eclipse.jdt.core
> plug-in.  It doesn't use reflection, and it doesn't load classes at all
> (except for the classes that make up its own implementation).  The language
> of the compiler is unrelated to the language of the code being compiled,
> except that they happen to be the same.  Indeed, the first Java compilers
> were not written in Java and did not run on Java virtual machines; I think
> the compiler that eventually became Eclipse started out written in
> Smalltalk, although I might be mistaken about that.
>
> Compilers do not in general load user code, for reasons exactly such as the
> one you encountered.  It's also in general unnecessary and unsafe, not to
> mention that it causes bad performance.  It would create the potential for
> classloader conflicts, if the user code had a class whose name and package
> were the same as one of the compiler implementation classes.  And in the
> case of compiling for a different platform than what you're running on, it
> could simply be impossible.
>
> And imagine if, instead of throwing an exception, your code actually *did*
> something, like say formatting a hard drive or withdrawing the cesium rods
> from the reactor.  (Hey, don't laugh, somewhere that code must exist, right?
> They don't use a big hand crank.)  "Uh, sorry about the meltdown, boss, I
> was just trying to compile some test code, and I guess the compiler must
> have loaded and executed the classes in the reactor controller jar file."
> -----------------------------------------------------------------
>
> (http://www.eclipse.org/newsportal/article.php?id=20544&group=eclipse.tools.jdt#20544, password
> protected).
>
> I find the "bad performance" interesting.
>
> 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

[Scott Hickey-3]

I'm not following the multiple config files for each test. We don't have that issue and we have about 900 JUnit tests in all.

I just have to say that I had some of the same fears before I used it. Now, I wouldn't work on a Java project without Spring. I've stopped writing factory classes. For me, in practice, once the wiring is done, I don't really look at it again. Debugging hasn't been an issue but maybe I've just been lucky. Having Spring as my factory made it really easy to do a little AOP without AspectJ or writing my dynamic proxy classes.

My objects don't know about each other either. And with Groovy, no interfaces! It's actually been a great combination.

Just my two cents worth from using it on my project.

Scott

----- Original Message ----
From: Aaron Digulla <digulla@...>
To: dev@...
Sent: Wednesday, May 2, 2007 10:52:30 AM
Subject: Re: [groovy-dev] Groovy runs code in static initializers during compile

Quoting Scott Hickey <jshickey@...>:

> It sounds like your trying to manage test configuration and  
> production configuration in your application code.

Exactly. I just can't use Spring because that would be too expensive.

And there are corner cases, which Spring just can't handle. For  
example, I have a test case which gets a "read only" database  
connection (the connection will rollback after the test). So for my  
current project, I would probably need > 20 config files (one for each  
test, sometimes five).

Right now, I can see what's going on in one place. Everything is  
local. All objects are sealed and don't know much about each other.  
Debugging is simple. When I add Spring to this, I'd get a nightmare in  
XML, slower startup times, and all the information would spread all  
over the place.

Plus I'd need to define 200 interface classes, so I could even do the wiring.

Conclusion: Spring isn't a solution in my book. It just gave us an  
idea of the hell in which we were living without noticing. Projects  
like Rails show that you can do without an injection framework, AOP  
and all this crap. If Groovy can't match that, Ruby will win.

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





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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Guillaume Laforge schrieb:
> Interesting.
> Perhaps we could reuse ASM for super-fast crawling in class files to
> find all the relevant information we need.

then we need two modes, compilation from files and compilation from
unknown sources. If compiled from files the compiler can expect to find
a .class file for each class and will use getRessource to find that
file. In the other case the compiler will use loadClass, as it does
already... I think we can control that through the compiler
configuration. The default for groovyc would be to compile from files
and the default for compiling during runtime would be to load the class
if a .class file was not found. What do you think?

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