The JEP talks about supporting textblock in a string template.

And a main targeted use case is SQL.

Well, SQL can be long, spanning dozens of lines. And sometimes you may wish to protect a block of subquery behind a flag (for example, you want to roll it out to specific experiments).

For example, if I have a SQL template that looks like:

"""  
SELECT
    foo,
    IF(
      complex_multiline_expression, NULL,
      another_complex_expression) AS bar
FROM
  ...
"""  

And if I need to put the IF expression behind a isBarEnabled() feature flag, naturally I'd just wrap that block with a ternary operator inside a pair of \{}. But how do I do this for the multi-line SQL text?

This wouldn't compile, right?

"""  
SELECT
    foo,
    \{
      isBarEnabled()
      ? """
        , IF(
        complex_multiline_expression, NULL,
        another_complex_expression) AS bar
        """
      : ""}
FROM
  ...
"""  

Or, will I be able to use triple single quotes?

I can only think of two options but I wish I won't have to use either:

1. Turn the complex multi-line sql into a super long single-line string.
2. Use the old + operator to concat multiple lines inside the \{}.

In the interests of increased acrimony in it usually congenial community. It doesn't sound like the templates redesign is going well. https://mail.openjdk.org/pipermail/amber-spec-experts/2024-December/004232.html

My impression when they pulled it out was that they saw improvements that could be made but this sounds more like it was too hard to use and they don't see how to make it better.

https://daniel.avery.io/writing/the-java-streams-parallel

I made this "expert-friendly" doc, to orient all who find themselves probing the Java Streams source code in despair. It culminates in the "Stream planner" - a little tool I made to simulate how (parallel) stream operations affect memory usage and execution paths.

Go forth, use (parallel) streams with confidence, and don't run out of memory.

Hi all, as the title says I'm just curious why we don't really see game engines in Java (by game engines I mean ones such as Unity or Unreal that anyone can run).

My current theory is that it might not be great at communicating with graphic cards drivers or other low level limitations.

I love using Java and Unity with C# is similar enough that I enjoy using it as well but I'm genuinely curious why we don't really have a Java based game engine.

We know that Java can run Minecraft which can be heavily modded and optimized to run on low end PC's and (I think) we can install a bundled jdk with a game and essentialy make it an executable.

Anyways long post about a shower thought I had. Curious what you all have to say about it.

Nice :-) I was looking for this ca. 2 years ago, now it's here.

See:

• Java 23 MessageFormat Javadoc
• JDK-8319344 MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter

Examples:

System.out.println(MessageFormat.format("LocalDateTime: {0,dtf_datetime}", LocalDateTime.now()));
// Jan 25, 2025, 9:12:48 PM
System.out.println(MessageFormat.format("LocalTime with style: {0,dtf_time,short}", LocalTime.now()));
// 9:12 PM
System.out.println(MessageFormat.format("LocalDate with custom format: {0,dtf_date,GGGG yyyy MMMM dd}", LocalDate.now()));
// Anno Domini 2025 January 25
System.out.println(MessageFormat.format("LocalDate with pre-defined formatter: {0,ISO_WEEK_DATE}", LocalDate.now()));
// 2025-W04-6

Almost a year ago we shared a post about our JSON masker library. The feedback from the community was incredibly helpful and we got a couple additional improvements requested, and we now also see quite a few downloads from Maven Central.

Since then we've implemented most of your suggestions which are now included in version 1.1.0, with the most notable changes being:

• Added a streaming API which can be useful for large JSON inputs
• Added over 1,000 additional tests, including full coverage of the JSONTestSuite
• We reduced memory footprint by more than 90% while keeping the same masking performance.
• Lowered the JDK requirement from 17 to 11 by using a multi-release JAR

Once again we'd love to hear your thoughts on the project.

Note: Although the library was designed to mask sensitive data in JSON, we've seen people using it for arbitrary rewrites of JSON values as the API allows virtually any operation on a JSON value that matches a key.

Hey there. I need to find a Java library to create OPC UA clients and the encryption stuff, like e.g. Eclipse Milo. Do you have some recommendations? Thanks in advance

Right now, I'm being trained in Spring. I can't shake the feeling that breaking backend web applications into all of these layers, using all this reflection, and using these giant toolboxes is not the right way to do things. Obviously, I'm going to do it this way, because thats what they want, but if it were up to me, I would just write procedural code with as few dependencies and as small dependencies as possible.

There's all of this code hidden away in dependencies, and mountains of documentation that must be read to understand the framework. Even the simplest changes have unforseen consequences, and you can't rely on static analysis to catch simple bugs because of all the reflection going on.

Sure, my way might be more verbose. There would be no dynamic-proxy that writes SQL queries for me, I would have to pass dependencies explicitly, I would have to write serialization/deserialization code by hand, I would have to compose each response explicitly (as opposed to using defaults, annotations, hidden config etc.).

But, it would be so much simpler. Stacktraces would be way shorter. There would be so much less terminology and consequently the codebase would be far more accessible to devs across the company. It'd be more performant because there's no reflection, and there'd be less chance for security vulnerabilities without all this code hidden away in dependencies and reflection going on.

Do any of you agree or disagree? Why/why not?

Title.

I’ve built a proof-of-concept tool that auto-parallelizes simple loops in compiled Java code—without touching the original source. It scans the bytecode, generates multi-threaded versions, and dynamically decides whether to run sequentially or in parallel based on loop size.

• Speedup: 2.8× (247 ms → 86 ms) on a 1B-iteration integer-summing loop.
• Key Points:
  • It works directly on compiled bytecode, so there is no need to change your source.
  • Automatically detects parallel-friendly patterns and proves they're thread-safe.
  • Dynamically switches between sequential & parallel execution based on loop size.
  • Current limitation: handles only simple numeric loops (plans for branching, exceptions, object references, etc. in the future).
  • Comparison to Streams/Fork-Join: Unlike manually using parallel streams or Fork/Join, this tool automatically transforms existing compiled code. This might help when source changes aren’t feasible, or you want a “drop-in” speedup.

It’s an early side project I built mostly for fun. If you’re interested in the implementation details (with code snippets), check out my blog post:
LINK: https://deviantabstraction.com/2025/01/17/a-proof-of-concept-of-a-jvm-autoparallelizer/

Feedback wanted: I’d love any input on handling more complex loops or other real-world scenarios. Thanks!

Edit (thanks to feedback)
JMH runs
Original
Benchmark Mode Cnt Score Error Units
SummerBenchmark.bigLoop avgt 5 245.986 ± 5.068 ms/op
SummerBenchmark.randomLoop avgt 5 384.023 ± 84.664 ms/op
SummerBenchmark.smallLoop avgt 5 ≈ 10⁻⁶ ms/op

Optimized
Benchmark Mode Cnt Score Error Units
SummerBenchmark.bigLoop avgt 5 38.963 ± 10.641 ms/op
SummerBenchmark.randomLoop avgt 5 56.230 ± 2.425 ms/op
SummerBenchmark.smallLoop avgt 5 ≈ 10⁻⁵ ms/op

Switch guards work for something like this:

switch (obj) { String s when s.isEmpty() -> { } }

But don’t seem to work when switching over an enum like:

switch (direction) { Up when x == 4 -> {} }

I also don’t see examples of this in the JEP, so it seems like this isn’t supported? If not, are there any plans for it to be supported?

Edit: my example was confusing some people so I changed the when clause to x == 4

Search bar not working, hyperlinks to classes and modules broken.

https://docs.oracle.com/en/java/javase/17/docs/api/index.html

Yesterday I made a post on r/javahelp about hanging reads when using pipes: https://www.reddit.com/r/javahelp/comments/1i6kdl8/nio_pipe_hangs_on_sourceread/

After some digging I found out that I've probably hit a known bug in the JDK (or rather in Windows, according to bug report): https://bugs.openjdk.org/browse/JDK-8279916

What I don't understand is what is the current status of this Bug. In the above link it says Unresolved, but according to the related SubTask ( https://bugs.openjdk.org/browse/JDK-8280233 ) the workaround should be present in JDK 17 since 17.0.5 - the Pipe implementation should simply use TCP socket instead of Unix socket. However when navigating classes of my Amazon Coretto 17.0.10 I can see that it definetely uses Unix socket.

Can someone help me verify:

1. Is it really that JDK/Windows bug or an issue with my code?
2. Was the JDK's code restored to using Unix pipe for some reason in version > 17.0.5?

Java 23 supporting Markdown for Javadoc is a much needed update that I'm ready to start using. This version of Markdown is based on Commonmark as implemented in Commonmark-java. It would be great if I can finally add math equations to Javadoc, especially if they are human readable in plain text. Looks like math is not native to Commonmark and equires a plug in.

Are there any plans to add support for Math? I've been forced to use raw HTML in the past that's horrible to read when viewing the source code as a text file. Support for Latex style syntax or something even more simple would be great. It seems like most math Markdown languages support entering math mode through something like this:

$ x^2 = a*b $

Where $ indicates that it should go into math mode. Right now you would need to do something like `x<sup>2<sup> = a*b`. I also just tried adding that code to a Javadoc file to see how it would render and sadly didn't work.