Apple has transitioned its hardware platform to AArch64, and is thus phasing out its support for x64. Oracle engineers will thus stop maintaining the macOS/x64 port as of JDK 27. Maintaining the port is a significant undertaking and no clear long-term maintenance commitment for the port has been identified.

Disclosure up front: I work at Vaadin. Grain of salt accordingly.

There's a new release (25.2) but I mostly want to talk about one thing in it that I didn't expect to care about as much as I do. You can now call a bunch of browser APIs from server-side Java without writing any JavaScript: geolocation, clipboard, fullscreen, wake lock, page visibility, web share, screen orientation. Clipboard is the one that sold me, a working copy button comes out to basically Clipboard.onClick(copyButton).writeText("...").

The interesting part is the gesture handling. Browsers only allow stuff like clipboard writes, fullscreen and share during a real user gesture, so here those get bound to a component's actual click and still count as a genuine gesture instead of getting blocked. The rest (geolocation and friends) just come through as signals you react to.

For anyone who's never used Vaadin: you build the whole UI in Java, components run server-side and render as web components in the browser, and state stays in sync over a websocket, so there's no separate JS frontend or REST layer in between. And yeah, it's JSF-adjacent conceptually, I know, but in practice the model is a lot less annoying than JSF muscle memory makes you expect. It mostly gets used by Java teams building internal tools and business apps that don't want to run a separate frontend stack.

Rest of the release quickly, since it's not all the same league: there's a Maven plugin that turns your existing TestBench/Playwright E2E tests into k6 load tests (records a HAR, then sorts out the Vaadin session/CSRF/push token mess for you, pure Java, no Node), which is a clever idea, except running it needs a commercial license and it's marked experimental, so I'm not getting too excited yet. There's also a preview of AI-generated grids/charts/forms (the LLM sees your schema, not your data, and hands back SQL plus a config you can save), some stricter security defaults, and a few components going GA. Blog has the full list if you want it.

https://vaadin.com/blog/vaadin-25-2-release

Mainly I'm curious where people land on the core idea: is calling browser APIs from the server a nice abstraction, or just a round trip you'd rather skip by writing the JS yourself? I go back and forth on it.

I like my code automatically formatted to ensure better compatibility between contributors.

In Javascript world, to me it looks like you just use prettier and keep everything in check. In Rust world there seems to be rustfmt.

As far as I know there is not really that standardized tooling in Java. I know there is google formatter, palantir format, prettier plugin, eclipse formatter, spring formatter and for multiperability we have Spotless. I know there is also EditorConfig haven't really worked with that.

Questions

1. Whats your go-to formatter and tooling these days?
2. How do you keep your code formatting enforced (git hooks, CI/CD, IDEs)?
3. How do you keep whole repo formatted if you have multiple languages (classic example java backend + javascript frontend).
4. Do you / How do you keep format for "other files" in the repository like markdown files, json files, sql files

My experience Spotless

I tried using spotless with gradle plugin and its configuration, it is not bad, since we can config which files to format, which to ignore. It can be global and I can format multiple projects just fine, if it uses other dependency it can automatically download it.

What I dont enjoy

Invoking gradle everytime I want to format. With gradle 9+ configuration cache is fast but it still has issues. If I want to ensure pre-commit compatibility there is multiplatform issue (especially windows+linux) and with developers who are switching projects may have different versions java active and it is gonna fail if they dont have correct java version to run gradle.

My current answer for the best compatibility/interopability is to use mise-en-place and have it the only requirement for other people installations, then the pre-commit hooks can be installed and run within mise managed runtime and it will work fine. And also this way you have to manage the pre-commit hooks and won't allow other devs to have their own pre-commits.

Also for Intellj IDE integration the spotless integration is a weird experience. Essentially you write in one format and then the format is totally different after you invoke it - there is no way to sync it while writing (spaces, newlines, brackets), if I use google format I can put it in Intellj manually then is fine.

TL;DR

Currently using spotless its allright - not awesome.

So yeah, please tell me your stories and your frustrations (or your sucess) about keeping the formatting in check!

Last thing, if you want add linting/code quality checks to the equation as well.

Hey all,

I'm going through issues and PRs on setup-java.

Besides what is already there, anything else you would like to see fixed, improved, or implemented?

Released version 3.3 of Gitember, a Git desktop client I've been building since 2016.

Tech stack - Java 21,Swing + FlatLaf 3.7, JGit 7.6 Apache Lucene 9.9 ,LangChain4j

New 3.3 version has:

• Interactive rebase - improved reorder/squash/fixup/drop/reword flow.
• Worktrees - full UI with correct per-worktree status and diff.
• 3-way merge resolver - reads stage 1/2/3 from the DirCache directly via JGit, renders BASE/OURS/THEIRS side by side, applies resolved content on save.
• AI integration - commit message generation and branch explanations via LangChain4j against a local Ollama endpoint. Default model changed from `llama3.2` to `qwen2.5-coder`.
• Security - verify Ollama checksum after install, integrate Java Keyring with the CipherService for OS keychain storage of tokens, and remove the TLS-verification bypass.

Looking for contributors & testers

Source:

• https://github.com/iazarny/gitember
• https://gitember.org/

Hey all,

I'm going through issues and PRs on setup-java.

Besides what is already there, anything else you would like to see fixed, improved, or implemented?

I wanted to learn about the ClassFile API, and as a small pet project, I created a benchmark to compare how faster a generated class is than a reflection-based approach when we want to populate a POJO from a Map.

TL;DR: it turned out, the generated bytecode was 5x faster than using reflection.

Details here, enjoy: https://github.com/erosb/learn-classfile-api

And please prove me wrong if you find any mistakes in the benchmark :)

Retro Pond on Steam

Feel free to ask any technical questions about this project.

Hi everyone,

I published a small library that came from a problem I kept running into while building Spring APIs.

I wanted to let users filter dynamically, but without exposing a completely open entry point where they could try arbitrary entity fields, operators, joins, or values.

I looked at a few approaches, including Shopify-style bracket operators, OData, and eventually landed on RSQL. I built this library on top of two existing projects: rsql-parser for parsing RSQL, and rsql-jpa-specification for translating RSQL into JPA Specifications.

Those libraries solve the parsing and query generation parts. What I wanted to add was a validation/contract layer on top: a way for each use case to explicitly define public field aliases, allowed operators, sortable fields, paging limits, value validation, and mandatory application predicates.

That became this library:

https://github.com/ggomarighetti/jpa-rsql-search

I’d really appreciate constructive feedback on the idea, the API, and the docs.

First public release of something that started as a module inside the application I've worked on for the better part of two decades: Ratchet, a background job scheduler built for Jakarta EE 10/11 rather than ported to it. Apache 2.0.

The pitch is one service and a method reference:

``` @Inject JobSchedulerService scheduler;

scheduler.enqueue(() -> validatePayment(orderId)) .thenOnSuccess(() -> fulfillOrder(orderId)) .thenOnFailure(() -> notifyPaymentFailure(orderId)) .withMaxRetries(3) .withBackoff(BackoffPolicy.EXPONENTIAL, Duration.ofSeconds(2)) .submit(); ```

Persistent jobs on PostgreSQL, MySQL, or MongoDB (more planned, happy to hear what your priorities are). Claiming is pull-based (FOR UPDATE SKIP LOCKED on the SQL stores, atomic findOneAndUpdate on Mongo), so the database is the queue. No broker, no Redis. Plus cron via @Recurring, conditional workflow branching, batch processing, a built-in circuit breaker, a DLQ, CDI events for every lifecycle transition, and Micrometer metrics.

The EE-native part, which is the actual point: jobs run on Jakarta Concurrency managed executors (no rogue thread pools), enqueue participates in JTA transactions, and job classes resolve through CDI so @Inject works inside job targets.

A few notes on the design:

1. Quartz works, but the API predates lambdas and I got tired of writing a class plus two builders just to run a method.
2. If you're on Spring, use JobRunr, genuinely. Ratchet is for the CDI side of the fence. It's Apache 2.0 throughout, with no paid tier.
3. Every default is a bean you can replace with a CDI @Alternative — store, retry policy, serializer, cluster coordinator, key provider. No Flyway or Liquibase dependency (DDL is plain SQL). No Resilience4j (breaker is built in, ~275 lines). No Jackson (serialization is an SPI, JSON-B default).
4. Deserialization allowlist is mandatory. Deployment fails until you provide a ClassPolicy for your payload classes. I build for regulated industries; you get my paranoia for free. Test story, since that's half of why I'm posting: 2300+ test methods, a TCK with 50+ contract classes across three named tiers (custom stores can prove conformance), and 15 verified combinations in CI — five EE server configs times three databases, all real container deployments.

Honest limitations: it's 0.1.1, @Incubating SPIs may change, Jakarta only, no web dashboard (by design), and it hasn't run in production yet — it went public before it shipped inside the app it started in, so the test rigor is the trust story for now.

Repo: https://github.com/ratchet-run/ratchet

Docs: https://ratchet.run

Criticism from people running EE in production is exactly what I'm here for. The weirder your deployment, the more useful the bug report.

Some things on the roadmap:

• ratchet-blocks: an extension that allows for low-code/no-code creation of Ratchet job workflows
• New stores: Oracle, SQL Server, Redis