[groovy-dev] GroovyJavaCompiler from Commons JCI

Hi developers,

I ran across this:

http://jakarta.apache.org/commons/sandbox/jci/index.html

And started to wonder if this project might be of use to the groovy
project for compiling groovy classes to byte code.  I've not gone deep
into this, but there appears to be a GroovyJavaCompiler thing, and there
are various ClassLoaders for compiling.  Given that it is in the sandbox
still, I don't know if it is working or not...

Recalling my previous post on the list regarding problems with
classloaders and compiling with the groovyc ant task (and the eclipse
plugin); the above project might be useful in solving these problems, or
it might not??

Thanks for the attention,

Hein

Re: [groovy-dev] GroovyJavaCompiler from Commons JCI

Hi Hein,

> And started to wonder if this project might be of use to the groovy
> project for compiling groovy classes to byte code.  I've not gone deep
> into this, but there appears to be a GroovyJavaCompiler thing, and there
> are various ClassLoaders for compiling.  Given that it is in the sandbox
> still, I don't know if it is working or not...

Seeing
http://svn.apache.org/repos/asf/jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/compilers/groovy/GroovyJavaCompiler.java
it's probably not quite ready for consumption.

> Recalling my previous post on the list regarding problems with
> classloaders and compiling with the groovyc ant task (and the eclipse
> plugin); the above project might be useful in solving these problems, or
> it might not??

I didn't follow your conversation with Jochen too closely, but in GroovyJ (the
IDEA plug-in), most classloading problems were fixed by creating a
URLClassLoader based on the classpath of a given module, see:

http://cvs.codehaus.org/viewrep/groovy/groovy/ide/groovyj/src/java/org/codehaus/groovy/intellij/compiler/GroovyCompiler.java?r=HEAD#l140

Regards,

Franck

Re: [groovy-dev] GroovyJavaCompiler from Commons JCI

On Wed, 2005-08-03 at 06:08 -0700, Franck Rasolo wrote:
> Seeing
> http://svn.apache.org/repos/asf/jakarta/commons/sandbox/jci/trunk/src/java/org/apache/commons/jci/compilers/groovy/GroovyJavaCompiler.java
> it's probably not quite ready for consumption.

Yes I noticed after sending the mail.

> > Recalling my previous post on the list regarding problems with
> > classloaders and compiling with the groovyc ant task (and the eclipse
> > plugin); the above project might be useful in solving these problems, or
> > it might not??
> 
> I didn't follow your conversation with Jochen too closely, but in GroovyJ (the
> IDEA plug-in), most classloading problems were fixed by creating a
> URLClassLoader based on the classpath of a given module, see:
> 
> http://cvs.codehaus.org/viewrep/groovy/groovy/ide/groovyj/src/java/org/codehaus/groovy/intellij/compiler/GroovyCompiler.java?r=HEAD#l140

Thanks.  That's interesting.  Once my workload is lighter, I'll have a
look at the eclipse plugin and see if I can do a similar trick.

Hein

[groovy-dev] NullPointerException accessing variable outside closure

Sorry if this is a dupe, but I just wanted to submit some code to
exercise a bug in variable scoping (I think it's a bug).  I've assigned
to a variable inside an anonymous closure.  Then subsequently I assign
to a variable of the same name outside the closure, causing a
NullPointerException.  I am running groovy-1.0-jsr-02 on jdk1.5.0_03 on
Windows.

graham

// begin groovy code
[1].each( { myVariable = it; } )
myVariable = 8;

This message is intended only for the personal and confidential use of the designated recipient(s) named
above. If you are not the intended recipient of this message you are hereby notified that any review,
dissemination, distribution or copying of this message is strictly prohibited. This communication is
for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer
to buy any financial product, an official confirmation of any transaction, or as an official statement of
Del Mar Asset Management. Email transmission cannot be guaranteed to be secure or error-free.
Therefore, we do not represent that this information is complete or accurate and it should not be relied
upon as such. All information is subject to change without notice. 

Re: [groovy-dev] NullPointerException accessing variable outside closure

Hi Graham,

On 04/08/05, Graham Miller <gmiller@...> wrote:
> Sorry if this is a dupe, but I just wanted to submit some code to
> exercise a bug in variable scoping (I think it's a bug).  I've assigned
> to a variable inside an anonymous closure.  Then subsequently I assign
> to a variable of the same name outside the closure, causing a
> NullPointerException.  I am running groovy-1.0-jsr-02 on jdk1.5.0_03 on
> Windows.
> 
> graham
> 
> // begin groovy code
> [1].each( { myVariable = it; } )
> myVariable = 8;

You need to define the variable first before using it.
Here, you define myVariable in the scope of the closure, but it's not
available outside that scope, hence the second line throws an NPE
because there's no myVariable in that scope.

You should do:

def myVariable = 0 // some initial value
[1].each{ myVariable = it }
myVariable = 8

--

-- 
Guillaume Laforge
http://glaforge.free.fr/blog/java

Re: [groovy-dev] private / pubic methods.

Russel Winder schrieb:
> It seems that a Groovy scripts is quite happily able to execute a method
>>from a Java class that is private.  In terms of being able to use a
> Groovy script as a way of testing code when not using TestNG or some
> such, this is great.  However in terms of the Java class being happy
> that it's private methods can be executed from outside the class it sort
> of seems the whole scoping things is being destroyed.
> 
> Are we happy that this is the case?  I sort of am but then again I am
> not.

I know what you mean and I would love to see that configurable at 
runtime. Currently Groovy doesn't know if it should access a method or 
not, because it does not know the caller.

bye blackdrag

[groovy-dev] break from eachLine?

Re: [groovy-dev] break from eachLine?

Hi Tom,

Tom Gordon wrote:
> The File.eachLine (and similar) methods are very convenient.  However, I 
> can’t find a way to break out of the loop if I need to.  For example, 
> the following does not work:
> 
> #!/usr/bin/env groovy
> 
> int count = 0
> new File("foo").eachLine { line |
>     println line
>     if (++count == 1) {
>         break
>     }
> }
> 
> Instead, it always prints every line in foo.
>
> Is there any way to break these iterators?

Unfortunately... not really.
For the time being, the sole possibility is to throw some 
RuntimeException around your eachLine call, and to handle it yourself.

There's been a few discussions on the mailing-list in the past on that 
topic. But this break/continue/return semantics has not yet been 
specified and implemented. We will probably implement that in Groovy 2, 
but not in the upcoming 1.0 final release.

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

[groovy-dev] private / pubic methods.

It seems that a Groovy scripts is quite happily able to execute a method
from a Java class that is private.  In terms of being able to use a
Groovy script as a way of testing code when not using TestNG or some
such, this is great.  However in terms of the Java class being happy
that it's private methods can be executed from outside the class it sort
of seems the whole scoping things is being destroyed.

Are we happy that this is the case?  I sort of am but then again I am
not.

--

-- 
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             russel@...

RE: [groovy-dev] break from eachLine?

> -----Original Message-----
> From: Guillaume Laforge [mailto:glaforge@...]
> Sent: Donnerstag, 4. August 2005 20:48
..
> There's been a few discussions on the mailing-list in the past on that 
> topic. But this break/continue/return semantics has not yet been 
> specified and implemented. We will probably implement that in Groovy 2, 
> but not in the upcoming 1.0 final release.

What a pitty. I very much hoped we could have that with 1.0 final.
What makes that impossible? Is the task too complicated or too
much effort?

cheers
Mittie