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

91–100 of 108 posts

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

#91

Post by skissane »

pron wrote: post #80
skissane wrote: post #70

Earlier quoted context omitted.

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

It is a vague claim. How do you decide what is “important”?

And if the backing is a non-public market analyst report, different such reports can reach different conclusions.

> you can test your guess against some publicly-available jobs data such as

Which I note has both JavaScript/TypeScript and Python ahead of Java. Both of which are being used for a lot of server-side applications-whether or not you consider them important is rather subjective. (JS/TS is obviously including a lot of front-end stuff, and that site doesn’t disaggregate front-end from back-end; but Python is almost all back-end.)

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

#92

Post by lucumo »

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?

I know of these:

- Immutables - Autovalue - Mapstruct - Checker Framework

There's quite a list here https://github.com/gunnarmorling/awesome-annotation-processi... (Though I don't think Error Prone is actually an annotation processor, but rather a javac plugin.)

There's some irony in that Immutables and Autovalue are often named as alternatives for people that dislike Lombok's implementation but do like (some of) Lombok's features.

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

#93

Post by kaba0 »

hedora wrote: post #8
derefr wrote: post #6

Earlier quoted context omitted.

I think the difference is that annotation processors run arbitrary code at compile time . An org might have e.g. a CI with a build environment that’s not as well-sandboxed as the test environment for the built app, because a Java compiler isn’t generally expected to (and other than through annotations, usually doesn’t) expose arbitrary code execution abilities to the payload of code being compiled.

Is it actually common practice these days to have Java repositories that do not contain the build scripts, packaging, etc? The last time I looked at maven, it seemed easy enough to have it run arbitrary code directly during the build.

This is mostly about supply chain attacks, where transitive dependencies are at play. Those are mostly just already built jar files, that can still contain annotation processors, but not build scripts.

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

#94

Post by kaba0 »

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…

You might want to take a look at GraalVM’s Isolates. They are lightweight security boundaries, that can even limit things like memory usage and cpu time, for java, js, python among other languages, all within a normal JVM process.

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

#95

Post by kaba0 »

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…

> With manual memory management (and also with reference counting), whenever an object is no longer being used, its memory will be immediately released

Well, this is a fundamental space vs time tradeoff — reclaiming memory takes time, usually on the very same thread that would be doing useful work we care about. This is especially prominent with reference counting, which is the slowest of these all.

Allocators can make reclamation cheap/free, but not every usage pattern fits nicely, and in other cases you are fighting fragmentation.

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

#96

Post by cesarb »

kaba0 wrote: post #95
cesarb wrote: post #84

Earlier quoted context omitted.

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

> With manual memory management (and also with reference counting), whenever an object is no longer being used, its memory will be immediately released Well, this is a fundamental space vs time tradeoff — reclaiming memory takes time, usually on the very same thread that would be doing useful work we care about. This is especially prominent with reference counting, which is the slowest of these all. Allocators can ma…

> Well, this is a fundamental space vs time tradeoff — reclaiming memory takes time, usually on the very same thread that would be doing useful work we care about.

Precisely. Which is fine if you don't have to share that space with anyone else; the example which started this sub-thread ("running ~200 JVMs on the same machine") is one in which that tradeoff goes badly.

But it wouldn't be as much of an issue if the JVMs could coordinate between themselves (and with other processes on the same machine), so that whenever one JVM (or other things like the kernel itself) felt too much memory pressure, the other JVMs could clean some garbage and release it back to the common pool of the operating system.

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

#97

Post by zbentley »

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.

Wouldn’t BFS only require Lombok’s presence at the build step rather than after deployment?

Or is your stance here against it showing up a a transitive during development when including sources written with Lombok? If so, that’s pretty extreme; the build dependency surface of many packages is really huge. Do you have issues with other large or opinionated build depends (protoc, schema downloaders like buf, test frameworks)?

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

#98

Post by pron »

skissane wrote: post #91
pron wrote: post #80

Earlier quoted context omitted.

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

It is a vague claim. How do you decide what is “important”? And if the backing is a non-public market analyst report, different such reports can reach different conclusions. > you can test your guess against some publicly-available jobs data such as Which I note has both JavaScript/TypeScript and Python ahead of Java. Both of which are being used for a lot of server-side applications-whether or not you consider them…

> It is a vague claim. How do you decide what is “important”?

Java is so clearly ahead and by so much that it doesn't really matter, but generally, "important" can mean size, expected lifetime, criticality for business or some combination of them.

> Which I note has both JavaScript/TypeScript and Python ahead of Java.

Python is about on par or slightly ahead but given that the vast majority of the uses of Java are for server side applications, while the vast majority of Python uses are for data analysis etc., so clearly Java is much more favoured for serious applications (not to mention Python's serious scaling issue). JS is indeed significantly ahead, but again, clearly the vast majority of JS use is for web client programming. Node.js was very big for a while, but it isn't as big anymore. Again, ask any market analyst. Perhaps in 2035 some new language is going to show up and unseat Java, but in 2024, Java is the language of choice for serious server-side apps -- not the majority choice (i.e. all other languages combined may make up more than 50%), perhaps, but the first choice nonetheless.

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

#99

Post by skissane »

pron wrote: post #98
skissane wrote: post #91

Earlier quoted context omitted.

It is a vague claim. How do you decide what is “important”? And if the backing is a non-public market analyst report, different such reports can reach different conclusions. > you can test your guess against some publicly-available jobs data such as Which I note has both JavaScript/TypeScript and Python ahead of Java. Both of which are being used for a lot of server-side applications-whether or not you consider them…

> It is a vague claim. How do you decide what is “important”? Java is so clearly ahead and by so much that it doesn't really matter, but generally, "important" can mean size, expected lifetime, criticality for business or some combination of them. > Which I note has both JavaScript/TypeScript and Python ahead of Java. Python is about on par or slightly ahead but given that the vast majority of the uses of Java are fo…

I’ve been spending the last few months reimplementing Java backend code in Python. I’m sure I’m not the only one. It actually wasn’t originally my idea - I fought the decision and was initially upset about it, but now I’ve been living with it I’m actually glad they forced it on me :)

Yes it is true that Python can have limitations with high scale. But there are solutions to that (multi-process Python app servers for example). And the Python core performance story is improving (GIL removal is finally happening, JIT is moving into the core.) Plus there are a massive number of Java/Spring/etc business apps/microservices which aren’t actually high scale (I’ve written some myself) and could just as easily be done in Django/Flask/etc

The thing with saying that most Python is for data analysis, is what starts out as some ad hoc data analysis or data science prototype sooner or later morphs into a production service. And maintaining the same language from prototype to production makes life a lot easier-especially when the data science team decides they have to fundamentally change algorithms to improve performance leading them to rewrite half of it in the middle of the project. It is much easier to teach a backend developer Python (many of whom already know it anyway) than try to get a data scientist to learn Java.

Python is the de facto standard language of AI, and AI initiatives are driving a lot of Python adoption. But once you are using it for AI, why not consider it for non-AI use cases too? There isn’t a hard boundary between the two anyway - a lot of the Python code I’ve been writing recently has been related to getting OAuth tokens to talk to various pre-existing microservices (mostly Java with some node.js) and although I wrote that code for AI use cases it is obviously very applicable to non-AI use cases too.

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

#100

Post by vips7L »

skissane wrote: post #99
pron wrote: post #98

Earlier quoted context omitted.

> It is a vague claim. How do you decide what is “important”? Java is so clearly ahead and by so much that it doesn't really matter, but generally, "important" can mean size, expected lifetime, criticality for business or some combination of them. > Which I note has both JavaScript/TypeScript and Python ahead of Java. Python is about on par or slightly ahead but given that the vast majority of the uses of Java are fo…

I’ve been spending the last few months reimplementing Java backend code in Python. I’m sure I’m not the only one. It actually wasn’t originally my idea - I fought the decision and was initially upset about it, but now I’ve been living with it I’m actually glad they forced it on me :) Yes it is true that Python can have limitations with high scale. But there are solutions to that (multi-process Python app servers for…

> I’ve been spending the last few months reimplementing Java backend code in Python.

Lots of people are doing the opposite once they hit scale. DoorDash went from Python to Kotlin/JVM for their backend: https://doordash.engineering/2021/05/04/migrating-from-pytho...

Post reply on HN