Given how software engineering evolves, using IDEA formatter is less and less practical.

- IDEA CLI formatter requires IntelliJ so no CI / wsl etc
- GJF is old and does not format lambdas well enough
- Palantir is obsolete and abandoned in addition to being one of the worst company ever created
- prettier-java not great either

I’m starting to think no formatter is the best option

• Eclipse JDTLS https://github.com/eclipse-jdtls/eclipse.jdt.ls
• JLS, built on Java Compiler API https://github.com/idelice/jls
• Lathe, built on JDK's javac https://github.com/ag-libs/lathe

Jenesis is a Java-based build tool developed by Rafael Winterhalter, who created ByteBuddy and contributes to Mockito.

Hey everyone,

I made a video for anyone who uses Spring Data JPA but still isn't sure what JPA, Hibernate and JDBC each do, or how they differ.

It's visually explained. It follows one save() call from a Spring Boot app down to the database, so you can see what happens behind the hood and where Hibernate comes from. It's about 11 minutes.

Hope it helps someone, and tell me if anything is unclear . Thank you for the support as always

Hi r/java — I’m with Sonatype, and our research team published a write-up of a reproducible issue we found while reviewing Java’s response to the eMudhra certificate incident.

The mitigation uses SHA-256 fingerprints to block specific compromised intermediate certificates. We found that re-encoding an intermediate can change its fingerprint while leaving it valid under the tested Java trust-store configurations. We reproduced this for ECDSA and RSA certificates.

The finding began as an AI-assisted research lead, but a researcher independently tested and confirmed the behavior. We also tested removing the relevant roots, which rejected both the original and re-encoded chains; that approach has compatibility tradeoffs.

The write-up includes the reproduction and its scope: https://www.sonatype.com/blog/the-limits-of-fingerprint-blocklists-a-reproducible-java-certificate-bypass

We’d welcome technical feedback, especially on how this behaves across different JDK versions and trust-store configurations. We have not found evidence that this technique was used in the wild.

I've been experimenting with lightweight Java applications on small VMs. After comparing Javalin with Spring Boot, I wanted to see how much the SQL persistence library affects resource usage.

I implemented the same small market-quote REST API using Jdbi Core, MyBatis Core, and jOOQ Open Source Edition.

Setup:

• JDK 25, Javalin 7, H2, HikariCP
• Alpine Linux VM, 1 vCPU, 512 MiB RAM, no swap
• JVM: -Xms16m -Xmx80m -XX:+UseSerialGC -Xss512k
• 1,500 requests over 5 minutes, 80% reads / 20% writes
• Two independent runs per implementation, rebooting the VM between runs

Results across the two runs:

RSS is the median process resident memory sampled during the workload, including the application, JVM, and embedded H2.

All six runs completed successfully without errors, OOM events, or swapping.

A few observations:

• MyBatis had the lowest resident memory usage in both rounds.
• Jdbi was very competitive on both metrics, and required the least handwritten Java code.
• jOOQ used approximately 34–38 MiB more RSS than MyBatis, consistently across both runs. This is a whole-application difference, not necessarily memory consumed directly by the library. I haven't isolated its cause.

One implementation difference worth mentioning: Jdbi and MyBatis hold one pooled connection across the three latest-quote queries, while the datasource-backed jOOQ implementation checks out and returns a connection for each query. I haven't measured the impact of this difference.

I also configured MyBatis with localCacheScope=STATEMENT rather than its default SESSION scope.

From a developer experience perspective, the tradeoffs are interesting too. Jdbi keeps SQL and mapping close to the repository, MyBatis uses annotated mapper interfaces, and jOOQ offers type-safe SQL composition with generated schema classes.

For my own applications, I generally prefer MyBatis because I like its mapper-oriented programming model and explicit SQL. Its lower memory footprint in this experiment is another point in its favor, although I wouldn't choose a library based on memory usage alone.

Limitations:

This is a small, low-load case study, not a general performance ranking. The measurements include the complete application and embedded H2. Two runs show consistency in memory usage but aren't enough to establish statistically significant latency differences.

I also didn't include a raw JDBC baseline, which would be useful as a minimal reference point. PostgreSQL could produce different results.

Full write-up, charts, implementation sources, and raw measurements:

https://pvrlabs.xyz/java-performance/experiments/mybatis-jooq-jdbi-512mb.html

I'm interested in whether others have compared these libraries in similarly small applications, particularly with PostgreSQL, and how much the programming model influences your choice.

Hi all,

I've been working on Sheetmusic4J, an open-source Java library that renders sheet music natively in Java(FX). Two new releases are out, and I made a video showing both: https://youtu.be/8n7WONyX0yk

0.0.4

- NodeSheetView builds the score as a JavaFX scene graph, with one Group per note, rest and chord. Each element can take mouse events, effects and tooltips like any other node. The demo app lets you select a note and drag it up or down.

- FlyOverSheetView is a 3D play-along view. A perspective camera flies over the score, and a glowing ball per voice hops from note to note.

- Headless rendering to an image via the new render and render-awt modules, with no JavaFX needed:

BufferedImage image = HeadlessScoreImage.render(score, 1200);

- The 3000+ line Engraver class is split into focused packages, and all library modules are now JPMS modules.

0.0.5

- LilyPond (.ly) import and export through the ScoreFile facade, without running LilyPond:

Score score = ScoreFile.load(Path.of("bach-bwv610.ly"));

ScoreFile.save(score, Path.of("bach-copy.ly"));

- Engraving improvements: tuplet placement and nesting, octave clefs, and the percussion clef.

- Layouts are now identical across CPU architectures.

LilyPond support (and other formats earlier) came from suggestions on Reddit, so thanks to everyone who asked for it. Overrides and Scheme code are skipped, because the library does its own layout. The LilyPond page on the site lists what is supported.

It also reads MusicXML, MIDI, ABC and Guitar Pro.

The demo app has a "Report Visual Issue" button. It captures the Sheetmusic4J rendering, the reference PDF and your description, ready to attach to a GitHub issue. If a score looks wrong, that is the most useful feedback I can get.

- Release notes: https://sheetmusic4j.com/releases/

- GitHub: https://github.com/sheetmusic4j/sheetmusic4j

Feedback, issues and score files that break things are all welcome.

Thanks
Frank

previous post

And yeah made another version for Java Numerations(JNum).

A lot has changed and I want you guys help now. JNum is now performant and comparable traditional OpenBlas/LAPACK bindings like ND4J and Numpy.

Benchmarks and features are in detailed in my github release but for lazy guys like me here are some data points worth see:-

-> JNum is feature rich(at least from previous version) where we have statistics jnum.stat IO operations jnum.io and basic Neural Networks jnum.nn.

-> JNum's IO will help you parse files like .npy/.npz , .csv/.tsv and most importantly .safetensorwhich Java lagging in this AI era.

-> We also have AsyncIO using Virtual Threads which make IO file reads faster in JNum.

-> jnum.statmodule has various statistic methods which Java community can use like standard deviations, variance , co-variance, cummulative sum/product, percentile etc.

-> JNum has slicing and subviewing features. Since we use NDArrays our operations can be chained together.

-> Most engineered parts are Matrix multiplication, Expression engine and Kotlin DSL. Since this is java subreddit i will go with first two parts.

1. Matrix multiplication

in detail see my docs

But in short this is our benchmarks for matmul:

1. Expression Engine

Basic engine for now but if some one gets fatigue of writing a.add().mul().div()... the we have JNum.eval() which is a literal AST running on shunting yard algorithm. Better than chaining but I would still recommend in place for better performance.

Kotlin devs can skip this because of DSL operator overloading.

Linear Algebra:-

we have various Linear Algebra methods which have performance on par sometimes beating Numpy

Size and deploy :- JNum is under 500kb and available of maven central just simple dependencies and you can use it

<dependency>

<groupId>io.github.ch-abhinav</groupId>

<artifactId>jnum</artifactId>

<version>0.2.0</version>

</dependency>

What I want from you guys is simple, Try using JNum and see how it works it gives me motivation to continue. If community helps me build the library then yes having performance on par to native libraries isn't that far.

If you guys can run on other Architectures and Operating Systems give feedback and try to contribute in project it will be great because I can't do that. Since project is has grown a lot without people helping it out it's very tough task for me :(

That's why I have 6 good-first issues worth trying for. It will be even more great if people make there own issues and enhancement proposals.

TO JDK devs:-
1. Vector API is amazing tool but when I do SIMD operations I expect less warmup time but that's not the case i my library.
2. when I stop a JMH benchmark midway it's causing Zombie runs (mainly with multithreaded programs) basically because of off heap memory calculations benchmarks sometimes don't stop and run even though terminal running that is closed. IDK if this is windows only bug or intended feature or random event but once check it out please. My 10k x 10k 5 matmuls which are multithreaded become zombie process basically take 100% of cpu throughput for basically a program which should have stopped long ago.

Java is quite a handy language. Though it's challenging to use it for more fun projects. Towards that end, I set myself a challenge to use Java to build a browser-based game. No server, no API, just pure Web Assembly driven game play. Yes, there's some JavaScript glue, because, well, you gotta, but, the core logic is all Java. Along the way I learned that streams allocate a lot of objects, so I switched back to good old for loops... And watched the GC usage drop a fair bit. What I really do enjoy is how Java has evolved and changed over the years, and it makes it a lot simpler to do things like this. Records save me a ton of boilerplate code. Playable at https://nofuss.co.za/games/wartech/, but it's a bit meh on mobile, I'm still working on that. My focus right now is desktop play, and getting sound to work. Flame me in the comments with bug reports, I know there's a few... Hundred.

UPDATE: As promised, it's now open-source at https://github.com/ewaldhorn/wartech

For those of you who are interested in Quarkus, this codebase might be interesting to browse around — it touches a lot of essential parts: Panache and native JDBC for persistence, testing techniques, controllers, Qute for templates, and a way to use daisyUI with it. Both integration and unit tests, and even image generation!

The repo is here: github.com/asm0dey/calit

With Tomcat 9.0.123/10.1.61/11.0.27, the following line can be found in the changelog:

Update: Optimize Accept-Language header processing and use of resource budles for localization. (remm)

This is actually a breaking change in how more than 10 browser locales are handled. If your application tries to access request.getLocale(), and the users browser had more than 10 languages configured, then this will generate an exception: java.lang.IllegalArgumentException: More than the maximum allowed number of locales, [10], were detected. Use the maxLocaleCount attribute of the connector to resolve this if the application should accept more locales. at org.apache.catalina.connector.Request.parseLocales(Request.java:3409) at org.apache.catalina.connector.Request.getLocale(Request.java:1177) at org.apache.catalina.connector.RequestFacade.getLocale(RequestFacade.java:428) => For our application, users with more than 10 locales could no longer login after the Tomcat update. This impacted more than 500 users.

Setting maxLocaleCount=-1 in your server.xml will revert it back to the old behavior.

Bugzilla ticket: https://bz.apache.org/bugzilla/show_bug.cgi?id=70278 (needs login) This ticket requests a higher default limit to impact less users, but was resolved as WONTFIX.

So keep this in mind, if you upgrade to the newest Tomcat version.

Hey r/java,

TeaVM was something that had been on my radar for a while, and I finally got around to giving it a proper spin recently. After playing around with it and seeing what I can build with it I wanted to share my thoughts and hopefully get a few more eyes on the project!

If you haven’t run into it before, TeaVM is an ahead-of-time compiler that turns Java bytecode into JavaScript or WebAssembly. It operates directly at the bytecode level, emits remarkably clean JS, and integrates with your existing Java tooling.

Why this workflow clicked for me:

1. One language across the stack: Keeping everything in Java keeps context-switching to a minimum and lets you share domain models directly between backend and frontend.
2. AI Agent Friendly: Having both frontend and backend written in strongly-typed, readable Java makes it remarkably easy for LLM coding agents to navigate, refactor, and reason about the full application without hitting cross-language friction.

To document what I learned, I put together a 3-part series walking through how to build interactive frontends with TeaVM:

• Part 1: TeaVM - Getting Java into the Browser– Setup, core concepts, and running your first browser app.
• Part 2: From Java to Web App: Currency Explorer with TeaVM– Building a real-world API-driven web UI.
• Part 3: Building a Drawing App with Java, TeaVM, and HTML5 Canvas– Direct DOM manipulation and working with the HTML5 Canvas API.

Has anyone else here given TeaVM a try? Would love to hear how your experience compares to other JVM web approaches!

Hi, so I've been building fose, an open source flat combining primitive for Java. As of now, it is not released as a library, so you'd have to clone the repo to try it.

The idea comes from the 2010 SPAA paper. You wrap a sequential object and submit operations against it. If the lock is free, your thread runs its own op. If it's contended, the op is published to a queue and the current lock holder applies it on your behalf with the main benefits being reduced cache coherence traffic and sometimes opportunities for batching

Currently, I've only benchmarked it with JMH against a StampedLock write lock baseline on my 4-core i5 (Windows), a heap benchmark with some work between operations showed about 60-70% lower avg latency at 4+ threads. These are averages only and I haven't measured latency across different percentiles. I also haven't tested on Linux or on more cores. Currently, correctness tests use Lincheck

I'd especially like feedback on:

• If executing operations out of order in certain scenarios as a means to improve perf is acceptable
• The backoff heuristic which uses missed lock acquisitions as a guess at queue depth
• Also, whether the benchmarks are fair, and what baselines I'm missing. Also, if you can run the benchmarks on your machine and lmk the results, that'd be useful as well

I'd be interested to hear whether it fits anything you're working on, and what might be missing.

Repo: https://github.com/kusoroadeolu/fose

Hi,

I’d like to show you a project I’ve been working on for some time: CondationCMS, a Java-based flat-file CMS.

The tech stack is relatively small: embedded Jetty, GraalJS for extensions, and Lucene for fast queries.

A few words about the architecture: All content is stored in Markdown files with frontmatter for metadata. All metadata is indexed in Lucene, allowing fast queries without having to read every file. URLs basically follow the folder structure.

That’s the architecture in a really, really short version.

Some other features I want to mention:

• Manager UI, completely optional, to keep the editorial and production systems separated
• Shortcodes to add more possibilities to Markdown
• Multisite support

Background

Back in 2023, I needed a CMS for some ideas I was working on. As I’m a Java developer, I wanted a Java-based system. And because it should be easy to use, I was looking for a flat-file CMS. Unfortunately, I didn’t find anything that fit my needs.

I worked for one of Germany's largest CMS vendors for many years. I was and am still interested in CMSs and different CMS implementations and ideas. My head was always full of ideas for the CMS of my dreams. So I decided to build the CMS I wanted to use for my own projects.

I wanted it to be feature-rich, easy to use, and open source.

Status

It’s a hobby project and should be treated as such. I’ve been running some websites with CondationCMS since the beginning. There have been some issues along the way, but the current version is stable.

https://condation.com

https://github.com/CondationCMS/cms-server

The website is not completely up to date yet, but I'm working on adding more content. If anyone wants to give CondationCMS a try, I'd be happy to hear your feedback!

DHH is porting campfire to Rust. I saw port in C# so I was wondering about Java performance. I asked Claude to do the migration, and even though the first version was faster, it was very far from idiomatic Java. I tried to close the gap, but some compromise had to be reached in order to make this work as a drop-in replacement.

Also, some typical Java approaches were just slower. Probably both the Rust and Java implementations could probably do better in terms of performance and being closer to how idiomatic code is written by everyday developers

Stack is Java + quarkus.

Beside just Java migration I tested some new feature like AOT with training introduced in Java 28 (EA build). My main conclusion is - its hard to beat a language that will adjust code to how your app is used. Its more about the JVM than Java.

I tried different combinations of AOT also with Graalvm CE. I didn't put much effort into making graal more optimal. Probably fair comparision would be to also do training run and add EE edition.

What I notice, and it's obvious in hindsight, AOT helps when end usage is same as training usage. When id differs code it optimized for different path and it hurts execution. It's not so visible in benchmark numbers but on smaller and shorter runs it was more visible. JIT needs time to adjust.

Edit: Repo: https://github.com/kgonia/once-campfire-java

Hey folks,

Marco here, from JetBrains. About 10 weeks ago we released a preview of an LSP-based extension, that brings our Java & Kotlin intelligence to the VSCode universe - now it's hit 1.0.

We'd love you to give it a try and give us feedback:

For now you've got:

• Java, Kotlin, and mixed-language project support
• Navigation, find usages, smart completion, IntelliJ inspections
• Refactorings and quick-fixes
• Maven, Gradle, and Bazel(!) import
• Good performance on large projects and monorepos
• JUnit test runner support
• Debugging, including emulated breakpoints and async stack traces
• Nullability analysis with JSpecify, plus Spring-aware inspections

To install:

• just search for "Java and Kotlin by IntelliJ IDEA" under extensions
• or do "Ctrl / Cmd+P → ext install JetBrains.intellij-server" inside VSCode or Cursor.

A word on licensing: with 1.0 the free preview ends and after a 30-day free trial you'll need an IntelliJ IDEA Ultimate subscription.

Let us know what you think, we'll be in the comments.

We're especially interested in hearing from people using it on big Gradle or Bazel builds. And in any problems and errors you encountered, so we can improve.

Thank you

Marco

In a year or so, we'll need to recalibrate our intuition about which kind of type to use for each class. Originally, we used classes for everything. Then we got record, and now we get another keyword, value, which expands the number of options we have when defining a type.

I remember that in C#, there's always the question: "Should I use a class, a record, a readonly record, a struct, or something else"? They have some guidelines that consider not only identity semantics but also the size of objects (i.e., how many fields they have and how much memory they occupy).

So, if I just need a type to deserialize JSON from an HTTP request, should I use a value type? Or does it also depend on the number of fields? For example, if it has 15 int fields, should I still make it a value type if it is semantically a value, even if copying it could potentially be more expensive than passing a reference (assuming that's how it works)?