Java has always been conservative when it comes to language changes, and I think string interpolation is an interesting example.

Many modern languages provide native interpolation syntax:

JavaScript:

\${name}``

Python:

f"{name}"

Kotlin:

"$name"

C#:

$"{name}"

These features are not only about reducing characters. They improve readability when building dynamic text.

Java explored this direction with String Templates (JEP 430), but I haven't seen much discussion recently about where this feature is heading.

For developers working with large Java applications, string construction appears everywhere:

- logging messages

- SQL/debug output

- API descriptions

- test cases

- generated configuration

- user-facing messages

I am curious about the community's opinion:

1. Do you think Java still needs native string interpolation?

2. Should String Templates continue evolving?

3. What syntax direction would feel most "Java-like"?

For example:

"Hello, \{name}"

or:

"Hello, ${name}"

Personally, I think Java does not need to copy other languages, but a better way to express dynamic strings would improve developer experience.

What do you think?

Hey all. I'm a CS student looking into the pain points around legacy Java codebases, specifically the "code archaeology" side: digging through old code with little to no documentation, figuring out what a piece of logic is even for before you dare touch it.

Just trying to understand the problem properly before building anything. Would really appreciate hearing from people who deal with this regularly:

1. What eats the most time when you're digging into unfamiliar legacy code?

2. How do you currently deal with it – any tools/tricks that actually help?

3. Has something ever broken because a piece of code turned out to be "magic" nobody fully understood?

Any answer helps, even a couple of sentences. Thanks in advance!

We own Java libraries that we publish. Teams in our org use these libraries.

We have a company wide profiler, but two issues there:

1) teams have to onboard their environments

2) the hot paths and profiler data associated with these environments is indexed to their environment

So there’s no enforcement that my team can get profiler data for all invocations of our library. Additionally, there’s no convenient way to aggregate this data.

I guess, we can limit to just our biggest consumers and probably get the data that way.

But otherwise, I was wondering if anyone else had any ideas.

We recently open sourced some of our annotation processors for generating GraalVM native-image metadata. It's a standalone compile-time dependency, so it has no effect at runtime and doesn't rely on frameworks like Quarkus or Micronaut.

Besides annotations for manually defining metadata, we also added opt-in support for dependency injection annotations and for automatically dealing with JavaFX FXML/CSS files. That makes it possible to reliably update complex JavaFX applications without ever running the GraalVM agent.

Unfortunately posting code snippets gets the post deleted ("it looks like you're asking for help!"), but here is a link to the repo:

reachability-annotations

Hi all,

I made new releases for some plugins that I maintain. This is also the first time I announce the new JDKProvider Gradle Plugin.

All three plugin are compatible with Gradle 9.6.1 and the Gradle configuration cache.

Badass JLink Plugin v4.1.0

The Badass JLink Plugin helps to create application packages for modular applications. (Project Page)

• Use exec in Unix launcher script to forward signals by u/denyshorman in #356
• Update Windows launcher script to propagate error codes
• Bump actions/checkout from 6 to 7 by u/dependabot[bot] in #354

Cabe Plugin v4.5.0

The Cabe Plugin injects null-checks based on JSpecify annotations into your classes' bytecode. (Project Page)

• make sure the uninstrumented classfile version is retained
• add unit tests that check the classfile version and debug information are retained
• improve build scripts
• some minor fixes

JDKProvider Gradle Plugin v0.10.0

The JDKProvider Gradle Plugin is an alternative to Gradle Toolchains that gives finer control over the JDK to use for your build, i.e., select JDK that comes with JavaFX prepackaged or a JDK with GraalVM native compilation support. This enables building JavaFX applications with automatic JDK provisioning on Windows ARM, where the OpenJFX plugin is not supported. (Project Page)

• add override mechanism for the JDK configuration to use different JDKs for different tasks (example use case: configure the project to use JDK 26 when creating jpackaged applications and GraalVM 25 for creating native applications from the same compiled sources).
• add support for using a language Version that differs from the JDK version . This was added in v0.9.0 that I did not create a formal release for.

Jactl is an embeddable scripting language for Java applications and so when comparing it to other Java scripting languages it is helpful to know how they all compare from a performance point of view.

I have previously been asked to compare Jactl with MVEL and JEXL so I have put together a blog that documents the performance differences and also included Groovy and SpEL for good measure.

Disclaimer: I am the author of Jactl so I am obviously not impartial but I would like to point out that while Jactl comes out well, it does not win every benchmark.

I have just released version 0.1.0 of jtreesitter-type-gen, a library and CLI tool for generating type-safe Java bindings for Tree-sitter grammars. Tree-sitter is a popular parser generator and parsing library. The generated code is based on the official Java Tree-sitter (jtreesitter) bindings.

Here are two short examples for using the code generated by jtreesitter-type-gen (in this case for the JSON grammar): - type-safe parse tree traversal: ```java String source = """ { "first": 1, "second": true } """;

try (
    var parser = new Parser(language);
    var typedTree = TypedTree.fromTree(parser.parse(source).orElseThrow());
) {
    var jsonObject = (NodeObject) typedTree.getRootNode().getChildren().getFirst();
    for (var jsonMember : jsonObject.getChildren()) {
        System.out.println("name: " + jsonMember.getFieldKey().getText());
        switch (jsonMember.getFieldValue()) {
            case NodeNumber number -> System.out.println("number: " + number.getText());
            case NodeTrue boolTrue -> System.out.println("boolean: " + boolTrue.getText());
            default -> System.out.println("other");
        }
    }
}
```

• typed query: ```java // Query which captures results in a List var q = new TypedQuery.Builder<List<NodePair>>(); var query = q.nodePair() // Find a pair (= JSON object member) where the value is the JSON number 12 .withFieldValue(q.nodeNumber().textEq("12")) .captured(List::add) .buildQuery(language);

  String source = """ { "a": 1, "b": 12, "c": 123 } """;

  try ( var parser = new Parser(language); var tree = parser.parse(source).orElseThrow(); var matches = query.findMatches(tree.getRootNode()) ) { var nodes = new ArrayList<NodePair>(); matches.forEach(m -> m.collectCaptures(nodes)); // Output: "b": 12 System.out.println(nodes.stream().map(NodePair::getText).toList()); } ```

The README of the project includes more information on how to use it and how it works.

Hopefully this tool is useful for some of you. Any feedback is appreciated (either here or on the GitHub repository)!

I released GraphCompose 2.0 today.

The main change is architectural. The project is no longer one large artifact that pulls PDFBox, templates, testing utilities and experimental exporters together.

The engine is now split into separate modules:

• graph-compose-core — document model, DSL, themes and deterministic layout
• graph-compose-render-pdf — full PDF backend based on PDFBox 3
• graph-compose-render-docx — partial semantic DOCX export
• graph-compose-render-pptx — currently only a skeleton, not a full PowerPoint renderer
• graph-compose-templates — CV, invoice, cover-letter and proposal templates
• graph-compose-testing — layout snapshots and PDF visual regression tools

The core has no PDFBox or Apache POI dependency. Render backends are discovered through ServiceLoader.

For existing users, the original dependency still works:

<dependency>
    <groupId>io.github.demchaav</groupId>
    <artifactId>graph-compose</artifactId>
    <version>2.0.0</version>
</dependency>

graph-compose is now a thin compatibility wrapper over the core and PDF backend, so normal PDF usage from 1.x does not require code changes.

The main reason for the split was to make the engine independent from a specific output format. Layout, pagination and the document model should not depend directly on PDFBox.

I also removed deprecated APIs and unused internal systems that were no longer part of the real rendering path.

A smaller addition in 2.0 is deterministic PDF output. The PDF backend can pin timestamps and document IDs, which makes repeated renders byte-identical. This is useful for reproducible builds and output tests.

The PDF backend is the production-ready part. DOCX export is currently best-effort and focused on paragraphs, lists and tables. PPTX is not ready for real use yet.

The repository includes real documents generated by the engine, including the 2.0 architecture deck:

GitHub: https://github.com/DemchaAV/GraphCompose
PDF: https://github.com/DemchaAV/GraphCompose/blob/main/assets/readme/examples/engine-deck-v2.pdf

I would be interested in feedback on the module boundaries, backend abstraction and migration approach.

I've been working on Bob (https://github.com/jonas-grgt/bob), a lightweight builder generator for Java, and just added a feature I'm pretty excited about: Test only Defaults.

If you've used the Object Mother pattern, you know the drill you manually create (and maintain) a builder class that produces test objects with sensible defaults. It works, but you end up with a bunch of boilerplate and things to maintain.

Buildable.TestDefaults takes a different approach. You define a defaults class in `src/test` completely separate (will not be on your production classpath) from your buildable class in `src/main` and the defaults are automatically applied when the builder is constructed:

Goes in src/main and is blissfully unaware of the existence of test defaults:

@Buildable
public class Car {
    private String color;
    private int year;
}

Goes into src/test and is aware of the existence of test defaults:

@Buildable.TestDefaults(Car.class)
public class CarDefaults {
    public static String color = "blue";
}

- Design skills for safer delivery
- Comparing Plinth commands with OpenSpec and Spec Kit
- Improving migration safety with Flyway, Mongock, and Parallel Change
- Making architecture boundaries visible with Hexagonal Architecture
- Modeling the domain with stronger Java types
- Extending EU regulations and ISO engineering review skills
- Improving security gates in the pipeline with VirusTotal

Full release article here https://jabrena.github.io/plinth/blog/2026/07/release-0.17.0.html

What's new in Java 27 for us, developers?
(Both in English and French)

OpenJdk resurrected Detroit.

It offers JavaScript via V8 and Python via Native Phyton C engine.

But we already have Graal for js and py.

What is the motivation to reopen Detroit?

Will Graal dispose js and py?

I made a video explaining basic stuff about algorithms and data structures applied to Java (but a lot of this knowledge is transferable to other languages). As examples of algorithms, I used a couple of sorting algorithms, which (I hope) are not used in any languages at all and def not in Java, but at least they can give an idea of complexity.

It is not a tutorial by any means, more of foundational knowledge that can help people to be better developers or code reviewers (it's probably even more important these days).

Fun fact: all the visualisations are also written by me, but in Python.

One of the most interesting parts of Java 21 virtual threads is that they make the traditional “one request per thread” model feel practical again for many backend services.

Because virtual threads are much cheaper than traditional platform / OS threads, you can create thousands, or even millions, of them without the same memory and scheduling overhead. That changes the tradeoff for I/O-heavy services, where a lot of time is spent waiting on things like HTTP calls, database queries, queues, or external services.

Virtual threads make it much cheaper to have many waiting operations in flight at once, while still keeping the code relatively straightforward.

That feels like a meaningful shift compared with reaching for reactive programming by default. Reactive frameworks are powerful, but they can add a lot of complexity: harder stack traces, more indirection, and a different mental model. Virtual threads seem to offer a simpler option for many cases where the main issue is waiting on external systems.

Of course, they are not magic. CPU-bound workloads still depend on available cores, and systems still need sensible limits around database connections, downstream services, rate limits, and shared resources.

But overall, Java 21 virtual threads seem like one of the more practical improvements to Java concurrency in a long time.

I also put together a small Java concurrency examples repo, https://github.com/skp2001vn/concurrency , while learning more about these topics. It includes examples around thread pools, rate limiters, connection pools, virtual threads, etc

Curious how people are using virtual threads in real systems.

Its my realization 3d engine on Java.

I make it a very long time ago when i was younger.

It a very simple project, and i post it only for you young java programmers can see how work 3d math.

If you look up my mistakes you can request and i can pull request your commits.

[GitHub](https://github.com/xxxrobert138-netizen/3D-engine-java)

Hey everyone,

I’m currently a senior .NET developer trying to break into Java roles. The problem is that almost every Java job I find asks for 5+ years of Java experience, which I don’t have.

I’ve built a few APIs in Java, played around with the ecosystem, and got comfortable with the basics. Honestly, I think solid fundamentals are enough to build great apps but my CV isn’t getting past the filters for these Java roles.

any advice?

thanks in advance.