undefined | Better HN

0 pointsfoobazgt11mo ago0 comments

Thanks for clarifying your role in the JEP.

I feel like we're talking right past one another. The ultimate reality is that annotation processors are pretty terrible for implementing functionality that a lot of Java developers depend upon. You could say annotation processors "weren't designed for that", but then you're just agreeing with me. This is sad, because arguably something quite similar to annotation processors could make the jobs of all of these developers a lot easier, instead of having them falling back to other mechanisms.

If your concern is integrity by default, why not just add yet another flag for can-muck-with-the-ast-annotation-processors? Or we can continue with the status quo.

0 comments

pron11mo ago

> If your concern is integrity by default, why not just add yet another flag for can-muck-with-the-ast-annotation-processors?

There is such a flag (or, rather, a set of flags), and that's exactly what the Lombok compiler uses to change javac to compile Lombok sources rather than Java sources.

However, we think there are much better solutions to the problem those languages try to solve than allowing AST manipulation.

foobazgtOP11mo ago

You've referenced Lombok a lot here, and some Google searches later, I can see that you're in conversations all over the internet re: Lombok (and similar projects like Manifold). Their purpose is to extend the Java language. The class of code I'm referring to is more like those you already mention in your JEP: logging, tracing, profiling, serialization, authn/authz, mocking, ffi, and so on. I would describe all of those as fitting under the umbrella of "cross-cutting" and needing a "meta-programming" facility.

> However, we think there are much better solutions

I'd like to hear more. Can I discuss this further with you in a more appropriate venue than this forever thread?

pron11mo ago

> The class of code I'm referring to is more like those you already mention in your JEP: logging, tracing, profiling, serialization, authn/authz, mocking, ffi, and so on. I would describe all of those as fitting under the umbrella of "cross-cutting" and needing a "meta-programming" facility.

Those are traditionally offered in Java in the form of bytecode transformation rather than AST transformations, as the notion of "compile time" in Java is not as clear as it is in, say, Zig; Project Leyden will make it even more vague, as it will allow caching JIT output from one run to the next.

> Can I discuss this further with you in a more appropriate venue than this forever thread?

Sure, you can email me at the email address I use on the JDK mailing lists (e.g. loom-dev).

1 more reply

j / k navigate · click thread line to collapse

0 pointsfoobazgt11mo ago0 comments

Thanks for clarifying your role in the JEP.

If your concern is integrity by default, why not just add yet another flag for can-muck-with-the-ast-annotation-processors? Or we can continue with the status quo.

0 comments

pron11mo ago

> If your concern is integrity by default, why not just add yet another flag for can-muck-with-the-ast-annotation-processors?

There is such a flag (or, rather, a set of flags), and that's exactly what the Lombok compiler uses to change javac to compile Lombok sources rather than Java sources.

However, we think there are much better solutions to the problem those languages try to solve than allowing AST manipulation.

foobazgtOP11mo ago

> However, we think there are much better solutions

I'd like to hear more. Can I discuss this further with you in a more appropriate venue than this forever thread?

pron11mo ago

> Can I discuss this further with you in a more appropriate venue than this forever thread?

Sure, you can email me at the email address I use on the JDK mailing lists (e.g. loom-dev).

1 more reply

j / k navigate · click thread line to collapse