32

I have inherited significant amounts of Groovy code, and I have found it difficult to maintain for several reasons:

  1. Very often it's hard to tell what's the type of a variable.
  2. Corollary: it's easy to modify a variable with a different type, and not being aware of it.
  3. Many errors will be discovered until run-time (which is scary if your unit testing doesn't cover pretty much everything).
  4. The type of the parameters is basically ignored.
  5. The IDE I'm using (STS Pro) is useful, but far behind from Java. For instance, refactoring is just not available.
  6. Suggestions are available some times, others, not.

Although I appreciate the compactness of the language, maintenance has been difficult and cumbersome.

I have tried to manually convert some pieces to Java, it's been a pain. Are you aware of any tools or plugins that help with this conversion?

JasonMArcher
  • 14,195
  • 22
  • 56
  • 52
luiscolorado
  • 1,525
  • 2
  • 16
  • 23
  • I have found a partial solution to the problem: Groovy++. Although it does not convert Groovy to Java, it provides static variables and fast execution (practically equal to Java), without loosing the concise syntax. My concerns 1, 2, 3, 4 have been resolved, but I have not found yet a plugin for Eclipse. Please see http://code.google.com/p/groovypptest/wiki/Welcome – luiscolorado Sep 13 '11 at 18:37

8 Answers8

33

IntelliJ IDEA has a quite decent support for refactoring of groovy code. It also has a source code level converter from Groovy -> Java. Most of the time it generates code that does not compile, but it may help to get you started with the process of converting the code. Groovy code:

class HelloWorld {
def name
def greet() { "Hello ${name}" }
int add(int a, int b) {
    return a+b;
}
}

Converted Java code:

public class HelloWorld {
public GString greet() {
    return "Hello " + String.valueOf(name);
}

public int add(int a, int b) {
    return a + b;
}

public Object getName() {
    return name;
}

public void setName(Object name) {
    this.name = name;
}

private Object name;
}
af1n
  • 430
  • 4
  • 4
16

Probably not the answer you want to hear, but I would focus on becoming more comfortable with Groovy instead of trying to convert the code to Java. There are many things you can do in Groovy which simply won't translate well to Java (like closures). Any automated conversion to Java will make the code much less readable and harder to understand.

If you can't be persuaded to stick with Groovy, and you MUST migrate to Java, your best bet will be to do it by hand.

dbyrne
  • 59,111
  • 13
  • 86
  • 103
  • Just FYI. The IDE the OP references (STS Pro) is SpringSource Tool Suite. A Spring specific version of Eclipse with the GroovyEclipse plugin built-in, and generally a little ahead of the one available for just plain Eclipse. – Mikezx6r Mar 14 '11 at 17:42
  • Ah thanks for the info. A quick google search on STS Pro didn't turn anything up. I'll remove that part of my answer. – dbyrne Mar 14 '11 at 17:44
  • 2
    you see, I think that I just finished the cycle of getting in love with the language, buying books, learn the most you can, and so on. Then, as I said, I confirmed once again the problem of Groovy: they give you a lot of liberty, so it is *easier* to write messy code, than not. Java also allows you to write messy code, but it's more difficult. And even if you inherit or make a mess of Java code, refactoring is so much easier. Groovy has great ideas, but it is extremely weak with types. I'm looking forward to learn Groovy++ one day... I've heard it fixes Groovy (we'll see). – luiscolorado Mar 14 '11 at 20:55
  • 1
    Groovy++ doesn't "fix" Groovy because it's not broken, it's supposed to be dynamically typed – Dónal Mar 15 '11 at 09:44
  • 2
    Since Java 8's lamdas closures aren't an advantage for groovy anymore. – Torsten Oct 09 '18 at 11:03
7

The Groovy and Java languages both compile to the same bytecode (Java Platform Bytecode). So just (a) compile your .groovy file to a .class file; (b) use a decompiler such as JDGUI to decompile your .class file to a .java file.

Adam Burley
  • 5,551
  • 4
  • 51
  • 72
3

My top tip is write lots of unit tests.

This advice holds true for most dynamic languages, because you get less of a "safety net" from static type checking by the compiler. You'll want to add tests to check that input and output values have the correct type etc.

I think this will solve most of your problems.

mikera
  • 105,238
  • 25
  • 256
  • 415
  • that's precisely the point: the solution to the dynamic languages is creating bigger unit tests. So, on one hand, you save time coding in Groovy, but, on the other hand, you have to write more code in your unit tests. Somehow that defeats, at least in part, the advantage of any dynamic language. – luiscolorado Mar 14 '11 at 20:36
  • your call, but I'd argue that more tests is never a bad thing.... if you're smart you can write tests that both give you functionality coverage *and* test your dynamic type assumptions. – mikera Mar 14 '11 at 20:47
  • 7
    I am all in favor of unit testing. Let me explain myself: if I have to create a new unit test every time I create a method, just to check that the method returns the correct type, something is wrong. If I have to manually check the type of incoming variables in every method, that is not producing clean and readable code. *Let us not do the work a compiler should do.* – luiscolorado Mar 14 '11 at 21:20
3

I found and alternate solution, using Groovy++. It has almost all the advantages of Groovy, but with performance and strong typing from Java. Furthermore, it is based on Groovy, so apparently you only need to add one jar file, and the "@Typed" annotation at the top of the code.

Furthermore, it adds a new features, such as "GrUnit", and allows mixing dynamic and static types, which I hope will allow for the creation of DSL's. So it allow mixing with existing Groovy code, and use with Grails.

The project seems go be young, but truly promising. I am already testing the waters, and checking how far can I take it.

So, this answer actually doesn't say how convert Groovy to Java, but you can get something even better: the benefits of both worlds plus and optional third world --no pun intended :-) -- static typing and performance.

luiscolorado
  • 1,525
  • 2
  • 16
  • 23
0

We would change about 1000 Groovy Classes to Java 8.

  • automatically : i think its possible in Combination with manual steps

Possible Steps for the Migration

  • def Variables : replace manually with the correct class name in the IDE

  • def Methodes : replace manually with the correct class name as Return Value in the IDE

  • File rename : Automatically replace all .groovy Files to .java Files (Java 8)

  • clousures : replace manually with Java 8 Lambdas and Java 8 Streams

  • Groovy overritten Methodes : replace manually with newer Java jdk Klasses i.e. New File io, New Date API or include Apache Libraries

Use your Unit Tests to control your refactoring.

PS: We usw. Eclipse with the Groovy Plugin.

Greetings Roebi

Robert Halter
  • 362
  • 1
  • 9
0

for someone who has similar question, you can take a look on GMavenPlus

Ted Xu
  • 1,095
  • 1
  • 11
  • 20
0

has a some question a year ago. After one or two month of groovy euphoria, it was changer on real world weak. Even GReclipse 2.0 doesn't do a less pain, code becomes unmanageabe and painful. Short answer to your question - no. There is not a real good instrument to do this. GSql i'm replace with Spring JdbcTemplate, Closures with callbacks. All of this need a manual decision of replace strategy, so if you want get a good code you need do int manauly. Else you may use some java decompilers, but i'm think it's not what you really want.

Alexey Sviridov
  • 3,360
  • 28
  • 33
  • 7
    Even though I don't like dynamic languages much, I disagree with "code becomes unmanageabe and painful" in a general context. Code becomes unmanageable and painful if someone makes it unmanageable and painful. – R. Martinho Fernandes Mar 14 '11 at 17:50
  • 2
    @ Martinho Fernandes It's you opinion, i'm respect it. But it's error to think 'language doesn't nothing, all problems is a programmer problem'. – Alexey Sviridov Mar 14 '11 at 18:06
  • 1
    you are feeling my pain. I, indeed, have to deal with a lot of unmanageable code. I have seen these arguments so many types with languages. One side says, "yeah, my language 'X' can do all what your language 'Y' does." Well, although in principle that might be true, that language X is slower, or harder to maintain, or it is easier to make a mess of things. When you inherit a mess of Groovy code, you wish they had been using Java. You can also make a mess in Java, it's just harder. – luiscolorado Mar 14 '11 at 20:42