Constructor Interfaces

[forax at univ-mlv.fr]

----- Original Message -----
> From: "Ron Pressler" <ron.pressler at oracle.com>
> To: "Red IO" <redio.development at gmail.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "amber-dev" <amber-dev at openjdk.org>
> Sent: Monday, January 30, 2023 2:37:20 PM
> Subject: Re: Constructor Interfaces

>> On 30 Jan 2023, at 10:26, Red IO <redio.development at gmail.com> wrote:
>> 
>> After exploring the world of annotation processors trying to implement test
>> versions of the features, I discovered that annotation processors can't
>> officially edit the ast and Lombok uses undocumented hacks to achieve this.
>> This is a bit of a problem for implementing the test versions that way. My
>> question is why is this disallowed? It would be a really powerful tool for
>> compile time code execution/ generation.
>> Great regards
>> RedIODev
> 
> It is disallowed because it would allow compiler plugins to change the semantics
> of Java code, adding, in effect, AST macros. Macros are very useful and very
> harmful. Some languages decide to allow them, Java forbids them. As with any
> feature, the question we ask is not “is it useful?” but “does its contribution
> significantly outweigh all of its costs and downsides in the long term for
> Java’s core audience?"
> 
> Note that the classes Lombok uses are not only undocumented, but also
> unexported, which makes any code breaking open the JDK’s encapsulation to rely
> on them not portable across Java versions.
> 
> Also note that the most important exploration of language features is the one
> required to establish that they’re necessary. Implementing a language feature
> is usually very easy and often not particularly interesting; what’s hard is
> finding the right problem to solve. A more valuable exploration of your
> proposed feature wouldn’t be implementing it, but analysing codebases to
> measure the importance of the problem.

Also the bytecode (the class file format) is the documented AST.

Modifying the bytecode means that your code works for Java but also Kotlin and Scala.
This can be done on top of an annotations processor like Quarkus does.
But obviously, you can not change the API, just implement backward compatible modifications (if separate compilation is a concern).

> 
> — Ron

Rémi