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

41–50 of 108 posts

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

#41

Post by pdpi »

giamma wrote: post #22

"This policy of implicitly running annotation processors by default may have been reasonable when the feature was introduced in JDK 6 circa 2006, but from a current perspective, in the interest of making build output more robust against annotation processors unintentionally being placed on the class path, the policy should not be the default anymore." This makes sense, especially in light of the growing number of sup…

> Plus, I'd love to be proven wrong, but I could bet that most people will fix the issue by simply adding the "all-on" switch to the command line instead of carefully evaluating which annotation processors are really needed by their codebase.

That’s ok!

For those people, they hit a small speed bump where they have to make a small change to their build. For those of us who care, we get a bunch of control we may choose to exert.

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

#42

Post by pjmlp »

skissane wrote: post #32
kaba0 wrote: post #15

Earlier quoted context omitted.

> this is a silly update in OpenJDK's war against things like Project Lombok Project Lombok doesn’t use the normal annotation processing system, as that is deliberately “add-only” - you can’t change a class’s implementation, unlike what lombok does. They instead hack into the javac compiler to be able to modify class files, which is a very different mechanism (and prone to break with any javac update, which they don’…

> 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

Yet another reason not to complain when those things go away.

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

#43

Post by dtech »

pron wrote: post #37
josefx wrote: post #30

Earlier quoted context omitted.

Public/private does nothing to change the problems a developer has to deal with. On the JVM side the most widely "hacked" private API was sun.misc.Unsafe, which just could not be implemented using pure Java and Oracle did not design public replacement APIs until the restrictions on it where anounced. > because internals and not being public symbols apparently isn't clear enough. You might as well tell a starving pers…

> Oracle did not design public replacement APIs until the restrictions on it where anounced. The very opposite is true. All the remaining required replacements for Unsafe were put in place in JDK 22, and access to Unsafe has been unrestricted and unencumbered in any way until the upcoming JDK 23 [1]. It is precisely because we know people have come to depend on Unsafe that we had not started to restrict its use until…

Private APIs have been starting to be restricted in previous versions already, requiring command line flags like add-exports=jdk.compiler/com.sun.tools.javac.api

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

#44

Post by giamma »

usrusr wrote: post #29
giamma wrote: post #22

"This policy of implicitly running annotation processors by default may have been reasonable when the feature was introduced in JDK 6 circa 2006, but from a current perspective, in the interest of making build output more robust against annotation processors unintentionally being placed on the class path, the policy should not be the default anymore." This makes sense, especially in light of the growing number of sup…

> but I could bet that most people will fix the issue by simply adding the "all-on" switch to the command line Definitely this. This is a dev experience problem. > Unless maybe JDK 23 comes with some tool to print a catalogue of the annotation processors found in the classpath, with their respective purpose and documentation, so that developers can make an educated guess about what they need or don't need. My thought…

With respect to auto-generating documentation, I was thinking about the possibility for annotation processors implementors to add javadoc comments or yet another annotation to their processor that JDK could use to dump a list of processors found in the classpath as a table with some information.

> javac -proc:info

some.library.Proccessor:

    scans classes annotated  and produces a file in META-INF/services
    for  to be able to load your implementation via ServiceLocator
some.otherlibrary.OtherProcessor:

    .....
With that table creating your inclusion/exclusion files would be easier

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

#45

Post by pron »

dtech wrote: post #43
pron wrote: post #37

Earlier quoted context omitted.

> Oracle did not design public replacement APIs until the restrictions on it where anounced. The very opposite is true. All the remaining required replacements for Unsafe were put in place in JDK 22, and access to Unsafe has been unrestricted and unencumbered in any way until the upcoming JDK 23 [1]. It is precisely because we know people have come to depend on Unsafe that we had not started to restrict its use until…

Private APIs have been starting to be restricted in previous versions already, requiring command line flags like add-exports=jdk.compiler/com.sun.tools.javac.api

Yes, those restrictions were turned on by default at runtime starting in JDK 16 (and at compile-time starting in JDK 9), but they specifically did not include Unsafe [1] precisely because it's been widely used for capabilities for which there were no supported replacements.

Capabilities requiring access to other internals -- such as jdk.compiler/com.sun.tools.javac.api -- do not have supported replacements as they can violate the specification in ways that the specification exists to prevent.

[1]: https://openjdk.org/jeps/260#Critical-internal-APIs-not-enca...

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

#46

Post by pron »

usrusr wrote: post #29
giamma wrote: post #22

"This policy of implicitly running annotation processors by default may have been reasonable when the feature was introduced in JDK 6 circa 2006, but from a current perspective, in the interest of making build output more robust against annotation processors unintentionally being placed on the class path, the policy should not be the default anymore." This makes sense, especially in light of the growing number of sup…

> but I could bet that most people will fix the issue by simply adding the "all-on" switch to the command line Definitely this. This is a dev experience problem. > Unless maybe JDK 23 comes with some tool to print a catalogue of the annotation processors found in the classpath, with their respective purpose and documentation, so that developers can make an educated guess about what they need or don't need. My thought…

> My thoughts on as to how a solution to the dev-x problem might look like go in the same direction: have a way to provide a file with an accept list, another file with a deny list

I'm not involved with this particular change so I'm not familiar with its details, but when it comes to other changes restricting operations that involve extra risk (such as JEPs 260 and 472) the operations are enabled on a per-module basis and, as always, any part of the command line configuration can be easily put into configuration "@files".

One thing to keep in mind is that such configurations should be kept simple because when things become complicated misconfiguration becomes common.

Another thing is that restriction should be the default, especially in situations where most people don't need to disable it. Otherwise things may creep in without the application owner's knowledge (this is like transitioning between high and low entropy; it's always better to start at low entropy, as going in the other direction requires energy).

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

#47

Post by The_Colonel »

tadfisher wrote: post #9
rzwitserloot wrote: post #5

Earlier quoted context omitted.

How hard is this to exploit in practice? Very - this is a silly update in OpenJDK's war against things like Project Lombok. It _seems_ easy to exploit: Just.. get any jar file containing an annotation processor on the classpath and it will be executed as part of `javac` - and almost every java build tool calls javac under the hood. However, this is misleading: _if_ somebody with malicious intent manages to either sne…

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

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

#48

Post by pron »

skissane wrote: post #32
kaba0 wrote: post #15

Earlier quoted context omitted.

> this is a silly update in OpenJDK's war against things like Project Lombok Project Lombok doesn’t use the normal annotation processing system, as that is deliberately “add-only” - you can’t change a class’s implementation, unlike what lombok does. They instead hack into the javac compiler to be able to modify class files, which is a very different mechanism (and prone to break with any javac update, which they don’…

> 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 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. If you want to change the behaviour of a JDK tool in a way that violates its specification, then you need to explicitly configure it to allow that.

The Java platform, however, does support many alternative languages, and that is not a violation of the specification. The only reason Lombok is experiencing a technical challenge that, say, Clojure, Kotlin and Scala do not, is because it insists on being used in a way that hides its operation. If Lombok were used like all other Java platform languages it would experience no friction.

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

#49

Post by kaba0 »

twic wrote: post #23

> As of the April 2024 JDK security updates, support for the "-proc:full" option has been backported to 17u (17.0.11) and 11u (11.0.23) for both Oracle JDK and OpenJDK distributions. Someone tell me again how LTS isn't a think for OpenJDK.

OracleJDK has LTS defined. OpenJDK doesn’t, but as changes made to forks have to be migrated back to the original codebase, it does tend to be a “de facto” LTS version.
Post reply on HN