On 29.06.23 07:52, Paul King wrote:
[...]
I would be interested in looking at earlier attempts like V2 to see if
advances in the meantime now make them more feasible.
[...]
On Mon, Jun 26, 2023 at 10:16 PM Jochen Theodorou <blackd...@gmx.org
<mailto:blackd...@gmx.org>> wrote:
[...]
V2:
Collect class data from javac using annotation processing and feed that
to groovyc. This would then be a 3 stage process. First we use javac to
get the class information, but javac cannot complete compilation, since
not all classes are resolved. Then we use the extracted information to
compile Groovy. And finally we compile normally with Java.
I tried this years ago and did not manage to get this working properly.
I would have to investigate what exactly was the problem since I tried
this maybe 8 years ago. But I think I actually was able to extract the
information and my problem was more making the classes then known to
Groovy. If not done in-memory this can probably be done easily.
Today I had some time to play around with this and got something running
quite fast... but looking a bit deeper I found issues.
assume you have something like this in Java
'''
package a;
public class J1 {}
'''
this in Groovy
'''
package b
import a.*
class G1 extends J1 {}
'''
and this in Java
'''
package a;
import b.*;
public class J2 extends G1 {}
'''
and finally in Groovy
'''
package b
import a.*
class G2 extends J2 {}
'''
The problem lies in resolving G1 in J2. The java compiler will not do
that for us, it cannot, since it does not have the required information.
Assume G1 defines a method and G2 uses @Override to override the method.
The result would be a compilation error on the Groovy side, since the G1
in J2 is not our b.G1 and is just an empty shell.
To resolve this by hand I would require the import statements, which
seem not to be part of javax.lang.model. If I go for the "Compiler Tree
API", but then I am specific to Oracle and OpenJDK. I would still have
to resolve things by hand of course.
Any ideas on how to proceed?
bye Jochen
