Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proposal to change default annotation processing policy in JDK 23

mail.openjdk.org

Post reply on HN
Print view View original

51–60 of 108 posts

Re: Proposal to change default annotation processing policy in JDK 23

#51

Post by frant-hartm »

pjmlp wrote: post #39
martypitt wrote: post #20

Earlier quoted context omitted.

Slightly OT, but sincere thanks from me to you for creating Lombok. It's a tool that sparks strong opinions, which is a testament to its significance and the impact it has made. You've created something that people are passionate about, whether they're for or against it. Personally, I'm firmly in Team Lombok. I believe the negative feedback it receives is disproportionate. For those of us who use it, Lombok significa…

Those of us that are not on team Lombok still have to deal with it due to transitive dependencies.

Complain to the author of your direct dependencies (or better send a PR if open source). There is absolutely no reason why lombok should get pulled in as transitive dependency apart from ignorance on library author side.

Re: Proposal to change default annotation processing policy in JDK 23

#52

Post by pron »

nfrankel wrote: post #27

The Java team is still breaking things despite numerous pleas of the community pleading not to do so? Color me surprised. The Security Manager send its regards.

You mean pleas from some members of the community not to do so and many more pleas from many more members of the community to the contrary. It is impossible to do "the community's bidding" when different parts of the community demand contradictory things. So we try to cater to the majority while giving the minority sufficient time to adapt.

SecurityManager is a case in point. You and a few others claimed that removing it would have a large harmful impact. We proceeded in our usual cautious manner to first test the more widely believed hypothesis to the contrary before doing anything irreversible and put a warning in place in JDK 17. A lot of people have adopted JDK 17 or later over the last few years and those of them who are using SecurityManager have seen the warning about its planned removal. As most people believed, the warning did not uncover some hidden widespread use of the feature (and your campaign didn't manage to find widespread support for your position).

It is perfectly alright to be dissatisfied when a decision doesn't go your way, but it's not alright to present it as if the decision went against "numerous pleas" without mentioning that, however numerous (which, in this case, was fewer than ten people), those pleas came from a small minority. Had we gone the other way, far more people would have been dissatisfied.

Re: Proposal to change default annotation processing policy in JDK 23

#53

Post by kaba0 »

jillesvangurp wrote: post #18
vips7L wrote: post #17

Earlier quoted context omitted.

> They generally require annotations in your own source code to kick in Right but you don’t know which annotation processor will actually run. Anybody could look for javax.persistence.Entity and do something. There’s no guarantee only your JPA provider will be running and looking at them.

In exactly the same way, unless you audit your dependencies, you have no idea what you are going to run. It all boils down to whether you trust your dependencies. The only difference here is that this is a compile time dependency, not a run-time dependency. But unless you checked it, there are no guarantees.

It’s pretty easy to statically verify that, say, no dependency (even transitive ones) contain a System.exit call.

It’s basically impossible to determine what your annotation processors will output besides running them yourselves (and their output may not be deterministic to begin with).

Re: Proposal to change default annotation processing policy in JDK 23

#54

Post by kaba0 »

bloat wrote: post #50

Lombok has come up a bit in this discussion. Are there any other popular Java libraries or frameworks that are affected?

No other comes to mind. Most other libraries are proper annotation processors, meaning they abide by the rules and are only additive, generating new classes. One such would be mapstruct which is pretty frequently used.

Re: Proposal to change default annotation processing policy in JDK 23

#55

Post by pjmlp »

frant-hartm wrote: post #51
pjmlp wrote: post #39

Earlier quoted context omitted.

Those of us that are not on team Lombok still have to deal with it due to transitive dependencies.

Complain to the author of your direct dependencies (or better send a PR if open source). There is absolutely no reason why lombok should get pulled in as transitive dependency apart from ignorance on library author side.

I rather get rid of them when possible, instead of indirectly contributing to lombok's existence.

Re: Proposal to change default annotation processing policy in JDK 23

#56

Post by dtech »

The_Colonel wrote: post #47
tadfisher wrote: post #9

Earlier quoted context omitted.

Annotation processors on the compile classpath are not automatically added to the build output's runtime classpath. The status quo doesn't change, because annotation processors also don't do anything when running the app (e.g. with java and not javac), on any Java version.

Annotation processor can generate code which will be included in the build output runtime classpath..

which is completely irrelevant for the context of this specific change: automatically picking up annotation processors.

If you don't like the (generated) code of a lib don't use it.

Re: Proposal to change default annotation processing policy in JDK 23

#57

Post by sixcorners »

pron wrote: post #48
skissane wrote: post #32

Earlier quoted context omitted.

> They instead hack into the javac compiler to be able to modify class files, which is a very different mechanism They only do that because there is no public Java API to do the things they want to do. If a public Java API to do the same things were made available, I’m sure they’d gladly migrate to doing that instead

> They only do that because there is no public Java API to do the things they want to do. If a public Java API to do the same things were made available, I’m sure they’d gladly migrate to doing that instead Lombok is an alternative language for the Java platform, and the thing they want to do is modify javac so that it compiles Lombok source (which does not conform to the Java Language Specification) rather than Java…

So would you suggest he change it to work like quasar?

Re: Proposal to change default annotation processing policy in JDK 23

#58

Post by skissane »

pron wrote: post #48
skissane wrote: post #32

Earlier quoted context omitted.

> They instead hack into the javac compiler to be able to modify class files, which is a very different mechanism They only do that because there is no public Java API to do the things they want to do. If a public Java API to do the same things were made available, I’m sure they’d gladly migrate to doing that instead

> They only do that because there is no public Java API to do the things they want to do. If a public Java API to do the same things were made available, I’m sure they’d gladly migrate to doing that instead Lombok is an alternative language for the Java platform, and the thing they want to do is modify javac so that it compiles Lombok source (which does not conform to the Java Language Specification) rather than Java…

> Lombok is an alternative language for the Java platform, and the thing they want to do is modify javac so that it compiles Lombok source (which does not conform to the Java Language Specification) rather than Java source. You are correct that the JDK does not currently wish to offer an API that would allow code, without any special configuration, to change the compiler so that it violates its own specification.

There are many other languages for which nobody would make the argument you just made, because the language has some kind of macro system (or equivalent thereof). Lombok is trying to plug some major gaps in Java’s feature set, and the fact that it exists and is so popular is testament to the fact that the gaps are real. And the “public API” I am talking about would essentially be the missing macro system (or the foundations of one)

> If Lombok were used like all other Java platform languages it would experience no friction.

Because Lombok is trying to be a minimalist extension to Java not a completely different language with very different syntax and semantics.

Re: Proposal to change default annotation processing policy in JDK 23

#59

Post by pron »

skissane wrote: post #58
pron wrote: post #48

Earlier quoted context omitted.

> They only do that because there is no public Java API to do the things they want to do. If a public Java API to do the same things were made available, I’m sure they’d gladly migrate to doing that instead Lombok is an alternative language for the Java platform, and the thing they want to do is modify javac so that it compiles Lombok source (which does not conform to the Java Language Specification) rather than Java…

> Lombok is an alternative language for the Java platform, and the thing they want to do is modify javac so that it compiles Lombok source (which does not conform to the Java Language Specification) rather than Java source. You are correct that the JDK does not currently wish to offer an API that would allow code, without any special configuration, to change the compiler so that it violates its own specification. The…

> because the language has some kind of macro system

Sure, but Java currently does not offer a macro system (which brings many downsides in addition to upsides) and that's by choice. Offering what amounts to a macro system via an API would be a decision with big ramification that is not to be taken lightly. Even then the language needs to decide the extent of the powers of such a system.

You don't have to like this state of affairs, but you can't pretend it isn't what it is. Every language gets to choose what guarantees it offers its users.

> Because Lombok is trying to be a minimalist extension to Java not a completely different language with very different syntax and semantics.

And that's perfectly fine, but the Java specification, by current choice, does not allow making either small or large changes to it. Any language that does not conform to the specification of the Java language is, by definition, not Java regardless of how similar it is. Consequently, the Java compiler does allow code implementing another language to change the compiler's inner workings to compile that new language by configuring it in a certain way, but it does not allow code to do that without special configuration while masquerading as a Java library that appears to conform to the specification.

Re: Proposal to change default annotation processing policy in JDK 23

#60

Post by The_Colonel »

dtech wrote: post #56
The_Colonel wrote: post #47

Earlier quoted context omitted.

Annotation processor can generate code which will be included in the build output runtime classpath..

which is completely irrelevant for the context of this specific change: automatically picking up annotation processors. If you don't like the (generated) code of a lib don't use it.

It's not irrelevant.

A rogue (automatically run) annotation processor will generate exploit code bundled into the build output artifact, which will then run on the production systems.

Besides, annotation processor can attack the build system as well.

Post reply on HN