Changing the default to CompileStatic

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Changing the default to CompileStatic

Steve Amerige
Is it possible to have @CompileStatic be applied to all compiled code by default with the import of groovy.transform.CompileStatic not being needed in code?

This would then make Groovy a statically-typed language, right?  And, then, just for those specific times when dynamic coding is needed, one could use the @CompileDynamic annotation, right?

If this is possible, can you tell me how?

Many thanks,
Steve Amerige
Principal Software Developer, Fraud and Compliance Solutions Development
SAS Institute, 100 SAS Campus Dr, Room U3050, Cary, NC 27513-8617




Reply | Threaded
Open this post in threaded view
|

Re: Changing the default to CompileStatic

Jochen Theodorou
Am 12.03.2015 16:58, schrieb Steve Amerige:
> Is it possible to have @CompileStatic be applied to all compiled code by
> default with the import of groovy.transform.CompileStatic not being
> needed in code?
>
> This would then make Groovy a statically-typed language, right? And,
> then, just for those specific times when dynamic coding is needed, one
> could use the @CompileDynamic annotation, right?
>
> If this is possible, can you tell me how?

http://groovy.codehaus.org/Advanced+compiler+configuration at the very end.

make a file config.groovy:

withConfig(configuration) {
    ast(groovy.transform.CompileStatic)
}

and then on the commandline do this:

groovyc -configscript src/conf/config.groovy src/main/groovy/MyClass.groovy

for gradle support see
http://gradle.org/docs/2.1/release-notes#groovy-compiler-configuration-script-support

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Changing the default to CompileStatic

keeganwitt
If you're a Maven user, this can also be done with GMavenPlus.  I have an example in the integration tests.

-Keegan

On Thu, Mar 12, 2015 at 12:08 PM, Jochen Theodorou <[hidden email]> wrote:
Am 12.03.2015 16:58, schrieb Steve Amerige:
Is it possible to have @CompileStatic be applied to all compiled code by
default with the import of groovy.transform.CompileStatic not being
needed in code?

This would then make Groovy a statically-typed language, right? And,
then, just for those specific times when dynamic coding is needed, one
could use the @CompileDynamic annotation, right?

If this is possible, can you tell me how?

http://groovy.codehaus.org/Advanced+compiler+configuration at the very end.

make a file config.groovy:

withConfig(configuration) {
   ast(groovy.transform.CompileStatic)
}

and then on the commandline do this:

groovyc -configscript src/conf/config.groovy src/main/groovy/MyClass.groovy

for gradle support see http://gradle.org/docs/2.1/release-notes#groovy-compiler-configuration-script-support

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Changing the default to CompileStatic

Cédric Champeau
In reply to this post by Jochen Theodorou
Same docs, but links to the new website instead (because Codehaus is
often down those days):
http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default

On 12/03/2015 17:08, Jochen Theodorou wrote:

> Am 12.03.2015 16:58, schrieb Steve Amerige:
>> Is it possible to have @CompileStatic be applied to all compiled code by
>> default with the import of groovy.transform.CompileStatic not being
>> needed in code?
>>
>> This would then make Groovy a statically-typed language, right? And,
>> then, just for those specific times when dynamic coding is needed, one
>> could use the @CompileDynamic annotation, right?
>>
>> If this is possible, can you tell me how?
>
> http://groovy.codehaus.org/Advanced+compiler+configuration at the very
> end.
>
> make a file config.groovy:
>
> withConfig(configuration) {
>    ast(groovy.transform.CompileStatic)
> }
>
> and then on the commandline do this:
>
> groovyc -configscript src/conf/config.groovy
> src/main/groovy/MyClass.groovy
>
> for gradle support see
> http://gradle.org/docs/2.1/release-notes#groovy-compiler-configuration-script-support
>
> bye blackdrag
>


--
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Changing the default to CompileStatic

Steve Amerige
In reply to this post by Jochen Theodorou
Hi,

Thanks for the great info!  It seems to me that enterprises might want to compile statically by default and compel developers to annotate with @CompileDynamic for those specific places where dynamic behavior is wanted.  This would address a constant complaint that Groovy is weakly typed and is, therefore, less safe than Java (or other JVM languages such as Scala that are only statically typed).  Other than compelling developers to use the @CompileDynamic annotation, is there any downside to making CompileStatic the default and requiring explicit tagging of dynamic code?

Thanks,
Steve Amerige
Principal Software Developer, Fraud and Compliance Solutions Development
SAS Institute, 100 SAS Campus Dr, Room U3050, Cary, NC 27513-8617



On 3/12/2015 12:08 PM, Jochen Theodorou wrote:
Am 12.03.2015 16:58, schrieb Steve Amerige:
Is it possible to have @CompileStatic be applied to all compiled code by
default with the import of groovy.transform.CompileStatic not being
needed in code?

This would then make Groovy a statically-typed language, right? And,
then, just for those specific times when dynamic coding is needed, one
could use the @CompileDynamic annotation, right?

If this is possible, can you tell me how?

http://groovy.codehaus.org/Advanced+compiler+configuration at the very end.

make a file config.groovy:

withConfig(configuration) {
   ast(groovy.transform.CompileStatic)
}

and then on the commandline do this:

groovyc -configscript src/conf/config.groovy src/main/groovy/MyClass.groovy

for gradle support see http://gradle.org/docs/2.1/release-notes#groovy-compiler-configuration-script-support

bye blackdrag


Reply | Threaded
Open this post in threaded view
|

Re: Changing the default to CompileStatic

Todd Bradley
On Fri, Mar 13, 2015 at 9:11 AM, Steve Amerige <[hidden email]> wrote:
Thanks for the great info!  It seems to me that enterprises might want to compile statically by default and compel developers to annotate with @CompileDynamic for those specific places where dynamic behavior is wanted.  This would address a constant complaint that Groovy is weakly typed and is, therefore, less safe than Java (or other JVM languages such as Scala that are only statically typed).  Other than compelling developers to use the @CompileDynamic annotation, is there any downside to making CompileStatic the default and requiring explicit tagging of dynamic code?

Well, CompileStatic makes it so Spock-based tests don't work. But I guess maybe that falls into the category of "compelling developers to use @CompileDynamic".

Where I work, we're one of those "constant complainers" about Groovy's weak typing. Now that I and my coworkers have been using Groovy for a year, it hasn't really found a foothold in our team for the kind of work we do. Almost nobody who has inhaled deeply has enjoyed it, I'm sad to say.


Cheers,
Todd.

Reply | Threaded
Open this post in threaded view
|

RE: Changing the default to CompileStatic

Corum, Michael

I think it is a philosophy difference.  If you do test-driven development, dynamic languages can be quite pleasant to use.  TDD-style automated tests provide the needed safety nets.  After about 4 and a half years with Groovy, I would be a constant complainer if I were forced back to Java.  I started with Java in 1996 with an early beta so I was very much a Java person before my introduction to Groovy.  At various times in my past, I used Smalltalk or Ruby for small tasks but Groovy was a bit of a leap for me.  Maybe having Java underneath was a form of safety but the static typing was not the good part.  The speed of development and the flexibility of Groovy are not just fun but also contribute to the bottom line.

 

If static typing is a key safety net for you, Groovy may not be your language. 

 

Mike

 

From: Todd Bradley [mailto:[hidden email]]
Sent: Saturday, March 14, 2015 12:13 AM
To: [hidden email]
Subject: Re: [groovy-user] Changing the default to CompileStatic

 

On Fri, Mar 13, 2015 at 9:11 AM, Steve Amerige <[hidden email]> wrote:

Thanks for the great info!  It seems to me that enterprises might want to compile statically by default and compel developers to annotate with @CompileDynamic for those specific places where dynamic behavior is wanted.  This would address a constant complaint that Groovy is weakly typed and is, therefore, less safe than Java (or other JVM languages such as Scala that are only statically typed).  Other than compelling developers to use the @CompileDynamic annotation, is there any downside to making CompileStatic the default and requiring explicit tagging of dynamic code?

 

Well, CompileStatic makes it so Spock-based tests don't work. But I guess maybe that falls into the category of "compelling developers to use @CompileDynamic".

 

Where I work, we're one of those "constant complainers" about Groovy's weak typing. Now that I and my coworkers have been using Groovy for a year, it hasn't really found a foothold in our team for the kind of work we do. Almost nobody who has inhaled deeply has enjoyed it, I'm sad to say.

 

 

Cheers,

Todd.

 

Reply | Threaded
Open this post in threaded view
|

RE: Changing the default to CompileStatic

Henrik Martin-2
In reply to this post by Steve Amerige
This conversation reminds me of the early 90s and the battle between C++ and Smalltalk. At the company I worked for,  the Smalltalk folks wore t-shirts with prints like "strong typing is for weak minds" ;-)



-------- Original message --------
From: "Corum, Michael"
Date:03/13/2015 10:30 PM (GMT-08:00)
Subject: RE: [groovy-user] Changing the default to CompileStatic

I think it is a philosophy difference.  If you do test-driven development, dynamic languages can be quite pleasant to use.  TDD-style automated tests provide the needed safety nets.  After about 4 and a half years with Groovy, I would be a constant complainer if I were forced back to Java.  I started with Java in 1996 with an early beta so I was very much a Java person before my introduction to Groovy.  At various times in my past, I used Smalltalk or Ruby for small tasks but Groovy was a bit of a leap for me.  Maybe having Java underneath was a form of safety but the static typing was not the good part.  The speed of development and the flexibility of Groovy are not just fun but also contribute to the bottom line.

 

If static typing is a key safety net for you, Groovy may not be your language. 

 

Mike

 

From: Todd Bradley [mailto:[hidden email]]
Sent: Saturday, March 14, 2015 12:13 AM
To: [hidden email]
Subject: Re: [groovy-user] Changing the default to CompileStatic

 

On Fri, Mar 13, 2015 at 9:11 AM, Steve Amerige <[hidden email]> wrote:

Thanks for the great info!  It seems to me that enterprises might want to compile statically by default and compel developers to annotate with @CompileDynamic for those specific places where dynamic behavior is wanted.  This would address a constant complaint that Groovy is weakly typed and is, therefore, less safe than Java (or other JVM languages such as Scala that are only statically typed).  Other than compelling developers to use the @CompileDynamic annotation, is there any downside to making CompileStatic the default and requiring explicit tagging of dynamic code?

 

Well, CompileStatic makes it so Spock-based tests don't work. But I guess maybe that falls into the category of "compelling developers to use @CompileDynamic".

 

Where I work, we're one of those "constant complainers" about Groovy's weak typing. Now that I and my coworkers have been using Groovy for a year, it hasn't really found a foothold in our team for the kind of work we do. Almost nobody who has inhaled deeply has enjoyed it, I'm sad to say.

 

 

Cheers,

Todd.

 

OC
Reply | Threaded
Open this post in threaded view
|

Re: Changing the default to CompileStatic

OC
Actually it is technically possible to have a „reasonably strong typing to catch most typos etc“ along with „full-fledged dynamic system like Smalltalk“. E.g. ObjC does that (or at least did before ARC, dot syntax for accessors and closures were added).

The standard design of Groovy typechecker alas strives to be theoretically perfect, not practically useable (with dynamic code).

Luckily, it is flexible enough to allow us to fixing that all; it's a lot of work though, and I'm still not quite finished with that :/

Just for the fun, you might e.g., check the following message (and possibly the looong thread around it):

http://groovy.329449.n5.nabble.com/Static-type-checking-def-trouble-tp5712912p5712948.html

All the best,
OC

On 14. 3. 2015, at 7:55, Henrik Martin <[hidden email]> wrote:

> This conversation reminds me of the early 90s and the battle between C++ and Smalltalk. At the company I worked for,  the Smalltalk folks wore t-shirts with prints like "strong typing is for weak minds" ;-)
>
>
>
> -------- Original message --------
> From: "Corum, Michael"
> Date:03/13/2015 10:30 PM (GMT-08:00)
> To: [hidden email]
> Subject: RE: [groovy-user] Changing the default to CompileStatic
>
> I think it is a philosophy difference.  If you do test-driven development, dynamic languages can be quite pleasant to use.  TDD-style automated tests provide the needed safety nets.  After about 4 and a half years with Groovy, I would be a constant complainer if I were forced back to Java.  I started with Java in 1996 with an early beta so I was very much a Java person before my introduction to Groovy.  At various times in my past, I used Smalltalk or Ruby for small tasks but Groovy was a bit of a leap for me.  Maybe having Java underneath was a form of safety but the static typing was not the good part.  The speed of development and the flexibility of Groovy are not just fun but also contribute to the bottom line.
>
>  
>
> If static typing is a key safety net for you, Groovy may not be your language.
>
>  
>
> Mike
>
>  
>
> From: Todd Bradley [mailto:[hidden email]]
> Sent: Saturday, March 14, 2015 12:13 AM
> To: [hidden email]
> Subject: Re: [groovy-user] Changing the default to CompileStatic
>
>  
>
> On Fri, Mar 13, 2015 at 9:11 AM, Steve Amerige <[hidden email]> wrote:
>
> Thanks for the great info!  It seems to me that enterprises might want to compile statically by default and compel developers to annotate with @CompileDynamic for those specific places where dynamic behavior is wanted.  This would address a constant complaint that Groovy is weakly typed and is, therefore, less safe than Java (or other JVM languages such as Scala that are only statically typed).  Other than compelling developers to use the @CompileDynamic annotation, is there any downside to making CompileStatic the default and requiring explicit tagging of dynamic code?
>
>  
>
> Well, CompileStatic makes it so Spock-based tests don't work. But I guess maybe that falls into the category of "compelling developers to use @CompileDynamic".
>
>  
>
> Where I work, we're one of those "constant complainers" about Groovy's weak typing. Now that I and my coworkers have been using Groovy for a year, it hasn't really found a foothold in our team for the kind of work we do. Almost nobody who has inhaled deeply has enjoyed it, I'm sad to say.
>
>  
>
>  
>
> Cheers,
>
> Todd.
>
>  
>


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Changing the default to CompileStatic

Todd Bradley
In reply to this post by Corum, Michael
Yes, Mike, I agree with you. Obviously it's a great language for many applications, but apparently not ours.

We decided to try Groovy for developing black box integration/system tests. The software we're testing is written in Java and unit tested in Java (that's irrelevant to our integration tests, but I mention it just for context). Based on the strengths of Spock, we decided to try Groovy/Spock for integration tests.

Now in hindsight, I can see why it wasn't such a great choice. Unit tests are small in scope, and quick to run. But these system tests are much bigger. Some of them may take five minutes or even an hour to run. In fact, some run for several hours. In the Java world, we eliminate stupid mistakes like typos at compile time, but with our Groovy/Spock tests those stupid mistakes in the test code aren't revealed until run time, typically half an hour later. This slow feedback loop is bad. The normal solution to this sort of issue would be to write more unit tests. But in our case our "application" is these long-running Spock test cases, and writing automated tests that test other automated tests is weird, awkward, and unpopular.

So, in summary, for at least this specific purpose, we seem to need that static typing safety net. And Henrik, I do hope this doesn't sound too much like the C++/Smalltalk wars. Nobody's trying to have a religious argument, as far as I can tell.


Cheers,
Todd.




On Fri, Mar 13, 2015 at 11:30 PM, Corum, Michael <[hidden email]> wrote:

I think it is a philosophy difference.  If you do test-driven development, dynamic languages can be quite pleasant to use.  TDD-style automated tests provide the needed safety nets.  After about 4 and a half years with Groovy, I would be a constant complainer if I were forced back to Java.  I started with Java in 1996 with an early beta so I was very much a Java person before my introduction to Groovy.  At various times in my past, I used Smalltalk or Ruby for small tasks but Groovy was a bit of a leap for me.  Maybe having Java underneath was a form of safety but the static typing was not the good part.  The speed of development and the flexibility of Groovy are not just fun but also contribute to the bottom line.

 

If static typing is a key safety net for you, Groovy may not be your language. 

 

Mike

 

From: Todd Bradley [mailto:[hidden email]]
Sent: Saturday, March 14, 2015 12:13 AM
To: [hidden email]
Subject: Re: [groovy-user] Changing the default to CompileStatic

 

On Fri, Mar 13, 2015 at 9:11 AM, Steve Amerige <[hidden email]> wrote:

Thanks for the great info!  It seems to me that enterprises might want to compile statically by default and compel developers to annotate with @CompileDynamic for those specific places where dynamic behavior is wanted.  This would address a constant complaint that Groovy is weakly typed and is, therefore, less safe than Java (or other JVM languages such as Scala that are only statically typed).  Other than compelling developers to use the @CompileDynamic annotation, is there any downside to making CompileStatic the default and requiring explicit tagging of dynamic code?

 

Well, CompileStatic makes it so Spock-based tests don't work. But I guess maybe that falls into the category of "compelling developers to use @CompileDynamic".

 

Where I work, we're one of those "constant complainers" about Groovy's weak typing. Now that I and my coworkers have been using Groovy for a year, it hasn't really found a foothold in our team for the kind of work we do. Almost nobody who has inhaled deeply has enjoyed it, I'm sad to say.

 

 

Cheers,

Todd.

 


12