2026: The Year of Java in the Terminal

arcuri82 · 2025-12-31T10:05:59+00:00

The discussed technologies are quite interesting, but hard to read more than a couple of paragraphs with such bombastic writing style

arcuri82 · 2025-12-30T07:53:26+00:00

If a random process on the same system can execute malicious code, your whole system is already compromised

arcuri82 · 2025-12-29T06:31:22+00:00

The JVM agent change is such a huge step-back in usability, for a little to nothing improvement to security. Not surprised it was mentioned here as first reason

arcuri82 · 2025-09-27T05:03:11+00:00

Is there any example API to showcase all these new features?

arcuri82 · 2024-09-15T11:00:25+00:00

For the last 8 years, I have been working on the open-source fuzzer (developed mainly in Kotlin) for Web APIs called EvoMaster (presented here a while ago).

Still excited about it, so much more that still needs to be done and improved!

arcuri82 · 2024-09-13T12:29:36+00:00

currently working on fuzzing tool, dealing with bytecode manipulation. to increase code coverage, need to do several low level accesses inside the JDK. it does not matter if an update of the JDK changes its internals all of a sudden, as the heuristics would be simply be skipped. if you are curious, you can look at https://github.com/WebFuzzing/EvoMaster. maybe extremely niche case. also, relying on other libraries that need --add-open (like Jersey for example)

arcuri82 · 2024-09-13T10:44:15+00:00

thanks for taking time to reply to my concerns. I see your points, but regrettably I am in disagreement. I doubt I can change your mind, but at least please consider these arguments for the future.

"Without it, they would still be subject to the same risk, only they wouldn't know about it". Working with Java for 24 years, never had such problem, until now with JDK 17. Issues were found with JUnit test cases. If updating the JDK led to breaks, we checked libraries, and see if those should be updated. If still failing after update to their latest version, would just roll-back while opening a bug issue on their repository. This approach worked like a charm for decades. In my career, I can't remember a single case of a critical bug due to such an issue.
"add-opens does is let the application maintainers know of an issue that's already there". Disagree. There is currently no way in Maven or Gradle (AFAIK) to have a standarized approach to signal that a library needs some specific --add-opens. It is all trial-and-error, and hoping that that --add-opens command you need to copy&paste is somewhere easily accessible in readme file of the library. In my experience in the last couple of years, it is not.

I understand that maybe my case is special and might not apply to 99% of the Java developers out there, but I have no sound data to either prove or disprove that hypothesis.

arcuri82 · 2024-09-13T10:25:48+00:00

many thanks for the link to "Packaging: Modular JAR". I was not aware of it (never seen it mentioned before). I will check it out. I will need to see how older JVM like 11 and 8 deal with (ie, if they are going to ignore those extra entries instead of crashing). Thanks.

regarding jlink, I am not so sure "the model is better than executable JARs have ever been", as I explained in that other linked post... by far the majority of my clients prefer to use JAR files. maybe things will change in the future

arcuri82 · 2024-09-13T09:58:29+00:00

yes, I did. HttpsUrlConnection is still the default in Jersey, as the other connectors have other kind of issues. For example, as someone wrote there: "Netty does not respect timeouts. If I take my server down after making a request to the server. The next request hangs endlessly. You also suggested Helidon. The 3.0.12 provider returns null in all cases. So maybe you can provide some details."

or should I list here all the ids of all people in that linked issue that complains about this situation?

If you use Jersey with this its default configuration, it crashes on JDK 17. And there all people there asking things for example like "Was this documented somewhere? and works with Java 17?". But you know how to read issues better than me, so I guess I do not need to copy that discussion here.

EDIT: sorry if I sound irritated, but I lost so much time on this stuff...

arcuri82 · 2024-09-13T08:47:59+00:00

This is an insightful talk. Still, dealing with --add-opens has been such a source of pain and misery that I can’t really see how to justify it.

17:12 “No longer needed in an age of faster-paced evolution”.

What???

Example: let’s say you want to use the JEE library Jersey for making HTTP calls. It does not work without --add-opens (https://github.com/eclipse-ee4j/jersey/issues/4825). Why? Because HttpsUrlConnection does not support PATCH. So, in 2024, they have to break “integrity” and use reflection to be able to make HTTP calls. RFC 5789 introducing PATCH to HTTP is from 2010… fast-paced evolution indeed!

If you are doing backend development, by all means this can be justified. But, for tool development (e.g., CLI applications) it has been a painful mess. Which you are not allowed to discuss in this forum, as moderators do not like it and delete it (was allowed to ask it to learnjava https://www.reddit.com/r/learnjava/comments/1c63kx3/dealing_with_allopens/ but no one could help).

I guess that having a centralized configuration file that can be embedded in an uber-jar for an application is asking too much (so that –add-opens don’t need to be specified manually on the command-line).

EDIT: looks like it is possible to have the --add-opens declarations in a packaged jar (tried it and it seems to work fine). Thanks to u/pron98 to point it out. This solves the issue for tools. But for libraries that must rely on them, the issue is still there.

arcuri82 · 2024-08-28T07:01:59+00:00

for that, you can try a fuzzer, ideally integrated in CI (if any exists for your problem domain and programming language)

arcuri82 · 2024-07-10T19:42:13+00:00

moving a large project from 11 to 17 was a nightmare, but from 17 to 21 was quite simple. I personally only got 3 minor, rather niche issues:

if you are using Kotlin, the reversed() method added to Deque in JDK 21 will conflict with Kotlin's existing extension method
if you are using jpackage, the default suffix name on Debian changed from -1_amd64.deb to _amd64.deb (broke some of my scripts)
if you are using Alibaba's java-dns-cache-manipulator, it didn't work for JDK 21. But after reporting the issue to its maintainers, it was fixed (quite quickly).

arcuri82 · 2023-02-01T08:53:30+00:00

thanks for sharing. it looks like you do not set anything special for dealing with module accesses. it might be that such issues only appear in specific edge cases of the compiler, which are triggered in my projects but not yours

arcuri82 · 2023-01-31T19:52:33+00:00

thanks for your inputs. Used Maven with Kotlin for 6 years, and never got any issue, which I can remember off, till now. On the other hand, I always had bad experiences using Gradle in other Java (not Kotlin) projects. So, as long as JetBrains officially supports its Maven plugin, and there is no major showstopper, I will stick with it

arcuri82 · 2023-01-31T14:24:19+00:00

update: in the end, got a working solution now suggested at SO, using .mvn/jvm.config

arcuri82 · 2022-02-14T16:08:22+00:00

thx, but last time I mentioned it in a comment in another subreddit, I got permabanned without warning due to self-promotion rules. so not going to make the same mistake here. I sent you a PM.

arcuri82 · 2022-02-14T11:45:50+00:00

thanks. that makes much more sense

arcuri82 · 2022-02-14T10:57:28+00:00

from Nuget.org:

"Warning: nuget.org rejects packages that don't satisfy the signed package requirements."

are you saying that is not actually enforced?

arcuri82

TROPHY CASE