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

61–70 of 108 posts

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

#61

Post by pron »

sixcorners wrote: post #57
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…

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

That's one option. Quasar was configured to run as a runtime agent while the Lombok compiler runs at compile-time, but the Lombok compiler could perhaps indeed be implemented as a Java agent of javac's. This, however, would also require a special configuration of javac, just like all other alternatives. A simpler option is to offer a separate launcher for that compiler (and/or a special build-tool plugin, which is also what Quasar did in its AOT mode).

No matter what, code that wishes to break the guarantees that JDK programs want to make needs to configure that program in some special way so that there's some record, auditable by the application author, saying "this program has been modified in a way that may make it behave not in accordance with its specification".

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

#62

Post by skissane »

pron wrote: post #59
skissane wrote: post #58

Earlier quoted context omitted.

> 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 s…

> You don't have to like this state of affairs,

This attitude is part of why I have given up on Java – despite having spent so much of my career on it – and nowadays avoid it as much as I can. In my own mind it is a legacy language - if I have some existing code base in Java, extending/enhancing it might be the path of least resistance, but for a greenfield project it would be far from my first choice.

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

#63

Post by sixcorners »

pron wrote: post #61
sixcorners wrote: post #57

Earlier quoted context omitted.

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

That's one option. Quasar was configured to run as a runtime agent while the Lombok compiler runs at compile-time, but the Lombok compiler could perhaps indeed be implemented as a Java agent of javac's. This, however, would also require a special configuration of javac, just like all other alternatives. A simpler option is to offer a separate launcher for that compiler (and/or a special build-tool plugin, which is al…

You could do a lot of the lombok things as a runtime agent. I think @ToString, @EqualsAndHashCode, @Synchronized, @Getter(lazy=true), @UtilityClass, @Delegate, and @Cleanup could all be implemented in a runtime agent. Most of the rest could work as a runtime agent too as long as you were willing to type out the method signature (plus maybe a native keyword) for the things you actually want to link against at build time.

I think this would end up being way more difficult to use though and I think it would be perceived to have way more risk compared to lombok as it is now. What do you think?

Also is something wrong with paralleluniverse.co? The root domain seems to go to a gambling site?

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

#64

Post by pron »

skissane wrote: post #62
pron wrote: post #59

Earlier quoted context omitted.

> 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 s…

> You don't have to like this state of affairs, This attitude is part of why I have given up on Java – despite having spent so much of my career on it – and nowadays avoid it as much as I can. In my own mind it is a legacy language - if I have some existing code base in Java, extending/enhancing it might be the path of least resistance, but for a greenfield project it would be far from my first choice.

Any philosophy, let alone policy, isn't for everyone, and we want to make our policies clear so that the people who align with them will choose the platform, while those who do not -- won't. It is due to this careful philosophy and policy that places an emphasis on integrity (safety) and specification that has made Java the #1 chosen language for new important server-side applications today; i.e. it is more people's first choice than any other language for this domain (despite others who have considered it a legacy language since 2006).

Java says that an application can monkey-patch whatever it likes but that a library needs to be given that permission by the application. If that's not what you need, then Java isn't for you and you should consider it a legacy language for your needs. Like some other languages and unlike others we will continue placing an emphasis on safety, as that appeals to most of our users and hopefully to future users, too. Those who want to easily monkey-patch anything from any code without controls -- which is also a valid requirement -- also have a selection of languages to choose from.

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

#65

Post by beeboobaa3 »

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

Earlier quoted context omitted.

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.

It's clear you are just spiteful and have absolutely no clue what you are talking about.

Lombok does not get pulled in as a transitive dependency unless the author of your dependency fucked up their build. RTFM and you're good. Even if they fucked up, you can just exclude the transitive dependency. Easy.

Lombok produces bytecode that could have been written by hand. You will not be able to tell the difference when using these compiled classes.

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

#66

Post by beeboobaa3 »

frant-hartm wrote: post #24
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…

There are multiple attack vectors via the supply chain that this new settings prevents. Sure, if the compromised library is one of your core libraries that runs during build, test and runtime, then this does not help. But there are test libraries only compile time only libraries (hello lombok?) transitive dependencies that may not be used during runtime (or run only in rare code paths) Sometimes compromising the buil…

> test libraries only

Typically runs during build (unit tests), just like annotation processors.

> compile time only libraries (hello lombok?)

Right, annotation processors. This is what we're discussing.

> transitive dependencies that may not be used during runtime (or run only in rare code paths)

Irrelevant. If they are compromised they will just set themselves up as an SPI and run on JVM start.

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

#67

Post by beeboobaa3 »

pron wrote: post #52
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 removin…

Never seen anyone ask for you to get rid of security manager. Fix and improve it, sure. But no, it had to go and we did not get a suitable replacement. RIP.

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

#68

Post by the-alchemist »

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?

Lombok is not affected by this, as it is not an annotation processor.

The most popular annotation processor that I've seen "in the wild" is the Hibernate Metamodel Generator (https://hibernate.org/orm/tooling/).

Also, Immutables (https://immutables.github.io/), my favorite Lombok alternative, is affected.

Of note, you can bypass this more-security-concious approach by just passing `-prof:full` to javac.

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

#69

Post by the-alchemist »

Don't quite understand the hate. This is very reasonable behavior for a compiler in 2024. I would even go so far as to say that a compiler should never execute any user code by default.

Imagine if gcc could automatically, by default, download some shared library and include it in the build because of a special macro included by a random header file on the system.

Of course, this change is optional (just add `-proc:full` to the command line) if you want the old, less secure behavior.

Also, Lombok is not affected because it's not an annotation processor. (Also, look at Immutables: https://immutables.github.io/).

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

#70

Post by skissane »

pron wrote: post #64
skissane wrote: post #62

Earlier quoted context omitted.

> You don't have to like this state of affairs, This attitude is part of why I have given up on Java – despite having spent so much of my career on it – and nowadays avoid it as much as I can. In my own mind it is a legacy language - if I have some existing code base in Java, extending/enhancing it might be the path of least resistance, but for a greenfield project it would be far from my first choice.

Any philosophy, let alone policy, isn't for everyone, and we want to make our policies clear so that the people who align with them will choose the platform, while those who do not -- won't. It is due to this careful philosophy and policy that places an emphasis on integrity (safety) and specification that has made Java the #1 chosen language for new important server-side applications today; i.e. it is more people's…

> Java the #1 chosen language for new important server-side applications today

What is the evidence for that claim?

Post reply on HN