Constructor Interfaces

[Red IO]

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.
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).

And I think the bigger feature aka runtime generics are undoubtedly
generally understood to be highly desirable.

Great regards
RedIODev

On Mon, Jan 30, 2023, 14:37 Ron Pressler <ron.pressler at oracle.com> wrote:

>
>
> > 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.
>
> — Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230130/e95a31e8/attachment.htm>