Java <-> Groovy converters

[Edward Povazan]

Hello,

Having used some of the Groovy AST classes of late, and also looking  
at the ASTNode hierarchy representing a Java class in Eclipse, I  
started to think about converters from Java to Groovy (or perhaps the  
other way around).
It seems like a fun task. However, is there any practical use for  
something like this? Does anyone have any scenarios where this would  
be useful? Just curious.

-Ed

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

    http://xircles.codehaus.org/manage_email

[paulk_asert]

One that springs to mind is converting Java Unit tests to Groovy Unit tests.

You could start out with an autoconversion and then add extra Grooviness by
hand over time.

Paul.

Edward Povazan wrote:

> Hello,
>
> Having used some of the Groovy AST classes of late, and also looking at
> the ASTNode hierarchy representing a Java class in Eclipse, I started to
> think about converters from Java to Groovy (or perhaps the other way
> around).
> It seems like a fun task. However, is there any practical use for
> something like this? Does anyone have any scenarios where this would be
> useful? Just curious.
>
> -Ed
>
> ---------------------------------------------------------------------
> 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]

Edward Povazan schrieb:
> Hello,
>
> Having used some of the Groovy AST classes of late, and also looking at
> the ASTNode hierarchy representing a Java class in Eclipse, I started to
> think about converters from Java to Groovy (or perhaps the other way
> around).

The problem with Groovy->Java is, that not all constructs are doable in
Java. Just think of checked Exceptions for example. Java->Groovy should
be easy on a syntactic level, but the lack of inner classes complicates
this a bit. And after that is done, there is always the semantic level.
Java does not have multimethods. I am not against such a tool, but it
must make clear, that it can not be used to convert one working program
into another.

> It seems like a fun task. However, is there any practical use for
> something like this? Does anyone have any scenarios where this would be
> useful? Just curious.

well, maybe for people starting with Groovy.

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

[Martin C. Martin-2]

Java to Groovy: Someone knows how to express something in Java, but not
in Groovy.  For example, turning anonymous inner classes into closures,
or named inner classes into separate classes in the same file.

Groovy to Java: Efficiency.  You have code that works in Groovy, but
it's slow.  It would be great to recode a few of the functions in Java.

- Martin

Edward Povazan wrote:

> Hello,
>
> Having used some of the Groovy AST classes of late, and also looking at
> the ASTNode hierarchy representing a Java class in Eclipse, I started to
> think about converters from Java to Groovy (or perhaps the other way
> around).
> It seems like a fun task. However, is there any practical use for
> something like this? Does anyone have any scenarios where this would be
> useful? Just curious.
>
> -Ed
>
> ---------------------------------------------------------------------
> 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

[tugwilson]

On 22 Dec 2006, at 12:24, Martin C. Martin wrote:

> Java to Groovy: Someone knows how to express something in Java, but  
> not in Groovy.  For example, turning anonymous inner classes into  
> closures, or named inner classes into separate classes in the same  
> file.
>
> Groovy to Java: Efficiency.  You have code that works in Groovy,  
> but it's slow.  It would be great to recode a few of the functions  
> in Java.

You can recode functions in Java pretty easily. Just subclass your  
Groovy class with a Java class or have your Groovy class subclass a  
Java class. You end up with an object with a mixture of Java and  
Groovy methods.

If you translate Groovy into Java whilst preserving the semantics you  
will not a large performance improvement. This is because you will  
need to pass everything through the MetaClass.

John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email

[Martin C. Martin-2]

John Wilson wrote:

>
> On 22 Dec 2006, at 12:24, Martin C. Martin wrote:
>
>> Groovy to Java: Efficiency.  You have code that works in Groovy, but
>> it's slow.  It would be great to recode a few of the functions in Java.
>
> You can recode functions in Java pretty easily. Just subclass your
> Groovy class with a Java class or have your Groovy class subclass a Java
> class. You end up with an object with a mixture of Java and Groovy methods.
>
> If you translate Groovy into Java whilst preserving the semantics you
> will not a large performance improvement. This is because you will need
> to pass everything through the MetaClass.

True, I was thinking that the Groovy -> Java compiler would assume the
default MetaClass and do the "obvious" Java thing, which will be
incorrect in certain cases.  So as Jochen said, the resulting Java code
may not behave exactly like the Groovy code.  But it would be a start.

If you want Java code whose behaviour is the same as the Groovy code,
just call a Java decompiler on the .class files.  :)  This was suggested
in GinA, and I've been playing around with it.  It's not perfect, but
it's a lot of fun.  :)

Best,
Martin


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

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 22 Dec 2006, at 13:19, Martin C. Martin wrote:

> True, I was thinking that the Groovy -> Java compiler would assume  
> the default MetaClass and do the "obvious" Java thing, which will  
> be incorrect in certain cases.  So as Jochen said, the resulting  
> Java code may not behave exactly like the Groovy code.  But it  
> would be a start.


Yes but the issue is not really the behaviour of the MetaClass it's  
the type of the variables. My view is that using typed variables is  
normally bad Groovy style (There are exceptions to this, of course).  
If you have code continuing untyped variables and you can't infer the  
type then you have to use the MetaClass directly.

Writing Groovy as though it was Java is a phase that all of us have  
gone through when learning Groovy. I'd certainly not like to  
encourage people to persist in this habit for the sake of  
"efficiency" :)


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email

[Gavin Grover]

A Java -> Groovy converter would be handy.

Martin C. Martin wrote:
> For example, turning anonymous inner classes into closures,
> or named inner classes into separate classes in the same file.

Other common tasks / workarounds I do a lot of:
3. removing getters and setters
4. replacing method calls with operators, especially [ ] and <<
5. removing extra constructors / methods by using default parameters
6. changing the for-loop, and do-loop
7. add semi-colons for fewer but longer lines
8. change 10-line /** comment into 1-line // comment
9. remove 20-line copyright message at top of 10-lines-of-code file
10. combine all the shortish classes in a package into one file
11. add def in front of methods / fields inside classes
12. remove try-catch blocks, or throws clauses from methods
13. remove typenames, except int & char
14. replace arrays with lists, hashtables with maps
15. remove import java.util.*, etc
16. finally, refactor in more meaningful class, method, etc names

Cheers, Gavin Grover




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

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

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 22 Dec 2006, at 15:55, Gavin Grover wrote:

> Martin C. Martin wrote:
>> For example, turning anonymous inner classes into closures,
>> or named inner classes into separate classes in the same file.
>
> Other common tasks / workarounds I do a lot of:
> 3. removing getters and setters
> 4. replacing method calls with operators, especially [ ] and <<
> 5. removing extra constructors / methods by using default parameters
> 6. changing the for-loop, and do-loop
> 7. add semi-colons for fewer but longer lines
> 8. change 10-line /** comment into 1-line // comment
> 9. remove 20-line copyright message at top of 10-lines-of-code file
> 10. combine all the shortish classes in a package into one file
> 11. add def in front of methods / fields inside classes
> 12. remove try-catch blocks, or throws clauses from methods
> 13. remove typenames, except int & char
> 14. replace arrays with lists, hashtables with maps
> 15. remove import java.util.*, etc
> 16. finally, refactor in more meaningful class, method, etc names

That's a great list!


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email

[Guillaume Laforge]

That's a "Groovyfy" refactoring that could be added to the Eclipse plugin :-)

On 12/22/06, John Wilson <[hidden email]> wrote:

>
> On 22 Dec 2006, at 15:55, Gavin Grover wrote:
>
> > Martin C. Martin wrote:
> >> For example, turning anonymous inner classes into closures,
> >> or named inner classes into separate classes in the same file.
> >
> > Other common tasks / workarounds I do a lot of:
> > 3. removing getters and setters
> > 4. replacing method calls with operators, especially [ ] and <<
> > 5. removing extra constructors / methods by using default parameters
> > 6. changing the for-loop, and do-loop
> > 7. add semi-colons for fewer but longer lines
> > 8. change 10-line /** comment into 1-line // comment
> > 9. remove 20-line copyright message at top of 10-lines-of-code file
> > 10. combine all the shortish classes in a package into one file
> > 11. add def in front of methods / fields inside classes
> > 12. remove try-catch blocks, or throws clauses from methods
> > 13. remove typenames, except int & char
> > 14. replace arrays with lists, hashtables with maps
> > 15. remove import java.util.*, etc
> > 16. finally, refactor in more meaningful class, method, etc names
>
>
> That's a great list!
>
>
> John Wilson
> The Wilson Partnership
> web http://www.wilson.co.uk
> blog http://eek.ook.org
>
>
>
> ---------------------------------------------------------------------
> 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

[Martin C. Martin-2]

John Wilson wrote:

>
> On 22 Dec 2006, at 13:19, Martin C. Martin wrote:
>
>> True, I was thinking that the Groovy -> Java compiler would assume the
>> default MetaClass and do the "obvious" Java thing, which will be
>> incorrect in certain cases.  So as Jochen said, the resulting Java
>> code may not behave exactly like the Groovy code.  But it would be a
>> start.
>
>
> Yes but the issue is not really the behaviour of the MetaClass it's the
> type of the variables. My view is that using typed variables is normally
> bad Groovy style (There are exceptions to this, of course). If you have
> code continuing untyped variables and you can't infer the type then you
> have to use the MetaClass directly.

Good point.  I tend to put types on method args/return values, at least
ones that are part of a public API, but on little else.

- Martin

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

    http://xircles.codehaus.org/manage_email

[Warner Onstine-3]

How do you handle things like this?
String[] myStrArray = ["string1"]

The reason I ask is because a function I was calling in Java-land
expected an array of strings but instead got an ArrayList when I did
this
def myStrArray = ["string1"]

The obvious workaround for me was to type the variable, if there's a
different solution that would be great.

Out of Java habit I was also typing my return values from method
calls, I just never thought about *not* doing it.

-warner

On 12/22/06, Martin C. Martin <[hidden email]> wrote:

>
>
> John Wilson wrote:
> >
> > On 22 Dec 2006, at 13:19, Martin C. Martin wrote:
> >
> >> True, I was thinking that the Groovy -> Java compiler would assume the
> >> default MetaClass and do the "obvious" Java thing, which will be
> >> incorrect in certain cases.  So as Jochen said, the resulting Java
> >> code may not behave exactly like the Groovy code.  But it would be a
> >> start.
> >
> >
> > Yes but the issue is not really the behaviour of the MetaClass it's the
> > type of the variables. My view is that using typed variables is normally
> > bad Groovy style (There are exceptions to this, of course). If you have
> > code continuing untyped variables and you can't infer the type then you
> > have to use the MetaClass directly.
>
> Good point.  I tend to put types on method args/return values, at least
> ones that are part of a public API, but on little else.
>
> - Martin
>
> ---------------------------------------------------------------------
> 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

[tugwilson]

On 22 Dec 2006, at 17:12, Warner Onstine wrote:

> How do you handle things like this?
> String[] myStrArray = ["string1"]
>
> The reason I ask is because a function I was calling in Java-land
> expected an array of strings but instead got an ArrayList when I did
> this
> def myStrArray = ["string1"]


def myStrAtrray = ["string1"] as String[]

Is a way of doing this.

Or wait until the function call and convert it then:

myObject.myJavaFunction(myStrAtrray as String[])

However, if you are building data structures which are just going to  
be consumed by Java code then I think it's legitimate to type them.N  
ot typing variables is a guideline not a rule.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email

[Warner Onstine-3]

Ahh, ok thanks for the clarification. Personally I really didn't see a
difference between typing it or typing it using the "as" keyword, but
I guess if you want to keep it typeless except in certain
circumstances that would make sense.

-warner

On 12/22/06, John Wilson <[hidden email]> wrote:

>
> On 22 Dec 2006, at 17:12, Warner Onstine wrote:
>
> > How do you handle things like this?
> > String[] myStrArray = ["string1"]
> >
> > The reason I ask is because a function I was calling in Java-land
> > expected an array of strings but instead got an ArrayList when I did
> > this
> > def myStrArray = ["string1"]
>
>
> def myStrAtrray = ["string1"] as String[]
>
> Is a way of doing this.
>
> Or wait until the function call and convert it then:
>
> myObject.myJavaFunction(myStrAtrray as String[])
>
> However, if you are building data structures which are just going to
> be consumed by Java code then I think it's legitimate to type them.N
> ot typing variables is a guideline not a rule.
>
>
> John Wilson
> The Wilson Partnership
> web http://www.wilson.co.uk
> blog http://eek.ook.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

[tugwilson]

On 22 Dec 2006, at 17:21, Warner Onstine wrote:

> Ahh, ok thanks for the clarification. Personally I really didn't see a
> difference between typing it or typing it using the "as" keyword, but
> I guess if you want to keep it typeless except in certain
> circumstances that would make sense.


It's a matter of trying to keep code as general as possible but not  
over specifying constraints.

So, in Java, this is generally bad practice

HashMap m = new HashMap();

we prefer

Map m = new HashMap()

but, in Groovy, we prefer

def m = [:]

However, if the value *must* be of a certain type (which appears to  
be the case in your example) then it's almost certainly preferable to  
use a typed variable.

I think we are still discovering the parameters of good Groovy style.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email

[Edward Povazan]

You sound like you do this a lot! And I don't see much that could not  
be converted into Groovy. You didn't mention inner classes at all,  
perhaps this is not a common thing?
-Ed

On 22-Dec-06, at 7:55 AM, Gavin Grover wrote:

> A Java -> Groovy converter would be handy.
>
> Martin C. Martin wrote:
>> For example, turning anonymous inner classes into closures,
>> or named inner classes into separate classes in the same file.
>
> Other common tasks / workarounds I do a lot of:
> 3. removing getters and setters
> 4. replacing method calls with operators, especially [ ] and <<
> 5. removing extra constructors / methods by using default parameters
> 6. changing the for-loop, and do-loop
> 7. add semi-colons for fewer but longer lines
> 8. change 10-line /** comment into 1-line // comment
> 9. remove 20-line copyright message at top of 10-lines-of-code file
> 10. combine all the shortish classes in a package into one file
> 11. add def in front of methods / fields inside classes
> 12. remove try-catch blocks, or throws clauses from methods
> 13. remove typenames, except int & char
> 14. replace arrays with lists, hashtables with maps
> 15. remove import java.util.*, etc
> 16. finally, refactor in more meaningful class, method, etc names
>
> Cheers, Gavin Grover
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.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

[Gavin Grover]

Hi Ed

I didn't repeat what Martin C. Martin already wrote:
1. For example, turning anonymous inner classes into closures,
2. or named inner classes into separate classes in the same file.

These are common. To turn an anonymous inner class into a closure, I just use:
  class MyListener extends SuppliedListener{
    def closure
    MyListener( Closure c ){ closure= c }
    public void suppliedEventMethod( SuppliedEvent e ){ closure(e) }
  }

I sometimes convert some small open source code to Groovy in my spare time. It helps me understand the program I'm converting. The hardest is multi-threaded programs.

Cheers, Gavin Grover
----- Original Message ----From: Edward Povazan
You sound like you do this a lot! And I don't see much that could not  
be converted into Groovy. You didn't mention inner classes at all,  
perhaps this is not a common thing?
-Ed

On 22-Dec-06, at 7:55 AM, Gavin Grover wrote:

> A Java -> Groovy converter would be handy.
>
> Martin C. Martin wrote:
>> For example, turning anonymous inner classes into closures,
>> or named inner classes into separate classes in the same file.
>
> Other common tasks / workarounds I do a lot of:
> 3. removing getters and setters
> 4. replacing method calls with operators, especially [ ] and <<
> 5. removing extra constructors / methods by using default parameters
> 6. changing the for-loop, and do-loop
> 7. add semi-colons for fewer but longer lines
> 8. change 10-line /** comment into 1-line // comment
> 9. remove 20-line copyright message at top of 10-lines-of-code file
> 10. combine all the shortish classes in a package into one file
> 11. add def in front of methods / fields inside classes
> 12. remove try-catch blocks, or throws clauses from methods
> 13. remove typenames, except int & char
> 14. replace arrays with lists, hashtables with maps
> 15. remove import java.util.*, etc
> 16. finally, refactor in more meaningful class, method, etc names
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

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

    http://xircles.codehaus.org/manage_email