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

101–108 of 108 posts

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

#101

Post by kaba0 »

cesarb wrote: post #96
kaba0 wrote: post #95

Earlier quoted context omitted.

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

It might even be a problem without garbage collection - linux might be a big culprit here with its tendency to over-allocate. Some signal would be welcome that says “try to free some memory” - I believe OSX has something like that.

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

#102

Post by eosterlund »

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…

I'm building this JEP for automatic heap sizing right now to address this when using ZGC: https://openjdk.org/jeps/8329758 I did in fact run exactly 200 JVMs, running a heterogeneous set of applications, and it ran totally fine. By totally fine I mean that the machine got rather starved of CPU and the programs run slowly due to having 12x more JVMs than cores, but they could all share the memory equally without blowing up anyway. I think it's looking rather promising.

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

#103

Post by skissane »

vips7L wrote: post #100
skissane wrote: post #99

Earlier quoted context omitted.

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

From the article you linked:

> our monolith was built on old versions of Python 2 and Django, which were rapidly entering end-of-life for security support

That doesn't seem to be an issue with Python scalability per se. There are massive creaking monolithic Java apps out there, stuck on old versions of the JDK and various Java libraries, which are just as brittle.

Also, if the discussion is about defending the design choices of the Java language, this blog post doesn't really support that defence, given that while they did choose the JVM as a platform, they also selected Kotlin over Java

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

#104

Post by vips7L »

skissane wrote: post #103
vips7L wrote: post #100

Earlier quoted context omitted.

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

From the article you linked: > our monolith was built on old versions of Python 2 and Django, which were rapidly entering end-of-life for security support That doesn't seem to be an issue with Python scalability per se . There are massive creaking monolithic Java apps out there, stuck on old versions of the JDK and various Java libraries, which are just as brittle. Also, if the discussion is about defending the desig…

I think you're selectively reading that to fit your narrative. The design choices of the Java language are the design choices of the Java Platform and that's exactly why they chose it:

> CPU-efficient and scalable to multiple cores

> Easy to monitor

> Supported by a strong library ecosystem, allowing us to focus on business problems

> Able to ensure good developer productivity

> Reliable at scale

> Future-proofed, able to support our business growth

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

#105

Post by derefr »

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.

> Is it actually common practice these days to have Java repositories that do not contain the build scripts, packaging, etc?

It's not that they don't contain these things; but rather that you can (and people often do) set things up so that the build scripts + packaging can be "more trusted" than the source files.

If you've ever tried to set up CI on e.g. Github for an open-source project, then you might be familiar with the concept of a "PR attack" — where an external contributor forks your project, submits a PR that adds malicious code to your build scripts (to e.g. exfiltrate your build-time secrets); and then your CI "helpfully" runs those build scripts (in order to e.g. evaluate that the PR compiles + passes tests + lints in order to determine whether it should be blocked from merging or not.)

GitHub and others have come up with ways around "PR attacks", that involve treating triggered automation workflows for external PRs differently: in these workflow runs, the core of the workflow — the workflow manifest file — is sourced not from the contributor's branch, but rather from the base branch that the PR aims to merge to.

Now, it's up to you, as a repo maintainer, to come up with a way to bootstrap that little bit of safety (protected workflow manifest) into whole-repo "PR attack" arbitrary-code-execution protection. But usually doing so involves:

1. moving as much of the logic for executing your build as possible out of the repo itself and into buildpacks / "action" repos; and

2. sourcing any scripts you do need for the build, not from the worktree of the external PR, but rather by having the workflow environment also check out the base branch, and then running those scripts against your worktree. (IIRC the most common pattern for this is that you check out the base branch worktree, blow away its src/ dir, symbolic-link the PR branch's worktree's src/ into the base branch as src/, and then run your build in the context of the base branch.)

This approach is incomplete, however, if the PR's source files can themselves be the source of arbitrary code execution.

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

#106

Post by skissane »

vips7L wrote: post #104
skissane wrote: post #103

Earlier quoted context omitted.

From the article you linked: > our monolith was built on old versions of Python 2 and Django, which were rapidly entering end-of-life for security support That doesn't seem to be an issue with Python scalability per se . There are massive creaking monolithic Java apps out there, stuck on old versions of the JDK and various Java libraries, which are just as brittle. Also, if the discussion is about defending the desig…

I think you're selectively reading that to fit your narrative. The design choices of the Java language are the design choices of the Java Platform and that's exactly why they chose it: > CPU-efficient and scalable to multiple cores > Easy to monitor > Supported by a strong library ecosystem, allowing us to focus on business problems > Able to ensure good developer productivity > Reliable at scale > Future-proofed, ab…

> I think you're selectively reading that to fit your narrative.

Please don’t tell people they are selectively reading things, because if you are going to do that, I can do the same right back to you. You will note up-thread I’m complaining about gaps in the Java language (not platform) which are why Lombok exists, and the Java language maintainers’ unwillingness to provide official solutions within the language to address that - which is something Kotlin handles much better (it has some Lombok-like features, plus its DSL support). So, just as you accuse me of selectively reading that blog post to fit my narrative, I can accuse you of selectively reading this thread to fit yours - but mutual accusations of “selective reading” aren’t really adding anything useful to the conversation, are they?

> The design choices of the Java language are the design choices of the Java Platform and that's exactly why they chose it:

No. As I said, the design choices of the Java language not to provide many Lombok-style features, whereas Kotlin does, has nothing to do with the JVM as a platform

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

#107

Post by vips7L »

skissane wrote: post #106
vips7L wrote: post #104

Earlier quoted context omitted.

I think you're selectively reading that to fit your narrative. The design choices of the Java language are the design choices of the Java Platform and that's exactly why they chose it: > CPU-efficient and scalable to multiple cores > Easy to monitor > Supported by a strong library ecosystem, allowing us to focus on business problems > Able to ensure good developer productivity > Reliable at scale > Future-proofed, ab…

> I think you're selectively reading that to fit your narrative. Please don’t tell people they are selectively reading things, because if you are going to do that, I can do the same right back to you. You will note up-thread I’m complaining about gaps in the Java language ( not platform) which are why Lombok exists, and the Java language maintainers’ unwillingness to provide official solutions within the language to…

You realize that conversations can evolve right? I merely pointed out that your anecdotal evidence of you rewriting from Java -> Python could be shown in the reverse direction of people moving away from Python. You then claimed this was not for scalability issues, which in fact it was if you didn't selectively read the article to fit your anecdotal evidence. I _never claimed this was about language features_.

Cheers.

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

#108

Post by skissane »

vips7L wrote: post #107
skissane wrote: post #106

Earlier quoted context omitted.

> I think you're selectively reading that to fit your narrative. Please don’t tell people they are selectively reading things, because if you are going to do that, I can do the same right back to you. You will note up-thread I’m complaining about gaps in the Java language ( not platform) which are why Lombok exists, and the Java language maintainers’ unwillingness to provide official solutions within the language to…

You realize that conversations can evolve right? I merely pointed out that your anecdotal evidence of you rewriting from Java -> Python could be shown in the reverse direction of people moving away from Python. You then claimed this was not for scalability issues, which in fact it was if you didn't selectively read the article to fit your anecdotal evidence. I _never claimed this was about language features_. Cheers.

> You then claimed this was not for scalability issues, which in fact it was if you didn't selectively read the article to fit your anecdotal evidence

They said at the start of the article that the primary motivation for finding a new technology stack was they were running on Python 2 and old versions of Django, and they also had the kind of issues which commonly happen with monolithic apps (slow bisection).

They then said they wanted to look for a new platform. And some of the reasons why they decided to pick Kotlin/JVM over CPython3 because they viewed the former as having likely better scalability and manageability.

If anyone here is "reading selectively", it is you, not me – you are mixing up (1) their original reasons for looking for a new platform (2) the reasons they chose for picking the new platform they did. If you read the blog post carefully, the reason they chose Kotlin/JVM was because they expected it would scale more easily in the future – which might be true – but the present day scalability issues they were having were due to an outdated stack and a monolithic architecture (problems which can occur on any technology stack), not those future expectations.

Post reply on HN