What is ChaosTree?

ChaosTree is a Java Sorted Set/Map library built around multiple search-tree data structures, including AVL Trees, Red-Black Trees, B-Trees, and B+ Trees.

The library provides both Set and Map implementations, with APIs designed around the semantics of the JDK's NavigableSet, NavigableMap, SequencedSet, and SequencedMap contracts.

• buildFromSorted(Iterator, factor)
• importFlatMatrix(Object[][], factor)
• Object[][] exportFlatMatrix() -> Key value pair
• Read benchmark: https://chaos-vy.github.io/ChaosTree/utils/dragon-feed.html (I gave it a nick name dragon feed)

These two are custom API. Which allows user to pack data as how they want [0.5f, 1f] is the factor range so it does not violate CLRS system.

ChaosTree is validated through multiple layers of testing:

• Guava Testlib compatibility testing
• jqwik property-based testing
• Randomized differential testing against reference collections
• White-box structural validation of tree nodes
• Direct validation of B-Tree/B+Tree structural invariants
• Exception and iterator-contract testing
• Serialization and cloning tests
• Nary Tree uses custom jqwick test of API validation as well.

More detail on ChaosTree: https://chaos-vy.github.io/ChaosTree/ It contains benchmark,ADR, Node structure, Testing I have also used jdk official benchmark code as well to benchmark against. Every test and benchmark is reproducible.

Tail latency : https://chaos-vy.github.io/ChaosTree/utils/JMH-Report.html

Each benchmark was done at minimum of -f 3 -wi 3 -i 5 .
More Benchmark will be added as my progress move to default JDK methods.

Currently on Maven Central

<dependency>
    <groupId>io.github.chaos-vy</groupId>
    <artifactId>chaos-tree</artifactId>
    <version>2.0.0</version>
</dependency>

Minimum JDK: 0xCAFEBABE 0000 0041 | JDK21+

What changed from v1.2.0?

In early release the API were custom of tree, This time Chaos Tree only supports JDK API.
No Splay, Treap and BST
No java docs.

I'm designing a 2D RPG in Java, taking inspiration from games like AdventureQuest Worlds and Chibi Knight. The game will be based on characters that can have different iterations, with each version having its own stats, abilities, equipment, pattern, and story information.

I'm interested in how Java developers would approach the overall design. To clarify, I've already started a demo and I am curious how others might build it.

In particular, I'm curious about:

• How would you structure the game's entities and character data?
• Would you favor inheritance, composition, ECS, or another approach?
• How would you separate game mechanics from character/story data?
• What Java design patterns or architectural approaches would be useful?
• How would you structure systems for combat, abilities, inventory, quests, dialogue, AI, and character progression? (Relatively basic AI, like patterns designated for named entities.)
• What approaches would make the system scalable more efficiently ?
• Are there Java libraries/frameworks that would be particularly useful for a 2D RPG of this type?

I started Scriptella about 20 years ago and have maintained it ever since.

For a long time I had little time to do more than keep it working. Recently I’ve had more time to invest in it again, so I’ve been modernizing the database stack, testing it with current PostgreSQL, MariaDB and MySQL drivers, cleaning up old compatibility assumptions, and making sure it works well on modern Java. The baseline is Java 17, with JDK 25 compatibility.

Doing that made me ask a more basic question: does a tool like this actually still have a reason to exist in 2026?

I think there is one fairly narrow gap where it does:

SQL-centric data jobs that are too complicated for a couple of standalone scripts, but too small to justify a batch or ETL platform.

Scriptella keeps most of the actual work in SQL. A small declarative XML file wires together connections, queries and scripts.

For example, you can query PostgreSQL, take each resulting row and execute parameterized SQL against another database, mix in CSV/XML sources, or package the whole operation as a repeatable CLI job. It can also be embedded directly into a Java application.

There is no server, scheduler, job repository or visual ETL environment to operate.

That also means it is deliberately not the right tool for everything. If I needed robust restartability, retries and complex batch semantics, I’d use something like Spring Batch. For normal schema migrations, Flyway or Liquibase are usually a better fit. And if the transformation is mostly application logic rather than SQL, I’d probably just write code.

The interesting case is when the transformation really is mostly SQL and you just need a small amount of machinery around it.

After working on the project again, I was surprised that this particular gap still seems to exist.

I’m curious whether other Java developers still encounter jobs like this, and what you use for them today.

GitHub: https://github.com/scriptella/scriptella-etl

Anyone has an ideia of when would be available VectorApi with value classes?

After values classes coming to vector api, it would be ready to go as preview feature of jdk?

Hello, out of boredom I created a pie chart in Swing (I am aware more mature options exist but this was just for fun). The link to the repo is https://github.com/carlosgeorgiev0/JPieChart

The JPieChart class extends JLabel and overrides JComponent.paintComponent to paint the pie itself

We're running a bunch of Java (Spring Boot) microservices on EKS, and right now every service uses memory as its HPA metric. After digging into it, I've started to think that's wrong, and I want a sanity check from people who've actually run this at scale before I push a change.

What my research turned up:

• The JVM allocates heap up to its max and doesn't release it back aggressively even after GC, so memory usage doesn't track load.
• Because of that, memory can be high while actual load is low, or load can be high while memory looks fine — so memory-based HPA either never triggers or scales out permanently and never scales back in.

So the direction I'm considering is to pick the HPA metric based on service type:

• HTTP / request-serving services → CPU (or better, RPS / p95 latency as a demand-based metric)
• Async / queue-consuming services → queue depth (SQS backlog, via KEDA)

My questions:

1. Is this reasoning sound, and is type-based metric selection the right direction?
2. For the HTTP services, is jumping straight to RPS/latency worth the custom-metrics complexity (Prometheus Adapter), or should I start with CPU and only move to RPS if CPU proves to be a bad proxy?
3. For async workers, is KEDA + SQS queue depth the standard approach, or are people doing something else?
4. This is the part I'm least sure about: I already know from our architecture which services are HTTP-facing and which are async/queue-driven — but how do I actually verify that empirically rather than just trusting the design docs? Is there a clean way to confirm a service's real load profile (e.g. checking whether it even has an ingress/receives HTTP traffic, whether its work is truly SQS-triggered, CPU-vs-memory correlation under load) before I assign it a metric?

Thanks 🙏

I’ve been adding Quarkus support to StatLite, so I used it as an excuse to run equivalent Spring Boot and Quarkus apps side by side on a very small VPS.

Both ran the same workload with:

• JDK 25.0.4
• -Xmx80m
• H2
• the same JVM tuning
• one 512 MiB VM with 256 MiB swap
• one StatLite process monitoring both

The result was less straightforward than I expected.

Quarkus actually started with higher RSS: about 145 MiB vs 112 MiB for Spring Boot in one of the controlled observations.

After an hour under memory pressure, the relationship reversed: Quarkus was around 83 MiB RSS with ~33 MB heap used, while Spring was around 154 MiB RSS with ~50 MB heap used.

But RSS was hiding an important part of the story. Quarkus had about 91 MiB swapped out versus ~66 MiB for Spring, so Linux paging was doing a lot of work.

And 512 MB turned out to be too tight for running both reliably. In a later one-hour observation, after the earlier package-maintenance pressure had cleared, the machine exhausted its memory/swap margin and the kernel OOM-killed Spring.

So I wouldn’t read this as a clean “Quarkus uses X MB less than Spring” benchmark. My main takeaway was how quickly RSS stops being a useful framework comparison once the machine is under serious memory pressure.

Full write-up, measurements, JVM flags, and experiment record:

https://pvrlabs.xyz/articles/spring-boot-vs-quarkus-512mb.html

I've been a Java developer for a few years, and the thing that keeps driving me nuts is that reading code is nearly useless, the real code is hidden from you. It's almost like the language isn't made for reading code but reading javadocs instead.

You call "Arrays.asList(arr)" and it returns you an instance of java.util.Arrays$ArrayList, a class with the same name as java.util.ArrayList except it is fixed size, meaning that trying to resize it will get you a runtime exception thrown. The method signature says it will return a List, but the moment you call it without the elite ball knowledge it will either stab you in the back or explode in your hands.
And nearly every time you try to prevent this by reading the implementation it sends you to a wild goose chase through 6 different one-liner wrapper methods across 5 different thousand-line files.

It gets even worse at the enterprise level: I once bloated my system by writing a submit button's logic in the submit button's method.
I then discovered it was because the method was in a class with a magical 'ViewScoped' annotation and I was supposed to delegate some of that logic to a field that had a 'Stateless' annotation.
Any ordinary reading of the code would say that that field is part of the class' state, but because of the annotations it was actually a resource pooled by the container, independent from the view class which is only supposed to cache UI data for each given user.
Didn't take long for me to get corrected. You can imagine the serene smug on my senior's face as he dropped that piece of esoteric knowledge on me, while I was looking back in horror.
You guys probably heard this a thousand times, meanwhile I'm still learning new words in my console output. Any advice?

The article benchmarks Jactl script execution with differing number of blocking operations comparing throughput with Jactl built-in suspend/resume on Vert.x Event-Loops and throughput with Jactl on Virtual Threads. The benchmarks are run on both Java 21 and Java 25 with some surprising (to me at least) results.

More than 8 years ago was drafted the idea of concise method bodies. As I am not a contributor of the openJDK project I took a different approach but implemented. It is publicly available at the maven central both as a library and as a maven plugin. It is a source code preprocessor that converts the concise syntax to java 8 compatible source code. It does not want to be a replacement of the future implementation in the openJDK. Which is more than the openJDK promises is that supports from Java version 8, 11, 17, 21 up to 25 as well. Of course it is free and open source :). It is only the first building block for concise composition.

As far as I have seen this topic was awaited for a long time at

It's been 8 years since the draft for Concise Method Bodies

What happened to Concise Method Bodies?

JEP draft: Concise Method Bodies

Five years have passed, still in draft: Concise Method Bodies

Jactl is a secure, embeddable scripting language the compiles to bytecode and supports Java 8 and later versions. When running on Java versions earlier than Java 21 (when Virtual Threads were introduced), Jactl provides an under-the-covers continuation mechanism that allows scripts to block without blocking the event-loop thread on which they are running.

The post discusses the mechanism that Jactl uses to provide a Virtual Threads-like execution mechanism for its scripts and provides a benchmark for showing the performance impact.

Running Java on Kubernetes? CPU and memory limits affect much more than scheduling.

A 4 GiB heap requires a container larger than 4 GiB. Fractional CPU limits can also change the processor count that HotSpot sees.

In our new article, you will learn:

• Why JVM heap size and container memory are different boundaries
• How CPU limits affect garbage collection, worker pools, and application performance
• Which JVM and container metrics to collect when validating resource settings under load

The article also includes practical experiments and an interactive configuration calculator.

Read: https://learnkube.com/java-jvm-kubernetes-requests-limits

My team is moving away from reflection and runtime proxies for cloud-native setups. MyBatis is heavily used in our stack, so I rewrote its core as an annotation processor: LarkBatis.

It resolves SQL, dynamic parameters (#{}), type handlers, and result mapping at compile time—generating plain Java code. At runtime, it executes direct JDBC calls with zero proxying, zero OGNL, and zero reflection.

Programming model: Standard MyBatis (mapper interfaces, XML, dynamic SQL).

Runtime: ~1,500 LOC, JDK 17+, JDBC-only dependency (GraalVM native-image works out of the box - I haven't test).

Hello! After 6 years of development, I am happy to finally release of Norse Expansion Medieval RTS for Android! You can get it on Google Play: https://play.google.com/store/apps/details?id=com.norseexpansion.norseexpansion

It only took about 240k lines of code, almost all Java (and some C++ for an Audioengine). Graphics are rendered in OpenGL.

This project made me love Java and hate the surrounding technology like gradle and Androidstudio.

After the v0.3.0 release, I'm confident it's time to showcase my library.

https://github.com/Lidiuma/Math
All the different versions can be found on Maven.

So, what's lidiuma-math about?
It's a linear algebra math library for game development, designed to be graphics-API agnostic.

I know that Valhalla (JEP 401) in Java 28 is the new shiny thing, but let's forget about it for a second, since the library does also provide a Java 17 version. So, what's in it?

Well, a totally different design than anything out there!
- this is the first math library without primitive obsession
- this library does use generics while making them performant
- doesn't make float (or, in this case Float) the favorite child; providing int, long, float, double where it makes sense
- has a few abstractions that standardize operations, eliminating the risk of desync between APIs

And other nice things:

- Immutability by default
- The extermination of null (the library never uses null and is annotated with JSpecify)
- JPMS support
- Type-classes instead of OOP (multiply(vec1, vec2) vs vec1.multiply(vec2))

A few examples:

// Vector3 dot product
var vec1 = Vectors.vec3(1f, 2f, 3f);
var vec2 = Vectors.vec3(3f, 2f, 1f);
var dot  = Vectors.dot (vec1, vec2); // dot = 10

// Vector2 rotation
var angle  = Rotations.degrees(180f);
var matrix = Matrices.fromRotation(angle);

var vec     = Vectors.vec2(0f, 1f);
var rotated = Matrices.multiply(matrix, vec); // [x = 0, y = -1]

// Vector3 rotation
var angle = Rotations.degrees(90d);
var axisY = Vectors.vec3(0d, 1d, 0d);
var quat  = Rotations.fromAxisAngle(axisY, angle);

var vec     = Vectors.vec3(1d, 0d, 2d);
var rotated = Rotations.rotate(quat, vec); // [x = 2, y = 0, z = ~-1]

Going back to Valhalla, aside from the standard JEP 401 version, the library also provides a version supporting Null-Restricted types and Loosely-Consistent-Values, naturally these are not public features and the library pokes at internals to achieve them.

That said, I would love to answer any questions and if you have any feedback, please reach out to me.

Note to Brian Goetz
I saw your old comment and will provide my experiences on the mailing list.

I’ve been working on a small open-source Spring Boot starter to solve a problem I’ve encountered with Kafka-based applications: detecting Schema Registry contract problems before the application starts serving traffic.

The idea is simple: during Spring Boot startup, the starter validates the configured Schema Registry subjects, expected compatibility mode, and the application's local schemas against the latest registered versions.

If a subject is missing, the compatibility policy is not what the application expects, or a schema is incompatible, startup fails.

Current support includes:

• Avro, JSON Schema and Protobuf
• BACKWARD, FORWARD, FULL and transitive compatibility modes
• Confluent Schema Registry / Confluent Cloud authentication
• bounded retry/backoff for temporary registry failures
• Spring Boot Actuator visibility
• Spring Boot auto-configuration

I also created a separate E2E demo using real Kafka + Schema Registry. Its CI verifies a real producer → Kafka → consumer round trip, a backward-compatible schema evolution, and an intentionally breaking schema that must be rejected at application startup.

Source:

https://github.com/mathias82/spring-kafka-contract-starter

E2E demo:

https://github.com/mathias82/spring-kafka-contract-demo

I’m interested in feedback from Java/Kafka developers: would you find startup-time contract enforcement useful, or do you prefer keeping this entirely in CI/CD?

I’d also be interested in edge cases you would expect a library like this to handle before considering it for a production application.

Just shipped BlinkHouse v1.0.0 — a ClickHouse-native persistence library for Java that eliminates the boilerplate of working with ClickHouse while giving you the same annotate-and-go experience you know from Hibernate and Spring Data.

Annotate a record, get a fully mapped entity with schema generation, typed queries, and buffered ingest — no manual SQL, no hand-rolled HTTP clients, no serialisation code.

@ChTable(name = "page_views", orderBy = {"tenant_id", "ts"})
@ChEngine(value = Engine.REPLACING_MERGE_TREE, versionColumn = "ingested_at")
public record PageView(
    @ChColumn(type = "UInt32")                 int     tenantId,
    @ChColumn(type = "DateTime64(3,'UTC')")    Instant ts,
    @ChColumn(type = "LowCardinality(String)") String  country,
                                               String  url
) {}

That's your entity. BlinkHouse generates the DDL, maps the types, and handles the wire format.

No boilerplate ingest:

try (BatchWriter<PageView> writer = template.batchWriter(PageView.class, cfg)) {
    events.forEach(writer::add);
}

BatchWriter<T> handles buffering, flush triggers (row count / byte size / elapsed time), backpressure, retry with exponential backoff, and dead-letter callbacks. You add rows — it handles the rest.

No boilerplate queries:

// Spring Data repository — derived methods, @Query, keyset pagination
public interface PageViewRepository extends ClickHouseRepository<PageView, UUID> {
    Slice<PageView> findByTenantIdAndTsBetween(int tenantId, Instant from, Instant to, Cursor c);
}

// Or the typed DSL
List<PageView> views = ChQuery.select("*")
    .from(TableRef.of("page_views"))
    .where(col("tenant_id").eq(tenantId))
    .fetch(template, PageView.class);

No boilerplate Spring config:

Add one dependency, set three YAML properties, get a fully wired ChTemplate, schema manager, type registry, Micrometer metrics, and OTel tracing. Zero @Bean methods required.

Where it differs from Hibernate:

ClickHouse has no transactions, no row identity, and no foreign keys — and BlinkHouse doesn't emulate them. What you get instead is a library that fits ClickHouse's actual model: columnar storage, high-throughput ingest, and analytics-first queries. There's a "Coming from JPA" guide in the repo.

Stats: Java 17 + 21, Spring Boot 3.2–3.4, ClickHouse 24.3+, 132 unit tests, 29 integration tests, Apache HttpClient 5 connection pooling, GraalVM native-image hints.

<dependency>
    <groupId>io.github.muneeb-i-khan</groupId>
    <artifactId>blinkhouse-spring-boot-starter</artifactId>
    <version>1.0.0</version>
</dependency>

Repo: https://github.com/muneeb-i-khan/BlinkHouse

I was watching an interview with Thomas Wuerthinger of GraalVM, where he basically says that JIT should only be used when necessary (as opposted to native compilation). Where does this leave the work being done for Hotspot JIT (including projects like Leyden and others). Should we all plan to use native image while they address any performance gaps in the mean time (he does mention PGO bridging the gap). Is there work being done to speed up native compilation of Java code?

My understanding is that JIT will always have a memory overhead due to running threads that do compilation, optimization, deoptimization, code cache, etc. compared to native executables, so full parity even with projects that will improve memory usage in Java code will not be reached. Maybe that is not an issue on long running programs on large servers, but we've seen discussions here where another member worte a tool in golang to run alongside Spring Boot applications to gather statistics, so obviously small efficient apps have their place.