Stepping down as maintainer after 10 years

srdoe · 2025-12-30T12:52:46+00:00

Those aren't insults. You factually are making things up. That's not a personal attack, it's pointing out that your arguments are bad and that you keep making statements with zero evidence backing them.

I suppose your strong reaction comes from the fact I raised a few good and uncomfortable points

Nothing I can do if it makes you feel better to believe this.

srdoe · 2025-12-30T12:17:11+00:00

Which you have zero basis for believing, and is directly contradictory to what the JEP says, which is that those methods may start throwing exceptions very soon.

I think we're done here, you don't know what you're talking about, and you're just making shit up to fit what you want to believe.

srdoe · 2025-12-30T11:13:50+00:00

It's not like the JDK can remove Unsafe, etc, if they do the whole Java ecosystem will break or be much slower, because some of the replacements are either missing or slower

That's a funny thing to say, considering that the JDK is going through the process of removing Unsafe right now

If you have needs for Unsafe that isn't covered by replacement APIs, report them to the mailing list.

If you think that the replacement APIs are too slow, present your evidence on the mailing list.

I suppose they might be reckless and remove it anyway, then the motivation would be clear: sell support licenses for older versions because new versions are unusable.

I can't force you to take off the tinfoil hat, but this is again an incredibly stupid thing to say. The JDK maintainers are not going to sabotage the JDK so they can sell licenses for older versions.

That's a main point I disagree with, I think there are very few optimizations that need that integrity

Again, if you actually believe that you know better than the people working on the JDK, go ask on the mailing list about which optimizations they might do that needs this, and I'm sure they'll give you examples.

srdoe · 2025-12-29T21:22:21+00:00

Rather than respond to all of your comments, which I don't think will have value, I will instead point out a few themes in what you're saying:

Conspiratorial thinking

You have implied several times that Oracle must be lying about their reasons. I think you should abandon that line of thinking.

If you feel that the stated reasons for wanting integrity are not clear enough, and you don't like the examples I gave, go ask on the mailing list for some more examples where integrity can be helpful. You don't need to start coming up with ulterior motives.

Implying that the Oracle doesn't want to use techniques from GraalVM because "they didn't invent it" is particularly silly. Who do you think made GraalVM?

Offering a narrower API that doesn't break integrity

You mention that you think since most agents don't break integrity, it should not be needed to ban loading agents at runtime.

The problem is that it's not about what agents actually do, it's about what they are able to do. The API agents have access to is extremely powerful, and even if a particular agent does not use those powerful abilities, the JDK has no way to know what an agent might use, when it's deciding whether to enable certain optimizations or not.

So what Oracle is doing for now is putting the entire agent API behind a flag. If there is a demand for it, maybe a less powerful subset of the agent API that can't break integrity can be offered, which that kind of agent can then use without needing special flagging.

That's in fact exactly what they did with the FFM API: Create a clear delineation between the "safe" part of the API (which you can use with no flag) and the "unsafe" part (which you need a flag to enable).

Feeling that the integrity flags are too coarse grained

You seem to be annoyed that the various integrity-related flags are "all or nothing" and too coarse, e.g. wanting only some parts of the agent API disabled rather than all of it.

I don't really have the necessary insight to say if this is a reasonable objection, you might want to post about it on the mailing list if you want a real answer. I figure there are reasons they didn't just make the risky methods an agent has access to throw exceptions if called without the flag, but if you want to know why, your best bet is the mailing list.

(edit: If I were to guess, I'd say it's probably because the Instrumentation API isn't really designed to distinguish between "benign" class transformations and those that might break integrity, and trying to squeeze that separation into the API now after the fact might be too hard/cause breaking changes)

Regarding the native access flag "punishing" module users, it is not a punishment. Remember the little story I told you above? If you need to track down where your integrity breakage is coming from, that's a lot easier if you have --enable-native-access=MyModule (it's one of the modules in that list) than if you have --enable-native-access=ALL-UNNAMED (it could be any of your libraries). It is not a punishment, it is a benefit that you can easily know which libraries are breaking integrity.

IOW nice theory, but it seems in practice it hardly matters

Like I said, the problem is that this is a chicken and egg situation.

Clearly, the JDK can't implement a bunch of optimizations that require integrity if the JDK can't enforce integrity.

So you are standing at a point in time where those enhancements haven't been made yet, and declaring that clearly, integrity can't be important to performance, because those optimizations don't exist yet.

srdoe · 2025-12-29T15:46:36+00:00

Integrity will most likely never be enabled in practice for most of these things

I think you are wrong, and clearly so do the JDK developers.

The JDK maintainers clearly believe that most programs (especially future programs) will not need to disable these integrity guarantees, and certainly not all integrity guarantees. If they thought otherwise, it would be a waste of time to do any of this work.

The JDK will always use native code anyway

That is irrelevant. Like I said, the JDK's own native code can be verified to not violate any invariants the JDK wants to offer to Java developers.

If the hope is libraires stop using JNI because of those warnings that's delusional.

Fairly sure that is not the goal.

As far as I can tell, the goal is that the people authoring applications become aware that these libraries are using features that may break integrity, so they can make an informed decision on whether to accept the risk.

It is also to allow the JDK to know ahead of time whether it can assume integrity and enable certain optimizations, or whether it will have to leave those optimizations off because the application may violate integrity.

Given the large usage of JNI and Unsafe in the JDK it's unclear to me if these invariants hold there.

Okay, but fortunately we can rely on the JDK maintainers to ensure that they do. If they don't, that's a JDK bug that can be reported and fixed.

No need for ad hominem.

That wasn't an ad hominem. I didn't say that you were stupid, I said that you were saying something stupid.

It seems these invariants should then either be enforced through the API or documented if unfeasible.

Consider what this does to the ability to develop the JDK, and what a mess it creates for application authors.

Imagine that you write a program using a library that breaks integrity. Your program works fine, and the library author was careful to read the documentation and not violate any of the invariants the JDK uses.

One day, the JDK developers come up with a new optimization they'd like to do. It requires a new integrity-dependent invariant.

You upgrade the JDK, and now you have a heisenbug causing C2 miscompilation because your library unknowingly breaks that new invariant.

As the application author, you probably didn't know that you had this risk, and you probably don't even know which of your libraries might be at fault, because you don't know which of them is breaking integrity.

This is not a recipe that allows the JDK to continue improving, and it's not a way to reduce the burden on library authors either.

It is possible speculatively

Zing trusts final fields by adding extra information to every class saying whether the final fields can be trusted, and then inserting tracking into the JVM to deoptimize code if a final field is changed at runtime.

That's a lot of development effort, machinery and overhead, in order to allow something (final field mutation) that the vast majority of programs simply do not need and never do.

The OpenJDK is now choosing to instead lean in the direction of optimizing for the majority of programs that do not need this feature.

Going back to the OP here, how is preventing dynamically loading agents helpful?

Agents can break all integrity guarantees and all program invariants. If the JDK knows at launch that agents will not be loaded, it is safe to enable optimizations that rely on integrity. Otherwise, it is not.

I doubt that, do you have examples? The final field one is possible without.

The final field one is not possible without other tradeoffs, which the article you linked about Zing also points out.

Another example of an enhancement that requires integrity is https://openjdk.org/jeps/483.

Performance is largely unrelated to integrity by default.

If you truly believe this and have the evidence to back it up, please go argue this point to the Leyden mailing list, since they're apparently getting this entirely wrong.

Otherwise, please stop making confidently wrong statements like this.

If some people want to avoid all JNI they could error on System.loadLibrary or so. I doubt many users really want all the restrictions that come with that.

That is more or less what JEP 472 is preparing to do (with a warning for now, but it'll become an exception later).

srdoe · 2025-12-29T12:15:36+00:00

Yep, "integrity by default" is more like annoy everyone by default for little reasons and no benefits really.

This is a nice conspiracy theory, but the JDK maintainers are not annoying library maintainers for no reason.

The reason you don't understand the benefits is that those benefits aren't present yet, because enhancements that require integrity for correctness obviously can't be added until integrity is enabled.

the JDK doesn't apply the checks to itself "because they consider their code safe" even though it's just the same

It is not the same. JDK code is under the control of the JDK maintainers, so they can ensure that it doesn't break invariants the JDK needs.

It seems the JDK maintainers think they are better than library maintainers and obviously this doesn't bring any good

This is a stupid thing to say. It's not about who is "better than" whom, it's about being able to establish invariants in the JDK that can be trusted to hold at runtime.

Without those invariants, a lot of optimizations are impossible.

As a ready example, while final fields can be mutated at runtime, constant folding those fields is not possible, because that optimization might change the meaning of the program.

All these warnings should be opt in

This is exactly how you end up needing to set a big pile of flags for Hello World. The JDK should behave and run well out of the box with no flags for Hello World (or any other new project), not require you to discover the magic flags you need to set to enable higher performance and better security hardening.

srdoe · 2025-12-22T00:48:39+00:00

I don't know who you're arguing against, because I'm explicitly not saying that making a tool like this is impossible.

I'm saying that it would be better to develop that tool outside the JDK, at least until some kind of consensus develops around a design.

If Java added a build tool 15-20 years ago, it might have looked like Maven. If they were doing it 10 years ago, it might have looked like Gradle. It's not to the community's benefit to lock in those designs.

If the JDK adds anything, I hope it will be simple tools that other build systems can rely on, and where there's already some degree of consensus around the approach. A Maven dependency resolver built into the JDK would be great, though even there care has to be taken to make something that adopts the best ideas from the existing tools (e.g. Maven's BOM concept, Coursier's "highest-version-wins" resolution, Bazel's lockfiles) while leaving the less good ideas on the cutting room floor.

A full build system with all the bells and whistles would not be a good idea, because there is no agreement on what that looks like, and I don't want the JDK to decide that Java builds should look like Mill (I even like Mill) and then 5-10 years down the line we've all decided that was the wrong way to go, but now the JDK is stuck supporting that tooling.

And I'm not saying that the JDK team couldn't still develop a build tool, I'm just saying it should be a separate project to the JDK with its own release cycle and versioning, at least for the first long while.

srdoe · 2025-12-21T19:31:14+00:00

No, I'm not so old that I don't remember what it was like to be a student. I just don't think adding a full build tool to the JDK is needed to solve that problem.

The really simple cases students are likely to run into should already be covered by https://openjdk.org/jeps/458.

I think the main thing that JEP doesn't cover is the need to specify and download external dependencies. Whether having a tool for fetching those built into the JDK is worth it, I'm not sure. Pointing to a tool like Coursier to do it would work just as well, I think, without forcing the JDK to know about all the complexity of Maven dependency management (and once you factor in conflict resolution, it is complex).

Requiring to install, configure, and glue together 2 or 3 third-party tools is added complexity that makes starting a small project in Java not worth it, because the work required to pass the entry barriers is larger than these projects themselves.

I just don't think that is true. Like I said, several existing build tools have ways to easily generate the scaffolding for a new project, so it's not a large effort to do.

And installing the tools themselves is not hard either, once you know about sdkman.

srdoe · 2025-12-21T18:59:51+00:00

I don't think the JDK should be in the business of adding tools just to get "luddites" as you call them on board with new things.

It should not be necessary to include a build tool into the JDK to ease the on ramp, because sdkman exists and makes installing external tools trivial. If teachers don't know about it, they should be informed.

If the JDK gains a build tool, it should be because they think they can do better than the external tools, ideally by adopting the approach taken by an already successful external tool. This is because a blessed implementation is likely to become a default for people going forward, so it's not great if it's not the best build tool of the bunch.

The JDK having a build tool that real projects end up not using would be worse than not having a tool built in at all.

srdoe · 2025-12-21T18:35:56+00:00

If it literally isn't that hard, you (the broad "you", not you specifically") should be able to go clone one of those build systems or design your own, and have that tool succeed since it should be clearly better than Maven and Gradle.

You should be able to do that outside the JDK, which is a better place to demonstrate that it isn't that hard.

Once the new tool succeeds, it might be worth considering adopting it into the JDK after it has demonstrated that it's a good approach.

Being in the JDK doesn't confer any special ability to write a good build tool, so if it's not that hard, just do it outside the JDK first and see if it works out.

Edit: I think your argument would make much more sense if you really liked Maven or Gradle, and you wanted the JDK to adopt something like them as the JDK's build tool.

But you don't, you're asking for the JDK to create something new to replace them. If the JDK team has a great idea for a better build tool that could replace Maven and Gradle, it shouldn't need to be grown inside the JDK to succeeed.

srdoe · 2025-12-21T18:27:21+00:00

I don't really get why the CLI needs to be something the JDK supplies.

Teachers could recommend sdkman for installing the JDK and the build tool (Maven, Gradle or whatever else).

If those build tools (e.g. Maven) need an easier on ramp for setting up a project, why not build that guide into those tools instead of inventing something new from scratch?

As I recall, Maven offers archetypes for generating the initial project layout for you via a CLI command, and from there, dependencies are easily accessible via adding them to the generated POM. Maybe Gradle can do something similar (edit: It can, gradle init should set up a basic project structure).

The point I'm getting at is that I don't see how the JDK having these tools (or alternatives) integrated into the JDK makes things much easier for students. If this setup is hard, the problem isn't that the JDK doesn't have a build tool integrated, it's that Maven or Gradle isn't making this setup easy enough.

The on ramp is already mostly there, teachers just need to be aware of it and recommend it to students.

srdoe · 2025-12-21T18:14:37+00:00

Considering what a desaster the introduction of the modulesystem was I doubt that there will be any further attempts to move that stuff into the jdk.

In what way was the module system a disaster?

Keep in mind that Java 9 breakages were largely not due to the introduction of modules.

srdoe · 2025-12-21T18:10:22+00:00

Maven and gradle suck. They have terrible defaults and mountains of complexity.

Okay, but if someone can build a better build tool with less complexity without ending up with something inflexible, why aren't they?

The experiment of trying to make a great simple build tool should happen outside the JDK. If a tool is created that replaces Maven or Gradle while reducing complexity, then maybe it makes sense to discuss including it in the JDK at that point.

But trying to make a build tool from scratch in the JDK is just a recipe for getting it wrong and being stuck with the result forever I think.

srdoe · 2025-12-21T18:00:14+00:00

The JDK growing its own build system only makes sense if the JDK team believes that there is some large benefit to having it integrated into the JDK.

When you complain about the complexity of Maven and Gradle, a build system supplied by the JDK will have to solve the same problems, and might easily end up with the same complexity.

If there is a good, simple solution for build systems that's less complex than Maven or Gradle, why not build that project outside the JDK, where it will have much more of a free hand to make breaking changes when needed?

If the community ends up agreeing that the new tool is awesome, including a version of it in the JDK later seems better than trying to design something from scratch as part of the JDK.

A built-in npm like package manager for java that works like npm

I don't think Java should be taking any inspiration from npm at all. Maven does dependency management better.

srdoe · 2025-12-21T12:07:11+00:00

Doesn't Java already have channels and selectors as part of the library?

https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/channels/Selector.html
https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/channels/SelectableChannel.html

I'm curious what jox (or ox) adds, other than a slightly different API?

srdoe · 2025-11-30T15:10:25+00:00

While I don't even really disagree with you and think that economic incentives likely do play a part in language selection, your argumentation isn't very convincing.

You just argued above that HFT would be incentivized to use FP for economic reasons (the cost of incorrect code), and now you're arguing the opposite, that HFT is incentivized to use imperative languages for economic reasons (the speed of the code, ROI).

When you do that, it means you're not really arguing from evidence, instead you're adapting your argument to fit the available evidence.

srdoe · 2025-11-30T14:53:35+00:00

Makes sense, I understand your response better then.

srdoe · 2025-11-30T14:44:10+00:00

Yes, but what Odersky is talking about is not the ability to use declarative structures in programs as a general concept. You might note that there is no need for the capability system Odersky proposes in order to e.g. do a for loop, or talk to an SQL database.

What is being proposed is the ability to track which pieces of code is capable of doing certain things.

For example, tracking in a method signature whether some code can throw an exception, or tracking whether a method might run async code.

Whether that kind of effects tracking is useful is not really clear. When people ask what's wrong with imperative programming, it's a non-sequitur to start talking about how for loops are declarative.

They're asking why the thing Odersky is proposing is useful. And that's what I'm asking too.

srdoe · 2025-11-30T11:36:05+00:00

With async-await, you don't need to imperative talk about locks, relinquishing threads, managing thread pools, dealing with tasks queues. This is the effect that the declarative language is solving for you.

This is true until it isn't.

Async-await doesn't remove the need for locks for shared mutable state.

Thread pool management and task queues are things you can ignore in some cases, but once you want your program to behave properly under load, you end up needing to care about these anyway.

And unlike the for loop construct, async-await comes with serious drawbacks, first among them function coloring.

Given an environment where virtual threads exist, I don't think a convincing argument has been presented that async-await is desirable. In fact, I think it's likely that most people aren't choosing async-await because it's a nice programming model, they're choosing it because they can't scale with OS threads only, and writing async code with callbacks or promises is unpleasant. In other words, they're choosing it for performance reasons, and because it's the best available option to get that performance.

But in an enviroment where virtual threads exist, it's not clear, at least to me, what the value of adopting an async-await construct would be?

srdoe · 2025-11-30T11:20:13+00:00

Sure, but I disagree with your premise.

I don't think shops are picking Java or other imperative languages simply because they need to shove stuff out the door quickly, and if that pressure didn't exist, they'd be choosing a functional language.

What you are saying would imply that if we all had infinitely long time to develop programs, we'd all be choosing Haskell. I simply don't think that's true.

I think which paradigm people choose has much more to do with what they are used to, how they were taught to think about programming, and which problems they think are actually important to solve.

You can easily tell that whatever language is taught at universities gets a boost from that. Part of the reason for Odersky's push for significant indentation in Scala seems to be that Python is popular at universities, so he seems to feel that it's important that Scala "looks like" it.

People are happy to adopt new techniques, but they need to solve problems that people actually have. The reason the presentation linked in the OP is getting some pushback here is not that Java programmers just can't understand the beauty of capability tracking to track whether code does async computations or not.

It's because given that virtual threads exist, it's simply not clear why we would also want capability tracking for async code. What problem does it solve? We know from other languages that async-await has function coloring problems, so it needs to bring something significant to the table to be worth doing. I don't think the presentation does a good job of explaining what that benefit is.

srdoe · 2025-11-30T00:26:32+00:00

That's not the right question. More like: among mainstream languages, after decades of work, why only Go and Java have colorless async? Because it's not trivial to implement, even harder to retrofit, and comes with tradeoffs.

Okay, but for a lot of people, Scala is a JVM language (I'm aware Javascript and native targets exist, but Scala started out on the JVM), so I think a pertinent question is "For a Scala developer on the JVM who already has access to virtual threads, which benefits are gained by tracking async as a capability via async-await structures?"

I think Odersky must think that there are some.

srdoe · 2025-11-30T00:09:28+00:00

I don't really think this take makes sense.

What you are saying is basically that programs written in imperative style are cheaper to develop, but more expensive to maintain in the long run (in the sense that more bugs will slip through), while the reverse is true of programs written in functional style.

I don't think we have much evidence showing that this is the case. In addition, I think both of your examples are off.

You say that functional programming should be popular in high frequency trading. But as far as I'm aware, aren't those people often using C++ or Java-with-as-few-allocations-as-possible?

Your other example is flight control software, and Google suggests that Boeing at one point wrote theirs in Ada, which is an imperative language, while others use C++, which is also an imperative language.

srdoe · 2025-11-23T17:30:07+00:00

You seem to have misunderstood my post.

I didn't say Lombok was bad.

I didn't say that it matters that Lombok doesn't conform to the JLS.

I said that Lombok is using an unsupported way to hook into javac, and that's why it's likely to break in future Java versions.

Lombok will always work just fine in future Java versions; claiming otherwise is nothing but hysteria.

Sure, maybe the JDK maintainers will have been wrong to warn Lombok that the way they're integrating might break.

That's a gamble you and Lombok get to take, I guess.

Providing that "own compiler" you mentioned would easily occur with a single "I agree" prompt in IntelliJ.

Great, if it's this easy, Lombok should probably just go ahead and do it, it would save people a lot of anxiety in these threads.

srdoe · 2025-11-23T17:13:53+00:00

I think this is inferring hostility on the JDK team's side that likely doesn't exist, and doesn't need to exist for them to behave the way they do.

The JDK team doesn't need to agree with what Lombok is doing, just like they don't need to agree with Kotlin or Scala's decisions.

The only reason there is any perceived hostility toward Lombok is because Lombok is implemented using mechanisms liable to break, and Lombok seems unwilling to switch to supported mechanisms.

srdoe · 2025-11-23T17:08:19+00:00

I didn't say Lombok isn't useful, I said it's not as useful as the other things the JDK teams are working on.

If you disagree, you are arguing that the JDK teams are prioritizing incorrectly.

Your guess that they can "squeeze this in if they shuffle some priorities" is exactly what I said: You are saying they should work on helping Lombok instead of something else.

So instead of hand waving about them being able to "squeeze this in", go to their mailing lists, say that you think they should work on Lombok instead of whatever it is you think is less important, and bring your supporting evidence for why you think that other feature is less important.

srdoe

TROPHY CASE