We just posted an update regarding Maven Central publishing limits over on r/mavencentral.

Please check out the full details and share your feedback there.

Read the full update on r/mavencentral

Spent a nice chunk of tokens over the weekend to make Hardwood's (a new Java library and CLI tool for Apache Parquet) TUI runnable in a browser. There are still some limitations (only single-threaded; no native code, hence only support for Snappy- and GZIP-compressed files), but I'm kinda mind-blown that this actually works. Everything runs locally, i.e. the files never leave your browser. The translation to WASM is done via GraalVM's Web Image.

like public sealed class String permits Latin1String, Utf16String instead of the private final byte coder; field

From its humble beginnings as a project code-named "Oak" at Sun Microsystems to becoming a global standard for enterprise software and billions of devices, Java's journey is one of radical innovation, strategic pivots, and enduring community strength.

Today I accidentally became the maintainer of software that was already almost three decades old: reviving a 1990s Java utility to keep the last PAD submitter alive in 2026.

I was looking for a way to submit my AI app RiverScript to old desktop software directories and ended up digging through the long-forgotten world of PAD files.

There was one problem.

The only batch submission tool I could find was a Java application that first appeared in the late 1990s. The last release was in 2017.

It was written by Roedy Green of Canadian Mind Products — a software developer who passed away in 2023. He spent decades writing and freely distributing Java utilities, and maintaining the widely-read Java Glossary. Roedy Green also wrote How To Write Unmaintainable Code — a famous satirical guide about writing code nobody can maintain. So, Roedy, today the code you wrote almost three decades ago was maintained.

The tool still did exactly what it was supposed to do. Thank you.

It just had absolutely no idea the modern web existed.

It happily produced URLs like http://https://riverscript.com instead of https://riverscript.com, disabled SNI globally (which was probably a perfectly reasonable workaround at some point), and couldn't cope with the fact that almost every website now redirects HTTP to HTTPS.

So I dug through the legacy Java code, fixed the compatibility issues, and got it working again.

I used it to submit my app to several software directories, then published the revived version on GitHub so anyone who still needs it can use it too.

Maybe nobody will ever need it again. Maybe someone will.

Either way, I'm happy this old thing works again.

So today, the code of the man who wrote "How To Write Unmaintainable Code" is still being maintained even after he was gone.

P.S. The public repository for Mini PAD Submitter 26.3 Revived — 2026 Community Fix is available and open to everyone.

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.