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

71–80 of 108 posts

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

#71

Post by pron »

beeboobaa3 wrote: post #67
pron wrote: post #52

Earlier quoted context omitted.

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.

Of course you did -- many, many, many times -- you just didn't know that that's what you were seeing.

People rarely directly asks for an old feature that they're not using to be removed. Rather, they ask for new features that the old feature interferes with. SecurityManager imposed a significant tax on nearly every new feature, as it interacts with just about everything, slowing down much of the work on the JDK. SecurityManager was (actually, still is as it has not been removed yet) simultaneously one of the most expensive features and least used features in the JDK. Everyone who asked for new significant features effectively asked for SM to be removed, as they could not be delivered -- certainly not as expeditiously -- with it in place.

In fact, as early as JDK 8, new features (such as streams) had to work around SM (simply documenting that it could not be effectively used in combination with the new feature; few people noticed because few people used SM). With time, it became ridiculous to say that SM is ineffective when used in combination with more and more new features (e.g. virtual threads, and the same would have been the case for Leyden [1]), and it still kept exacting a tax on most uses, so it had to be removed if we were to give people the features they were asking for. The fact that more robust, effective, and relevant security mechanisms are now not only available but have grown far more popular in Java applications than SM ever was only meant that the whatever arguments there may have been to keep it and delay and significantly complicate new features were weak.

[1]: I shudder to think how Leyden could be done while keeping SM in some functional state.

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

#72

Post by pjmlp »

beeboobaa3 wrote: post #65
pjmlp wrote: post #55

Earlier quoted context omitted.

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

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

#73

Post by beeboobaa3 »

pron wrote: post #71
beeboobaa3 wrote: post #67

Earlier quoted context omitted.

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.

Of course you did -- many, many, many times -- you just didn't know that that's what you were seeing. People rarely directly asks for an old feature that they're not using to be removed. Rather, they ask for new features that the old feature interferes with. SecurityManager imposed a significant tax on nearly every new feature, as it interacts with just about everything, slowing down much of the work on the JDK. Secu…

> 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 of the most expensive features and least used features in the JDK

Well, yeah. It was hard to implement, I'd know because I was working on integrating it in a plugin framework I was working on at the time. But we eventually abandoned that idea when we heard the announcement of SM being deprecated with no replacement.

Would've been great to be able to support sandboxed plugins for the game we were working on.

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

#74

Post by pjmlp »

skissane wrote: post #70
pron wrote: post #64

Earlier quoted context omitted.

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?

Any real world market analysis survey that shows what languages are used across the industry, not only SV startups, when performance matters.

Plus the whole development toolchain for the mobile OS with 80% of the world market, even if Kotlin is favoured, there is plenty of Java on Android Studio, Gradle, Bazel, AOSP, and Maven Central.

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

#75

Post by cies »

the-alchemist wrote: post #69

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:fu…

I find it a great improvement. Secure by default.

To me the hate started when Java went from a statically compiled languages, to a half way dynamic language that does a fair bit of compilation at application startup, based on a bunch of annotations. Suddenly many Java projects introduced Ruby-on-Rails level "magic" (yes looking at you Spring(Boot)).

I'm not totally against annotations, but it's easier to over use them just to remove a bit of boiler plate.

To me Kotlin's approach makes more sense: reduce boilerplate by making the language more expressive, adding KClass and KFunction (https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.reflect) while mostly avoiding annotations and exceptions.

Kotlin also has a nice story for immutability.

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

#76

Post by pjmlp »

beeboobaa3 wrote: post #73
pron wrote: post #71

Earlier quoted context omitted.

Of course you did -- many, many, many times -- you just didn't know that that's what you were seeing. People rarely directly asks for an old feature that they're not using to be removed. Rather, they ask for new features that the old feature interferes with. SecurityManager imposed a significant tax on nearly every new feature, as it interacts with just about everything, slowing down much of the work on the JDK. Secu…

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

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.

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

#77

Post by beeboobaa3 »

pjmlp wrote: post #76
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…

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?

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

#78

Post by pron »

beeboobaa3 wrote: post #73
pron wrote: post #71

Earlier quoted context omitted.

Of course you did -- many, many, many times -- you just didn't know that that's what you were seeing. People rarely directly asks for an old feature that they're not using to be removed. Rather, they ask for new features that the old feature interferes with. SecurityManager imposed a significant tax on nearly every new feature, as it interacts with just about everything, slowing down much of the work on the JDK. Secu…

> 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 mechanism like SM, and even client-side plugins now use different, simpler, mechanisms.

> Would've been great to be able to support sandboxed plugins for the game we were working on.

It's not that hard to offer some in-process client-side sandboxing using modules and some instrumenting class loaders without SM. It may not be very robust, but SM wasn't as robust as some imagined it was, either.

There aren't in-process isolation mechanisms robust enough for server-side use -- where DoS attacks are a common threat -- and even on the client it would be both safer and simpler to sandbox the entire process or make no security claims (many client-side programs with plugins opt for the latter).

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

#79

Post by pjmlp »

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?

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.

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

#80

Post by pron »

skissane wrote: post #70
pron wrote: post #64

Earlier quoted context omitted.

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?

Ask for a report from a market analyst.

Out of curiosity, though, what language would you imagine is now chosen more frequently than Java for important server-side applications? (you can test your guess against some publicly-available jobs data such as https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...)

Post reply on HN