I realize that I am trying to do something different, compile Java using
Groovy. I wonder if supporting this will open up a lot more usage of Groovy
(especially when doing AST transformations), which is exactly what I am
trying to do
Greedy is a solution, I think another way would be to use ; as a delimiter
when trying to compile java code. Is there a way to do this, some sort of
mixed compilation mode? The array problem listed is also a pain when
compiling java code (I suppose a simple regex can solve that). The last one
about static analysis, I just realized also works if I explicitly provide
the function generic types
class MyData ( String dataType; }
List<MyData> allMyData = []
// This is valid Java but wont compile in Groovy. The error is (getDataType
is not a valid method on Object)
Map<String, List<String>> myList =
allMyData.stream().collect(Collectors.groupingBy(data -> data.dataType ));
// It needs to be converted to this
Map<String, List<String>> myList =
allMyData.stream().collect(Collectors.<MyData, String> groupingBy(data ->
data.dataType) );
regards
Saravanan
On Sat, Nov 2, 2024 at 7:41 PM Christopher Smith <chry...@gmail.com> wrote:
> I suggest that the Groovy parser should be "greedier" in both of the
> return cases you showed. Furthermore, as this is a trap that's bitten me
> before, I propose that it should be a compile-time error to use a bare
> "return" statement in a method with a non-void return type; implied "return
> null" is almost never what the programmer intends.
>
> On Sat, Nov 2, 2024, 08:28 Saravanan Palanichamy <chava...@gmail.com>
> wrote:
>
>> Hello there
>>
>> I am compiling standard Java code with Groovy (it works for the most part
>> with some exceptions) and want to call out some differences. Is there a way
>> for me to auto fix these discrepancies with say a text pre-processor or
>> some AST parsing modifications?
>>
>> *Compile errors with new lines. *This snippet of code below will cause a
>> compile error with "Cannot find matching method
>> java.lang.String#positive()" on the line after the return statement. I
>> suppose this is because the parser thinks return blah is a statement by
>> itself
>>
>> @Override
>> public String toString() {
>> return "blah"
>> + "blah blah";
>> }
>>
>> *Unexpected behaviour with new lines.* This can cause other issues
>> unexpectedly. The following is valid java code, but it returns null in
>> Groovy instead of blah blah
>>
>> @Override
>> public String toString() {
>> return
>> "blah blah";
>> }
>>
>> *Array constructs. *This is valid java code but will cause a compile
>> error in Groovy because arrays need to be created with [ ] instead of { }
>> enum MyEnum { ME, YOU, US }
>>
>> @MyEnums(value = {ME, YOU})
>> void function1() { ... }
>>
>>
>> *Static type checking for stream constructs. *
>>
>> class MyData ( String dataType; }
>> List<MyData> allMyData = []
>>
>> // This is valid Java but wont compile in Groovy. The error is
>> (getDataType is not a valid method on Object)
>> Map<String, List<String>> myList =
>> allMyData.stream().collect(Collectors.groupingBy(data -> data.dataType ));
>> // It needs to be converted to this
>> Map<String, List<String>> myList =
>> allMyData.stream().collect(Collectors.groupingBy { MyData data ->
>> data.dataType } );
>>
>> regards
>> Saravanan
>>
>
