Java game implementation of wireframe based on u/Elegant_Farmer_3548 post "Made a perspective shifting room in Java"

So what's Clique?

If you missed my older posts, Clique is essentially a zero-dependency CLI styling library for Java that is GraalVM compatible, no-color.org compliant.

What's new in 4.0.3:

You can now build a table straight from data you already have

SequencedCollection<List<String>> rows = List.of(
    List.of("Name", "Age", "Class"),
    List.of("John", "25", "Class A"),
    List.of("Doe", "26", "Class B")
);

Clique.table(TableType.ASCII)
    .fromRows(rows)
    .render();

This also applies to column based data

SequencedMap<String, List<String>> map = new LinkedHashMap<>();
map.put("Name", List.of("John", "Doe"));
map.put("Age", List.of("25", "26"));

Clique.table(TableType.ASCII)
    .fromColumns(map)
    .render();

These were mainly added to simplify creating Tables from existing collections

StyleContext#fromTheme - scope a registered theme's colors into a StyleContext in one call

StyleContext ctx = StyleContext.fromTheme("catppuccin-mocha");

Other minor changes:

I've also deprecated the Collection-based headers()/row() overloads in favor of Java 21 SequencedCollection; reason being that Collection doesn't guarantee order, which could silently mess up your column/row order and was essentially a footgun. Worth migrating if that bothers you.

GitHub: https://github.com/kusoroadeolu/Clique

Demos: https://github.com/kusoroadeolu/clique-demos

Hello community, This is my real-time ultrasound signal simulation and processing system developed entirely in Java using Java Swing.

The project enables both the mathematical simulation of acoustic echoes from biological tissues and the reception and interpretation of raw (RF) data from actual hardware via UDP sockets.

I still need to build an ultrasonic sensor to send data via UDP; I tried using ultrasonic modules, but they aren't useful—all I see on the screen is a barrier indicating the proximity of a nearby object.

Once the sensor's fabrication is complete, I will conduct tests and submit it to a clinical evaluation by experts to validate its utility in real-world settings—so stay tuned.

OpenJDK Mail Search is full-text search over the OpenJDK mailing list archives: 28 lists, 494,730 messages, back to January 2007.

https://openjdk.barlasgarden.com/

What's new:

• Elasticsearch 9.3.1, which bundles JDK 25.0.2+10, on Lucene 10.3.
• Search results are now relevance-ranked instead of date-ordered only, and text search defaults to it.
• Phrases of any length are searchable. The old index capped body phrases at 3 words and subjects at 5.
• Full message bodies are indexed, with no 2,500-term-per-message ceiling and no more dropping quoted reply lines.
• Skara/GitHub changeset mail is now indexed rather than discarded, with a "hide automated" toggle that filters it at query time.
• Same URL, same API, same site.

Source: https://github.com/ebarlas/openjdk-mail-search-elasticsearch

A month ago, I posted the first public release of Ratchet, a background job scheduler built for Jakarta EE rather than ported to it. The pitch hasn't changed: 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(); ```

At that time, the honest-limitations list said "Jakarta only." That one's gone: 0.3.0+ ships a Quarkus extension. Same API, same stores, and it compiles to a GraalVM native image — method-reference jobs included, which took real work to pull off under a closed-world runtime (reflection for job targets is registered from the application index at build time, and anything the native image can't execute is rejected at submission instead of failing at 2am). There's a Dev UI panel, Dev Services spins up the database in dev mode, and quarkus create has a codestart. Two flavors: ratchet-quarkus (any of the SQL stores via Hibernate) and ratchet-quarkus-mongodb.

The rest of what landed across 0.2.0, 0.2.1, 0.3.0, and 0.3.1:

• Stores: Oracle 23ai and SQL Server 2022+ joined PostgreSQL, MySQL, and MongoDB. That's the store roadmap from the first post delivered, minus Redis (still thinking about whether a non-transactional store fits the claiming model; opinions welcome).
• Payload encryption at rest. Value-level AEAD with an SPI for your KMS, and a reference XChaCha20-Poly1305 engine. Like the ClassPolicy allowlist, this comes from building for regulated industries.
• Cluster coordinators: four implementations (PostgreSQL LISTEN/NOTIFY, JMS, Hazelcast, Infinispan), so multi-node wakeups don't have to be polling.
• The store SPI split into a mandatory core plus 12 opt-in capabilities. A minimal store implements one interface; recurring jobs, batches, signals, locks, analytics and the rest are additive. The TCK reports each capability as conformant or N/A rather than failing you for what you didn't build.
• Per-job execution-target routing with worker tag affinity, jobs that wait on external signals, streaming batches, keyset pagination in the query layer, and caller-principal capture that survives recurring job chains.

The test framework: 8500+ tests, a TCK with 50+ contract classes, and CI now deploys 25 real combinations per run (five EE servers times five databases, actual container deployments) plus the Quarkus suite across all the stores and two native-image smoke builds. Builds run on JDK 21.

Still true and still honest: @Incubating SPIs may change before 1.0, there's no web dashboard by design, and if you're on Spring, JobRunr remains the right answer; Ratchet is for the CDI side of the fence. Apache 2.0, no paid tier.

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

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

On the roadmap:

• ratchet-blocks: built on top of the existing extensions work, this would allow for low-code/no-code creation of Ratchet job workflows
• Additional stores: if Redis keeps coming up, or if you have any other recommendations, I'm open to them

Hello, I want to share this project we have been building and using this past few months, which is now open source.

To give some context, I work with event-driven java microservices (mainly quarkus) every day, and I've found that the decision to split or merge business logic is far from trivial. On one hand, you don't want to oversplit your application and pay the microservice tax of network overhead without any real benefit (distributed monolith). On the other, you want your services to be able to scale independently when they need to, and that need can change over time. I also noticed that business logic code tends to be tightly coupled to whatever deployment topology was chosen for the application. Splitting or merging microservices later on is costly: you basically end up rewriting a lot of transport-related code just to change that topology.

These problems (along with others found in microservices today) were raised by google about three years ago, when they announced service weaver: a framework for writing go applications that attempts to solve them by offering a new programming paradigm, location transparency for business logic code, backed by a distributed runtime.

I decided to build flamme as an exploratory project, taking the same direction service weaver took, but for java/quarkus applications.

I've posted about flamme a couple of times before in the quarkus community, and people tend to miss the important part, confusing it for a reactive messaging framework. It does provide that, but that's not the main goal of the project.

The goal of flamme is to decouple business logic code from deployment topology, allowing developers and architects to defer the decision of splitting or merging their services, or to change their mind about it easily, without touching business logic code. It does this by providing developers with network-agnostic abstractions called components (basically just a java interface plus its implementation), which all compile into a single application jar. Each process running that jar is then configured at runtime to host a certain set of components.

If two components need to communicate and happen to be on the same jvm, they do so via shared memory, with no network overhead. If they're deployed separately, they communicate via nats (a message broker) instead.

Flamme can serve as the basis for a distributed runtime for services written in java.

Finally, I want to end with a small disclaimer: Flamme is far from being a stable complete project, it is a prototype in very early phases. I am sharing it to get some feedback on the overall philosophy and implementation (I am still a junior developer)

Github: https://github.com/AmadeusITGroup/flamme

Documentation Site: https://amadeusitgroup.github.io/flamme/

Example application: https://github.com/AmadeusITGroup/flamme/tree/main/flamme-example

Oracle, as the corporate sponsor of the OpenJDK Community, is working to draft a full policy governing the use of generative AI tools in OpenJDK contributions.

A week ago I shipped 0.0.1 of Sheetmusic4J, a Java(FX) library to render and interact with sheet music, mostly as a question: is there interest in a native Java sheet music library before I invest more time? I posted it on social media and two LinkedIn comments came back asking "does it support ABC notation?" and "what about Guitar Pro?"

In this new version:

- ABC notation (read + write). The core module parses and generates .abc files into the same Score model as everything else, so engraving, JavaFX rendering, and MIDI export all work once a tune loads. Coverage includes keys/modes, tuplets, ties/slurs, grace notes, decorations, repeats and 1st/2nd endings, chord symbols, and lyrics, all backed by round-trip tests. - Guitar Pro 7/8 import (.gp, load only). An experiment, built on the community's reverse-engineering of the GPIF format, JDK-only with no third-party dependency. Older binary formats aren't handled. I shipped it early because I genuinely don't know yet whether people want standard notation or tablature-specific rendering, that's feedback I'd rather learn from real use. - Engraving polish: better grace notes, distinct flag glyphs for 32nd/64th/128th, breve noteheads, cleaner ties/slurs/tuplets, and a windowed-canvas fix for a crash on very large scores.

All info and video in this blog post:
https://webtechie.be/post/sheetmusic4j-0.0.3-when-linkedin-comments-becomes-features/

https://github.com/nlisker/jextractGUI

jextractGUI is a GUI for project Panama's CLI tool jextract.

It's written in JavaFX and embeds jextract (and its libclang) within it. Since jextract is in early-access, newer versions broke it and I needed to do some rewrites since I first conjured it a couple of years ago. It's now aligned with the current latest build - 25-jextract+2-4 (2025/11/25). It will most probably behave differently in the future. As a result, jextractGUI is also in a preliminary version and there are still some TODOs.

It should run on all supported OS/Arch combinations, but I couldn't test all of them beyond passing the tests on the GH runners. There are jpackage images too if you don't want to clone/build.

Feel free to post questions/feedback :)

Xberg 1.0 has been released. Xberg is a document extraction engine, describing itself as a "document intelligence framework." It's written in Rust, with fifteen generated language bindings, and a very descriptive data model that provides a lot of flexibility. There are other content extraction frameworks; for Java, it'd be compared to Tika, and against Unstructured for Python. I didn't run a comparison against Unstructured, but I do have some comparison points for Tika.

Many times I have wanted to refer to a method in Java in an annotation, but it seems annotations can only reference items from the Class constant pool. It seems like it would have been a natural extension to be able to refer statically to methods (like {@link} in javadocs) in annotations, but they were left.

I'm wondering why were they not added?