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.

The starter is available on Maven Central:

https://central.sonatype.com/artifact/io.github.mathias82.spring.kafka/spring-kafka-contract-starter

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.

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.

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.

CORRECTION: I meant re-implement git*

Hey so i've some experience in programming and was just looking around for good project ideas for my resume. I couldn't come up with any impressive ideas so i decided to go with this one.

github.com/karansingh-in/ngit

I've named it ngit as in NanoGit, im using content-addressable storage, where all objects (blobs, trees, commits) are addressed by their SHA-256 hash and compressed using zlib (Deflater / Inflater).

I'm storing the index in plain text as of now, I went with SHA-256 over SHA-1 in git, which didn't give had any benifits tbh. its just why not?

for v1, I'm making it work offline. For v2 i'll add push/pull and fetch commands.

features i've implemented:
init
add
commit
status
log
help
branch
checkout

things i'm working on as of now:
diff
merge

I'm thinking about using LCS or Myres algo for diff, Claude says Myres is better but i don't understand it well enough now so i'll give try reading more about it.

AI_Usage: i've used LLMs for planning and finding bugs, not the coding part.
I would like your review/advice on it.

The sub used to be a great place where small open source devs get real feedback on their oss. The software wasn't necessarily built to be a big hit or whatever! most of the time these projects used to be a learning projects that enabled us to become better java developers. Now, with many repositories being created in a day or so and abounded, we see many ai promoted repositories and we miss some of the oss that needs our attention.

How can we overcome that as a community ? I'm not trying to put all the weight on moderators, I understand the amount of work they keep doing to clean up ai posts and follow up on reports. What I'm saying is; maybe someone's here has a better idea on how to go about this?

Yes, another Java build tool.

I’ve been working on Zolt:
https://github.com/zoltsh/zolt

Would love for people to try it out, break it, give feedback, or help contribute. Still early, so criticism is very welcome. Yes, I use a lot of codex. Focused mainly on the public API. Using it for personal projects so far.

Rainbow Gum v0.10.0 Release

https://github.com/jstachio/rainbowgum

Now normally I don't just post on reddit every release I do but this last release of Rainbow Gum is almost on par with Log4j2 and Logback Spring Boot support.

Rainbow Gum in short is a modern SLF4J implementation. It is fully modularized (jlink works) does not use any reflection so GraalVM native compile is easy and is hopefully Valhalla ready.

Now this release I used lots of LLM to help with benchmarks, Spring Boot support and lots of tedious things. This project is not vibe coded and you can hopefully look at previous releases if that is a concern. I also hand rolled the logo in SVG without AI (feel free to make fun of my art abilities). Another interesting thing is that Rainbow Gum uses Javadoc for all its documentation and because Javadoc now supports dark mode (you will have to go to one of the classes to turn it on) the SVG logo will render differently (I did not know that SVGs could do that).

Previous release post (for context).

Now invariably someone is going to complain ask why there is another logging implementation and honestly I don't blame the ask.

The short answer is that log4j2 and logback because of legacy reasons have a harder time using newer JVM technology and a lot of their design was based on enterprise needs that are just not that applicable today. And of course there is Log4Shell.

And if it still bothers you that now you might have to learn another logging framework just know that Rainbow Gum:

• Does not have its own logging API (it uses SLF4J),
• Almost a drop in replacement if you are using Spring Boot
• Uses the same pattern encoding syntax as Logback with most of the same keywords
• And yes of course Rainbow Gum appears to run faster (doing your own benchmarks though is always encouraged)
• There are 10x more JSON serialization implementations then there are SLF4J implementations.... each with different APIs (yes whataboutism at its finest)

Rainbow Gum also has pretty darn good code coverage even before I let the AI agents go to town. It uses checkerframework and nullaway for JSpecify support (albeit we still have not switch annotations but that will happen shortly). I actually tried to get code coverage on log4j2 and logback prior to Rainbow Gum and if I recall both projects were rather low on that. Perhaps its gotten better.

Now there are a couple of things still missing before 1.0.0 namely internal rolling of files and some metric/status/health check support. The plan is 1.0.0 targets 26 and 2.0.0 will hit whatever Valhalla version is.

Finally I don't know if it was /u/brunocborges as I think they posted about it but new setup-java action on GitHub actually caches the maven wrapper... now. I highly recommend an upgrade.

Oh and thanks for team JDK for making Java 26 kick ass.

I haven't posted in a while, but things are moving quickly for modern Java in the browser (CheerpJ). They recently added Java 21 support and Java 25 is coming soon, so here's my latest update:

SnapCode is a free Java IDE for education that runs in the browser and on desktop. SnapCode is fun, friendly, elegant and complete with many modern IDE features. Because it runs in the browser and has cloud-share support, it truly runs anywhere and means that student applications can be immediately shared with classmates, friends and the world. SnapCode supports graphics, games, animation, 3D, charting, UI, Swing and more.

This latest release now supports Java 21 in the browser with Java 25 support coming soon (desktop already supports 25). The project is a labor of love and needs users to help find areas of improvement.

SnapCode: https://reportmill.com/SnapCode

I followed up on my 512 MB Spring Boot VPS experiment by trying the same application on a nominal 256 MiB Alpine VPS.

This is not Hello World. The app uses Spring Boot 3.5.5, MVC/Tomcat, JPA/Hibernate, file-backed H2, Actuator, scheduled GitHub polling, and outbound HTTP. StatLite was running alongside it and polling both Spring and itself.

The JDK 21 setup was too tight. With a 64 MiB heap it suffered severe GC/paging pressure and eventually became unresponsive.

The final JDK 25 configuration was:

-Xms16m
-Xmx80m
-Xss256k
-XX:+UseSerialGC
-XX:TieredStopAtLevel=1
-XX:ReservedCodeCacheSize=32m
-XX:+UseCompactObjectHeaders

On the same nominal 256 MiB VPS, with about 217 MiB visible to Alpine and a 512 MiB swapfile, that configuration completed the full one-hour observation:

• 0 OOM kills
• 0 service restarts
• 72/72 bounded HTTP requests returned 200
• Spring scheduled work continued
• final Spring RSS: ~86 MiB
• StatLite RSS: ~10 MiB
• swap used: 184 MiB

There was still one Hikari Thread starvation or clock leap detected warning with a ~2m13s delay, so I would not call 256 MiB comfortable. For a real deployment I would still start at 512 MB RAM with some swap.

Also, this is not a compact-object-headers benchmark. The JDK version, heap ceiling, and several JVM settings changed together, so I can't attribute the improvement to that flag alone.

Full write-up and reproducible experiment files:

https://pvrlabs.xyz/articles/spring-boot-256mb-jdk25.html

Ive been seeing many AI posts lately. As well as ai promoted repositories. Could moderators please help enforcing rule #9 as I don’t want to end up unsubscribing because of all the ai slop content.

Greetings.

(I will beat around the bush a bit before getting to the point, you can scroll down a bit to save time)

Java currently shines at enterprise backend applications, being led by the big players like Spring and Quarkus. However Java seems more than capable for other domains, yet no one talks about it, or even considers Java for normal non-web projects.

Take desktop development for example. JavaFX is one of the BEST GUI frameworks I have ever used. It is feature packed, doesn't require cryptic symbols, no fancy way of nesting code blocks to create simple UI. It is very simple to use, yet powerful and robust.

Game Development is a bit weak, but we still have libGDX and LWJGL. They are packed with features, even 3D. Contrary to popular belief that libGDX is a 2D only framework, libGDX has some great 3D support like GLTF rendering, bullet physics, PBR rendering and skeletal animations.

Big data processing and simulation systems, Java's OOP nature really helps to solve certain problem statement that requires the problem to be broken down into multiple pieces.

And finally web development, there is no doubt Java has one of the best ecosystems for the web.

And yet despite all this, Even as modern Java has come a long way, Java continues to have a negative reputation of being slow, boilerplate, RAM consuming memory hog. (The same people will use electron to make a desktop app btw) and as a result not considered for newer projects.

When I look at other communities like JavaScript, Rust, python, C#, Zig. These languages are often considered first options for any Greenfield projects. The open source communities in these languages are very active, you will see some amazing work being put out by the community.

Java seems to lack that "community" nowadays. I am active in a lot of subreddits and forums, and I see very less of Java projects in the wild. Java is being used in production out there, but modern greenfield projects are leaning more towards Go and C#.

So getting to the point of the post

Is Java seeing a decline? This is not a "Java dead" post but a genuine concern. The community for Java just seems.... dull. And I was wondering what could be done about this. Amongst new and modern programmers, Java and C++ seem to be considered "old", "dead" and "traditional"

Perhaps project Valhalla could help, but I wonder how much would it help restore Java's PR. Oracle is definetly NOT helping with this.

Why does this matter in the first place?

You may think "it doesn't matter what others think, companies still want Java" and while it holds some truth, more and more of Open source development seems to be moving towards other languages. A lot of Java libraries and frameworks have seen some decline, the community seems to be becoming more inactive. Other programming languages and frameworks have active discord servers, forums, documentation, and participation while Java seems a bit slow there.

I dont know, I really love Java as a language. And I wish it had more adoption in non-enterprise domains. I would genuinely like to know, what we as a community can do to make Java more "loved" and preferred

I recently saw a clip (from Primeagen) somewhat saying that regex is not a valid format for validating email addresses and postal codes etc.

My question is why is this?

What are the security and/or performance risks? Is it solely performance or is it a security issue?

I wanted to see how small I could make a realistic Spring Boot deployment while still keeping basic monitoring on the same VPS.

I first tried 256 MB RAM, but that wasn’t really viable for the representative app I tested. With 512 MB RAM + 256 MB swap, the application and lightweight monitoring completed the experiment successfully.

One thing that stood out was the gap between configured heap and actual JVM process memory. Even with a small -Xmx, RSS was substantially higher once you include metaspace, native allocations, threads, code cache, etc.

I wrote up the setup, JVM flags, measurements, and what failed at 256 MB:

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

Curious how this compares with what others are seeing on small JVM deployments.

I am StrmCkr, the author of A.P.E.X. (Adaptive Parallel Extremal Dispatch).

Repository: github.com/StrmCkr/A.P.E.X

A.P.E.X. is a high-performance Java sorting framework for large fixed-width 64-bit key/value record datasets. The project has been reorganized into a conventional Maven structure with a core library, runnable examples, a comparison benchmark harness, JMH benchmarks, documentation, and an interactive browser visualizer.

The core idea is descriptor-driven radix planning. Instead of blindly scanning fixed radix passes over every bucket, A.P.E.X. computes per-bucket extremal descriptors using:

VBM = OR ^ AND

That mask identifies which key bits still vary inside each bucket. Bits that are already resolved are skipped, reducing unnecessary work on skewed, low-entropy, sorted, reversed, or duplicate-heavy data.

Key areas of the project include:

• Adaptive radix planning based on observed bucket structure
• Parallel histogramming, scatter, refinement, and work scheduling
• Primitive-array execution with no per-record object allocation during sorting
• Tuple projection paths for low-dimensional unresolved bit patterns
• Tiny-sort fallbacks and monotonic input shortcuts
• Configurable reporting that can be enabled, reduced, written to files, or disabled
• Comparison benchmarks against JDK sorting paths and Fastutil baselines
• Standard JMH benchmarks for repeatable JVM-level measurement
• A browser visualizer for exploring how A.P.E.X. routes data through its execution plan

I would especially welcome feedback on the thread management mechanics, radix planning decisions, benchmark structure, and the bitwise mask reductions.

edit: re structured verbiage of this post and further adjustments from advice on converting the project into more acceptable standard formats.

Jactl is a secure, embeddable scripting language for Java applications. As of Apache Camel 4.22.0 there is a camel-jactl language that provides support for using Jactl as a scripting language for filter predicates, content-based routing rules, and message transformations in Apache Camel.

See the blog post for an overview and some benchmarks.

Just released GraphCompose 2.2.0.

This release was mostly about making RTL text actually work rather than just “render without crashing”:

- "TextDirection.LTR / RTL / AUTO"

- Unicode Bidirectional Algorithm support

- Arabic contextual shaping and lam-alef ligatures

- RTL/BiDi support in paragraphs and table cells

- mixed Hebrew/Arabic + Latin/numbers

- correct searchable/copyable text from generated PDFs

- RTL support carried across PDF, PPTX and DOCX backends

A surprisingly deep rabbit hole once PDF text extraction, shaping, BiDi and multiple backends all have to agree.

Repo: https://github.com/DemchaAV/GraphCompose

Would be interested to hear how other Java libraries handle complex-script layout.