<div dir="auto">The idea behind implementing it quick and dirty with "Marcos"(annotation processors) was to see applicability and usefulness of the features. I think it's really difficult to either write synthetic examples or develop libraries with the feature in mind while it's not working showing red lines everywhere and having neither syntax highlighting nor the ability to compile everything.<div dir="auto">But I got an idea even though not optimal that allows me to implement a prototype in bounds of normal annotation processing (and new class creation).</div><div dir="auto"><br></div><div dir="auto">And I think the bigger feature aka runtime generics are undoubtedly generally understood to be highly desirable. </div><div dir="auto"><br></div><div dir="auto">Great regards </div><div dir="auto">RedIODev </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 30, 2023, 14:37 Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On 30 Jan 2023, at 10:26, Red IO <<a href="mailto:redio.development@gmail.com" target="_blank" rel="noreferrer">redio.development@gmail.com</a>> wrote:<br>
> <br>
> 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.<br>
> Great regards <br>
> RedIODev <br>
<br>
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?"<br>
<br>
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.<br>
<br>
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.<br>
<br>
— Ron</blockquote></div>