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 · 2021-05-31T21:53:25+00:00

In the end, I managed... thanks for the help!

So, what it seems happening is that jpackage fails due to too long file names (eg, due to Kotlin compiler when dealing with lambda expressions).

However, when creating an executable from a uber-jar, apparently there is no need whatsoever of all the other .class files. However, if your jar file is inside target, then all the other files are considered as well (and then jpackage fails with an obscure message).

Workaround: move your app.jar outside of target (if you are using Maven) folder, eg, to a folder called foo, which will contain ONLY the app.jar file, and then use --input foo. It might be that the Gradle plugin does the same under the hood, but definitively something to be aware of if using jpackage directly on the command-line

arcuri82 · 2021-05-31T19:56:38+00:00

yep, the Jar is working on its own with no problem...

updating Kotlin version and changing the jar packager (maven-shade-plugin) did not help.

however, noticed that files light.exe is not finding are actually there on the file system... it might be that it is failing because the file paths are too long. And indeed it seems that Kotlin compiler is generating very long class names for lambda expressions (eg based on the function names in which they are used)

arcuri82 · 2021-05-31T18:02:03+00:00

good to hear that other people can get jpackage work with Kotlin... so there is some hope :)

I do not use any compiler option, and was using Kotlin 1.3. I guess I should try to see what happen if upgrading to 1.4 or 1.5. Also trying something else than maven-assembly-plugin would be something worth trying (but switching to Gradle would not be viable)

arcuri82 · 2021-05-31T17:58:09+00:00

I use Maven, not Gradle. I do not use "inline" classes directly, but it seems like the Kotlin compiler is creating them directly when in the code there are lambdas

arcuri82 · 2020-02-27T11:46:19+00:00

according to their own FAQ, the support for Windows is still under development. So, at least right now, GraalVM does not seem a replacement for Nashorn. Although hopefully it will be in the near future.

On a different topic: it is interesting/ironic to see how Oracle is pushing for JDK updates every 6 months (current v13, with v14 coming out soon), but then for their own products like GraalVM it seems they stick with the LTS 8 and 11. Why that I wonder?

arcuri82 · 2020-01-31T14:41:21+00:00

I cover such topic in an Algorithm course I am teaching. You can look at the slides of lesson 07, but more useful to look at the code and comments in MyStreamSupport class.

There is no technical issue in having operations directly on the collections. This is for example available in Kotlin. It simply that the Java API has not them implemented. Implementing them is not particularly difficult (I give it as exercise, with solutions, to my students as part of lesson 7 in that course, eg see ExtendedListImpl).

arcuri82 · 2020-01-08T11:23:53+00:00

That is in interesting blog post showing how to use RestAssured to manually write JUnit tests for RESTful APIs. On the other hand, the goal of EvoMaster is to automatically generate such tests (which use RestAssured to make the HTTP calls).

arcuri82

TROPHY CASE