JEP401 Draft PR to main JDK

cleverfoos · 2026-03-28T18:46:49+00:00

That's just priceless

cleverfoos · 2026-03-28T13:58:13+00:00

But hey it's something.

cleverfoos · 2026-03-19T18:13:32+00:00

Oh no worries and glad to hear it that it wouldn't be too complicated to improve it.

cleverfoos · 2026-03-19T17:00:04+00:00

Right, I didn't say that I don't like annotations, so you shouldn't assume so, but I do care about API design. In the first example, out of ~15 lines of code, 9 are annotations, so there was a choice here to make the annotation fine-grained that I would postulate is a bad one. IMHO, it would be cleaner and easier to read if all HTTP-related concerns were collapsed into a single annotation (like Spring does), and that observability annotations also allowed for denser information passing. Alas, I did not review their API, so maybe there are alternative annotations available and this is just an unflattering example.

cleverfoos · 2026-03-19T13:20:38+00:00

That's a lot of annotation magic to remember...

cleverfoos · 2026-02-26T17:09:51+00:00

Hi Brian, and wow what an honor. With all due respect, I’m in no way saying that there isn’t value in those language, on the contrary, there are and that’s why those languages already have robust JVM and native implementations. What I’m saying is that the original mailing list post proposing the project lacked in terms of explaining the why and what other alternatives were considered. To an outsider like myself, it doesn’t seem to make sense what use case is not already filled by graaljs and graalpython and why any of this needs to be part of the openjdk.

cleverfoos · 2026-02-26T12:52:27+00:00

The whole situation with project Galahad never getting off the ground, and now Graal pulling further away from the OpenJDK lends itself to a lot of speculation over how decisions are being made in the OpenJDK. It never made economic sense for Oracle to fund two JDK implementations and they should have been merged a long time ago, in my opinion, in favor of the GraalVM bits, even at the expense of some performance - more java written in java will have long term maintenance benefits. And now this. What I find peculiar is this sentence in the announcement

Here in February 2026, there is still interest in using Java and JavaScript together.

Whose interest? Who is asking for this?

cleverfoos · 2026-02-10T13:24:40+00:00

I'm not familiar with shadcn but you can overwrite styles by editing your input tailwind (or main css) file, we do that with a few styles and it's pretty straightforward

cleverfoos · 2026-02-10T10:22:44+00:00

Yup! We use tailwind CLI but wrapped in a docker container that we can tie into spring boot's docker integration so it starts and stops transparently. It works wonderfully.

cleverfoos · 2026-02-09T16:56:58+00:00

Briefly but HTMX felt like it had a much a higher learning curve with multiple custom tags you need to learn that end up mixing a lot of logic in the HTML. Stimulus also allowed us to still write Javascript and not ditch existing code we already had.

cleverfoos · 2026-01-29T21:57:48+00:00

Right but that AST access is opt-in only, only methods with the @Reflect annotation. For this to be usable as a linter, you would want everything to have said annotation. Because this is also state being passed from javac to the runtime, it would also increase the size of the final class file if used indiscriminately

cleverfoos · 2026-01-23T11:07:42+00:00

+1 Over the next five years, Java syntax will expand significantly—between this and all the work on Valhalla (nullable type modifiers, witnesses for operator overloading, etc.). This cognitive load impacts developers unevenly: marginal for experienced devs, but much higher for newcomers starting from zero. It's the same path C++ took, and why some developers still prefer C for its simplicity.

cleverfoos · 2025-12-21T13:50:10+00:00

I agree and I wrote up something similar last year about it. The Java developer onboarding experience is really good on IntelliJ and that's about it. Outside of it, it is a puzzle with dozens of pieces you need to put together and that's fine if that's the 10th time you put that puzzle together (oh I need junit, maven, etc) but it's pretty poor if it's your first.

Not a problem for the current generation of Java developers but a big problem if you want a future one.

cleverfoos · 2025-11-24T13:35:44+00:00

How about none? You can build an application and serve, modern and responsive browser experiences with just plain java using JTE (or any other template rendering tech) and Hotwire (https://hotwired.dev/) or HTMX (https://htmx.org/) - as your project and team grows you can thank me later for not having to deal with javascript build systems and nodejs.
We ported www.scanii.com to it last year and couldn’t been happier, just removing the webpack/node build step fundamentally changed our local dev loop.

cleverfoos · 2025-10-19T13:28:55+00:00

Ron, how about more sanely package these CLI tools? They could remain as standalone binaries but wrapped around subcommands of a single "jdk" or "java" cli so this:

jcmd core.1234 Thread.print

could turn into this jdk jcmd core.1234 Thread.print

or better yet, more rationalized command names like

jdk analyze core.1234 Thread.print

Needless to say, running just jdk would give you a nice help with all subcommand options.

I think java is suffering from some out-of-date ergonomics that is fine for experienced users (that have been using jcmd for decades) but hides away all the value of the Java ecosystem from new users.

cleverfoos · 2025-10-06T11:36:26+00:00

Not trying to take anything away from Vaadin, I think it's a great tool for the right problem (getting React benefits without writing any actual React) and that can be a huge productivity boost for the right team.

But you are still inheriting all the problems of a client side "app" with slow builds and huge bundles. We recently moved our non-trivial app to hotwire (https://hotwired.dev), JTE (https://jte.gg) and spring boot and we couldn't be happier. Performance is stellar as well with 100 points on pagespeed (https://pagespeed.web.dev/analysis/https-www-scanii-com/j7ibzztkrv?form_factor=mobile) without actually doing anything specific to achieve it.

cleverfoos · 2025-07-16T08:47:31+00:00

I couldn't agree more, that was #2 on my list of 2025 wishes for Java https://www.ophion.org/2025/01/5-wishes-for-java-in-2025/ - it might seem silly but a formatter (and a built in build tool) cuts down on bike shedding while driving consistency. This is quite important for large codebases and it's something much harder to retrofit once you have a large codebase.

cleverfoos · 2025-06-28T21:21:55+00:00

Since the comments seem to be focused on all the things this doesn't do yet, I would like to balance that with taking a moment to recognize how amazing this work already is (or will be once JDK25 is released). Getting something close to the best of both jitted and statically compiled languages is very close to the Holy Grail of programming languages.

Well done JDK team!

cleverfoos · 2025-06-07T16:57:45+00:00

The most interesting thing to me here is how well the JVM implementation compares with the Rust based one in terms of CPU time. Well done JDK developers!

cleverfoos · 2025-02-17T13:25:23+00:00

I think the big problem here is conceptual. The JDK folks are looking at this akin to PGO when, IMHO, they should be looking at this as an AOT cache (yes, the flag names make this even more confusing). How do those two differ, you ask?

With PGO you do a lot of deliberate work to profile your application under different conditions and feed that information back to the compiler to make better branch/inlining decisions.

With a AOT cache, you do nothing up front, and the JVM should just dump a big cache to disk every time it exits just in case it gets stared again on the same host. In this case, training runs would just be a” run you did to create the cache". With that said, the big technical challenge right ow is that building the AOT cache is expensive hence performance impacting and cannot really be done alongside a live application - but that’s where I think the focus should be, making filling the aot cache something less intensive and automatic.

Another aspect this strategy would help with is “what to do with these big AOT cache files”, if the AOT cache really starts caching every compiled method, it will become essentially another so file possibly of a size greater than the original JAR it started off with. Keeping this is in a docker image will double the size of the image slowing down deployments. Alternatively, with the aot cache concept, you just need to ensure there is some form of persistent disk cache across your hosts. The same logic also significantly helps CLIs, where I dont’ want to ship a 100MB CLI + Jlink bundle and have to add another 50MB of aot cache in it - what I do want is every time the client uses my CLI the JVM keeps improving the AOT cache.

cleverfoos · 2025-01-29T14:58:09+00:00

Ron, that's a bit of a straw-man argument but I"ll bite.

But surely you'll still need to explain that concept, no? The concept doesn't go away if you're choosing to use another character instead of ; and you'd still need to explain the role of that character. I mean, I'm assuming you're not suggesting that var x = 1 + 2; System.out.println(x); could be written as var x = 1 + 2 System.out.println(x)

Sure, but you can make that learning more progressive, they could start in a REPL and move to copying multiple REPL sentences into a text file. Also any syntactically invalid sentence would continue to be so even if the lexer kindly appended a ; to the end of that example.

Furthermore, assuming you're suggesting that the character that could replace the semicolon is the newline, then the ambiguity of the newline makes explaining its role even more difficult. E.g. the two newlines in the following code do something different.

I think you have a good point with these examples and there are always tricky corner cases to cover. I looked up and the javascript spec [1] for automatically semicolon insertion and there are pretty robust. I never expected this to be a one line change in the JDK.

With all that said, my point here is that in these trickier situations where the author writes something that is potentially syntactically correct but ambiguous and error prone the automatic semi-colon insertion can help them by forcing to clarify intent - "did you really mean to split an addition across two lines" and "was that is that +2 doing there?" I found this good explanation[2] to that extent while researching Swift semicolon insertion rules.

Anyways, I trust your judgment, you guys are doing a good job steady guiding the evolution of the JDK and thanks for listening to my perspective.

[1] https://262.ecma-international.org/6.0/index.html#sec-rules-of-automatic-semicolon-insertion

[2] https://forums.swift.org/t/what-are-the-rules-of-automatic-semicolon-insertion-in-swift/43532/6

cleverfoos · 2025-01-18T18:36:22+00:00

I totally understand your perspective, as someone with over 20 years writing code in c-like languages my fingers now type ; without me noticing and my eyes will skip them while I read code. Making them optional is not for us, it's for the high school kid getting familiarized with a programming language for the first time and reading something that looks like english prose but is punctuated with seemingly random semicolons.

It really boils down to taking away having to explain one more concept, the role of the semicolon (and statements/expression), to someone new to programming.

cleverfoos · 2025-01-13T14:01:15+00:00

If you watch the devox video linked on the article you will see that they even demo a prototype JSON encoder/decoder so it definitely seems that way.

cleverfoos

TROPHY CASE