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

81–90 of 108 posts

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

#81

Post by lucumo »

kaba0 wrote: post #15
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…

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

Lombok uses the annotation processor to bootstrap itself. That particular part of Lombok is uncontroversial and is in fact well-documented and used by other tools.

The parts of Lombok you have an issue with are not impacted by this change.

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

#82

Post by lucumo »

the-alchemist wrote: post #68
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.

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

Lombok uses an annotation processor to bootstrap itself.

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

#83

Post by beeboobaa3 »

pjmlp wrote: post #79
beeboobaa3 wrote: post #77

Earlier quoted context omitted.

All of those plugins have shit latency. This model is not suitable for games, at all. The plugins need to be able to render their own graphics, which happens at 60~120fps. Also have you ever tried running ~200 JVMs on the same machine?

Which games are you shipping in Java that depend on Security Manager's existence? Most games are deployed as services nowadays, they have a full network between their rendering and game logic. Yes, that is what Cloud Services do all the time across the globe in Kubernetes.

> Which games are you shipping in Java that depend on Security Manager's existence?

None, because it didn't pan out like I described above. No sense continuing developing something using a technology that is due to be removed. The project was abandoned.

This was for a third-party Old School RuneScape client which supports client side Java plugins. The current approach is to manually vet each plugin and its update before it is made available for users to install.

> Most games are deployed as services nowadays, they have a full network between their rendering and game logic.

Networked games do not communicate at 60~120fps. That's just not how it works, writing efficient netcode with client-side prediction is important for a reason.

> Yes, that is what Cloud Services do all the time across the globe in Kubernetes.

Yeah, on the servers they pay several grand a month for. Not on end user craptops which is where games obviously run.

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

#84

Post by cesarb »

beeboobaa3 wrote: post #77
pjmlp wrote: post #76

Earlier quoted context omitted.

Success of VSCode plugins, microservices, containers, and out of process VSTs, have proven that on modern hardware people favour stability and improved security, over the in process plugins. .NET also dropped their version of SecurityManager when they did the Core rewrite.

All of those plugins have shit latency. This model is not suitable for games, at all. The plugins need to be able to render their own graphics, which happens at 60~120fps. Also have you ever tried running ~200 JVMs on the same machine?

> Also have you ever tried running ~200 JVMs on the same machine?

This is one of my pet peeves with the "garbage collection" model of memory management: it does not play well with other processes in the same machine, especially when these other processes are also using garbage collection.

With manual memory management (and also with reference counting), whenever an object is no longer being used, its memory will be immediately released (that is, the memory use of a process is always at the minimum it needs, modulo some memory allocator overhead). With garbage collection, it will be left around as garbage, and its memory will only be released once the process decides that there's too much garbage; but that decision does not take into account that other processes (and even the kernel for its page cache) might have a better use for that memory.

This works fine when there's a single process using most of the memory on the machine, and its garbage collection limits have been tuned to leave enough for the kernel to use for its caches (I have seen in practice what happens when you give too much memory to the JVM, leaving too little for the kernel caches); but once you have more than a couple processes using garbage collection, they'll start to fight over the memory, unless you carefully tune their garbage collection limits.

It would be really great if there were some kernel API which allowed for multiple processes (and the kernel caches) to coordinate their garbage collection cycles, so that multiple garbage collectors (and in-process caches) would cooperate instead of fighting each other for memory, but AFAIK such API does not exist (the closest I know of is MADV_FREE, which is good for caches, but does not help with garbage collection).

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

#85

Post by beeboobaa3 »

pron wrote: post #78
beeboobaa3 wrote: post #73

Earlier quoted context omitted.

> The fact that more robust, effective, and relevant security mechanisms are now not only available but have grown far more popular in Java applications Like what? Or are you referring to isolating the entire JVM? That's pointless for plugin systems that don't want to deal with the ridiculous amount of overhead that'd entail. > SecurityManager was (actually, still is as it has not been removed yet) simultaneously one…

> Like what? Like all the security mechanisms that are used by virtually all security-sensitive Java applications, from cgroups/containers and firewalls to encryption protocols and serialization filters (they're not using SM). > That's pointless for plugin systems that don't want to deal with the ridiculous amount of overhead that'd entail. You cannot offer secure server-side plugins (i.e. on shared machines) with a…

> Like all the security mechanisms that are used by virtually all security-sensitive Java applications, from cgroups/containers and firewalls to encryption protocols and serialization filters (they're not using SM).

Not reasonable to implement across all platforms users may choose to run a game on. This discussion is about a game client, not the server. A replacement solution would have to work everywhere Java runs, and should not impact the user's system in any noticeable way.

> but SM wasn't as robust as some imagined it was, either.

The docs, at the time, implied SecurityManager was the way to go to run untrusted code, similar to Applets.

Since there is no reasonable alternative and the JDK team has seemingly given up on this feature we've instead opted to require all plugins to be source-available, manually vet the code, and build & distribute via our CI & only allow the client to load plugins signed by our CI.

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

#86

Post by beeboobaa3 »

pjmlp wrote: post #72
beeboobaa3 wrote: post #65

Earlier quoted context omitted.

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

Except you are forgetting that building dependencies from source is also something that happens in real life, as it is opening such projects in IDEs. In one thing you are right, I make my life easier by choosing other alternatives when possible.

Rather uncommon in the java world. Anyway, you can just delombok if you hate it so much.

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

#87

Post by pron »

beeboobaa3 wrote: post #85
pron wrote: post #78

Earlier quoted context omitted.

> Like what? Like all the security mechanisms that are used by virtually all security-sensitive Java applications, from cgroups/containers and firewalls to encryption protocols and serialization filters (they're not using SM). > That's pointless for plugin systems that don't want to deal with the ridiculous amount of overhead that'd entail. You cannot offer secure server-side plugins (i.e. on shared machines) with a…

> Like all the security mechanisms that are used by virtually all security-sensitive Java applications, from cgroups/containers and firewalls to encryption protocols and serialization filters (they're not using SM). Not reasonable to implement across all platforms users may choose to run a game on. This discussion is about a game client, not the server. A replacement solution would have to work everywhere Java runs,…

> This discussion is about a game client, not the server.

Well, I didn't know that's what this discussion is about, but sure, we can talk about that. :)

> A replacement solution would have to work everywhere Java runs, and should not impact the user's system in any noticeable way.

Except 1. there's little demand for such a system in the JDK (and, as I've said, you can do something reasonable on your own with modules, class loaders, and a tiny bit of instrumentation) and 2. I don't think anyone offers such a general mechanism, especially as different programs would have different requirements on robustness, some of which cannot be achieved in-process (e.g. web browsers, the prime example of a program running untrusted code, these days use process isolation).

> The docs, at the time, implied SecurityManager was the way to go to run untrusted code, similar to Applets.

Yes, that was the best way; whether or not the best was good enough is another matter.

> Since there is no reasonable alternative and the JDK team has seemingly given up on this feature we've instead opted to require all plugins to be source-available, manually vet the code, and build & distribute via our CI & only allow the client to load plugins signed by our CI.

I would say that even SM may not have given you what you need, but yeah with it or without it, some other approaches are required for better fortification. I would recommend additionally looking into some sort of basic sandboxing -- which will control which APIs are exposed to the plugin -- using modules and instrumentation (that can inspect/restrict some operations that are exported by, say, the java.base module).

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

#88

Post by beeboobaa3 »

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.

I like java, but it's unfortunate the current stewards come off as unlikable on social media. Most of the work they're doing is great, though.

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

#89

Post by pjmlp »

cesarb wrote: post #84
beeboobaa3 wrote: post #77

Earlier quoted context omitted.

All of those plugins have shit latency. This model is not suitable for games, at all. The plugins need to be able to render their own graphics, which happens at 60~120fps. Also have you ever tried running ~200 JVMs on the same machine?

> Also have you ever tried running ~200 JVMs on the same machine? This is one of my pet peeves with the "garbage collection" model of memory management: it does not play well with other processes in the same machine, especially when these other processes are also using garbage collection. With manual memory management (and also with reference counting), whenever an object is no longer being used, its memory will be i…

Contrary to common culture, if memory strain is an issue with GC, it is even worse with algorithms that cannot cope with fragmentation, or have to keep going down into the OS for memory management.

Optimizations to avoid fragmentation, locking contention or stop the world domino effect in reference counting algorithms, eventually end up being a poor implementation of a proper GC.

Finally, just because a language has a GC, doesn't mean it also doesn't offer language features to do manually memory management and reference counting if one feels like it.

While Java failed to build up on the learnings from Eiffel, Oberon, Modula-3, there are others that did, like D, Nim, C#.

Not all GCs are born alike.

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

#90

Post by vips7L »

beeboobaa3 wrote: post #88
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.

I like java, but it's unfortunate the current stewards come off as unlikable on social media. Most of the work they're doing is great, though.

I particularly like the current stewards. They've done a great job and have been consistently putting Java and the JVMs best interest at the forefront.
Post reply on HN