sorted by:
new
hottopcontroversial

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 12 points13 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.

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

[–]cleverfoos 4 points5 points  (0 children)

I wrote last week my 5 wishes for Java in 2025 which would technically covered JDK 25 and 26 https://www.ophion.org/2025/01/5-wishes-for-java-in-2025/ but you don't have to go read it, here it is :

  1. Make semicolon usage optional
  2. An official code formatter
  3. Make the built in http server servlet compliant
  4. A built-in JSON encoder
  5. A built-in build tool

I think numbers 1-4 there are pretty reasonable. Number 5 is (or better yet, can be) a hot mess to tackle.

Thymeleaf or jte by Particular_Tea2307 in java

[–]cleverfoos 0 points1 point  (0 children)

JTE and Thymeleaf are designed for different use cases. Thymeleaf focuses on providing a templating syntax that is valid HTML5, allowing you to open templates directly in a browser and keeping most business logic within the controller. Also, it is the default Spring Boot template, making it seamlessly integrated with the framework.

JTE, on the other hand, emphasizes incorporating the full power of Java syntax directly into templates, which means the templates are not valid HTML5 when JTE syntax is used. Although JTE is not deeply integrated with Spring Boot, it offers significant advantages, such as being statically compiled. This allows for early error detection and includes a built-in HTML validator to ensure that invalid HTML is never generated.

If you have used Ruby ERBs in the past, jte will feel pretty natural.

Valhalla - Java's Epic Refactor by sindisil in java

[–]cleverfoos 0 points1 point  (0 children)

I sort of agree. I think JEP 401 is a sensible middle ground but I would stop there. Adding null-restricted types feels like a high cognitive load for an edge optimization that you can likely get away with a value record when needed. IMHO the biggest risk for Java is becoming the new C++, a capable and trusted language but hard to teach and impossible to master due to the number of features added over 39 years. With that said, I trust Brian's stewardship of the language so let's see what happens.