On 06.04.25 06:59, Saravanan Palanichamy wrote:
Hello Groovy users/devs
I am using the Groovy compiler to compile standard Java code (as in the
developer wrote Java code, I am using the Groovy compiler behind the
scenes). Most of it works, but I did see a few compatibility issues.
Some seem like bugs, some seem like parsing differences. Will there be
plans to address some of them in 5.0 or even 4.0? I am using 4.0.24
1. Interfaces with static methods are not supported
I think that is fixed in 5
2. Calls to the outer class's super from an inner class does not work.
There are continuously fixes to this, and often things break again..
This is somehow really difficult to get right
3. Cannot mix public and private methods with the same name and parameters
Yes, that is by design.
4. Groovy incorrectly compiles the accessing of InnerClass's variables
when the OuterClass has a getter for it
I would need an example for this.
5. Cannot call on outerclass's default method if the inner class extends
that outerclass
you mean OuterClass.this.foo() does not work if foo is the default method?
6. Appending of strings with the appending operator on a new line (ie.
`+ "test"`) would fail in groovy
that is because
"foo"
+"bar"
is a valid Groovy program with two lines. Unlikely to be changed.
7. Return with return value on a new line will be considered a return
null in groovy with a non reacheable
again this is because of the optional semicolon. Unlikely to be changed.
8. Java files will use {} in annotations to define arrays which is not
supported in groovy where arrays uses square brackets. Static arrays in
java use {} while groovy uses [].
I think we recently changed something here
9, Dollar Signs in Strings need to be escaped in Groovy (Presumably
because of GString capabilities)
yep... unless we introduce a Javamode this is super unlikely to be changed.
10,. Enums in java switch/case statements must not be fully qualified,
but enums in groovy case statements must be fully qualified (A fix seems
to exist but it does not work as expected)
well, that does sound like a bug.
11. Groovy has trouble type inferencing for Collections. The offender is
Collections.asBlah set of methods. It needs <A.Y.X> to be added explicitly
Generics is actually quite difficult to do right. There is always some
work ongoing for that stuff, but I would need a more specific example
for this one.
12. Single Character in Single Quotes are not considered Char
by design, so unlikely to be changed.
13. Division Operations return a Big Decimal rather than an Integer/Double
by design, so unlikely to be changed.
14. Functions that take var args will default the type of the first
argument, java tries to find the common parent type from all arguments
really? I thought the parameter type should be used... well... this
could be fixed, but frankly it would be costing more than it is worth it.
I wonder though... why use Groovy to compile Java? I mean if you use
Groovy, then why not use joint compilation?
bye Jochen
