My Customers write Java code, I use Groovy's awesome AST transforms to
update it. I want to understand how to handle the differences from Java
a) Handle the newline in return usecase, both compile errors and unexpected
behaviour (I could write an AST transform to check for this, but it feels
more ingrained than that)
b) Handle the {} syntax in Java vs [] syntax in Groovy for arrays in my
annotations
c) Handle the static type checker that seems to do something different from
java when figuring out inherent types for lambda expressions
Thank you for your time
regards
Saravanan
On Sat, Nov 2, 2024 at 8:48 PM Saravanan Palanichamy <chava...@gmail.com>
wrote:
> 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
>>>
>>
