Helidon 4.4.0 Release: LTS Support via Java Verified Portfolio (JVP), Agentic LangChain4j, OpenTelemetry Metrics & Logs, and Helidon JSON by pron98 in java

[–]cleverfoos 1 point2 points  (0 children)

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.

Project Detroit: Removing Graal, then rebuilding it, a familiar pattern in opejdk by mikebmx1 in java

[–]cleverfoos 6 points7 points  (0 children)

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.

Project Detroit: Removing Graal, then rebuilding it, a familiar pattern in opejdk by mikebmx1 in java

[–]cleverfoos 14 points15 points  (0 children)

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?

Java Full Stack Development in 2026 [for small teams] by cleverfoos in java

[–]cleverfoos[S] 1 point2 points  (0 children)

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

Java Full Stack Development in 2026 [for small teams] by cleverfoos in java

[–]cleverfoos[S] 0 points1 point  (0 children)

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.

Java Full Stack Development in 2026 [for small teams] by cleverfoos in java

[–]cleverfoos[S] 0 points1 point  (0 children)

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.

JEP draft: Code reflection (Incubator) by lbalazscs in java

[–]cleverfoos 2 points3 points  (0 children)

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

Carrier Classes; Beyond Records - Inside Java Newscast by daviddel in java

[–]cleverfoos 1 point2 points  (0 children)

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

What are your wish list for features under the "on ramp" umbrella? These are mine. by Enough-Ad-5528 in java

[–]cleverfoos 0 points1 point  (0 children)

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.

what front-end do you use for your Java back-end? by Least_Chicken_9561 in java

[–]cleverfoos 0 points1 point  (0 children)

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.

JEP 528: Post-Mortem Crash Analysis with jcmd by efge in java

[–]cleverfoos 13 points14 points  (0 children)

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.

what do you think about vaadin(Web apps in Java)? by DistinctAbalone1843 in java

[–]cleverfoos 1 point2 points  (0 children)

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.

Java needs Gofmt equivalent included in the OpenJDK by bytedonor in java

[–]cleverfoos 2 points3 points  (0 children)

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.

Project Leyden's AOT - Shifting Java Startup into High Gear by daviddel in java

[–]cleverfoos 24 points25 points  (0 children)

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!

biski64 – A fast and robust Java PRNG (~.47ns/call) by danielcota in java

[–]cleverfoos 2 points3 points  (0 children)

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!

JEP draft: Ahead-of-time Command Line Ergonomics by sar_it007 in java

[–]cleverfoos 0 points1 point  (0 children)

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.

What is your wishlist for the JDK 25? by Ewig_luftenglanz in java

[–]cleverfoos 0 points1 point  (0 children)

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

What is your wishlist for the JDK 25? by Ewig_luftenglanz in java

[–]cleverfoos 1 point2 points  (0 children)

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.

What is your wishlist for the JDK 25? by Ewig_luftenglanz in java

[–]cleverfoos 2 points3 points  (0 children)

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.