# jvm Published articles for jvm. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Local and distributed cache coherence: stale data caused by missed invalidation messages DevFeed: [Local and distributed cache coherence: stale data caused by missed invalidation messages]() Original publisher: [Read original article]() Author: hello@ankit-rana.com Published: 2026-09-17T00:00:00Z Content type: opinion Language: en Sources: [Ankit Rana | Mechanical Sympathy]() Topics: [Caching](), [Redis](), [data](), [Network]() Tags: [cache](), [cache-coherence](), [caching](), [consistency](), [data](), [distributed-cache](), [distributed-systems](), [jvm](), [network](), [redis](), [ttl]() ### AI overview The article explains that adding an in-process cache in front of a distributed cache can improve latency but creates independently stale copies across service instances. It focuses on Redis pub/sub invalidation, which provides no persistence, acknowledgement, retry, or replay, allowing instances to miss invalidation messages and serve stale data until their TTL expires. ### Source excerpt An in-process cache in front of a distributed cache removes a network hop and adds one independent copy of the data per instance, each of which can be stale on its own schedule. Invalidation is normally broadcast over pub/sub, which is fire and forget, so any instance that is restarting, garbage collecting or briefly disconnected simply misses the message and serves stale data until its TTL expires. That TTL is not a performance setting, it is the maximum duration of incorrectness. ## Who am I ? DevFeed: [Who am I ?]() Original publisher: [Read original article]() Author: brice.dutheil@gmail.com (Brice Dutheil) Published: 2026-09-15T04:32:32.192351Z Content type: article Language: fr Sources: [The Coffee Workshop]() Topics: [Java](), [Kubernetes](), [Open Source](), [backends]() Tags: [java](), [jvm](), [kubernetes](), [open-source]() ### AI overview The author describes himself as primarily a Java and JVM developer, with experience using Kubernetes and contributing to open-source projects. He previously worked on Mockito, has spent ten years working on backends across various sectors, and currently works for BlaBlaCar. ### Source excerpt English 🇬🇧/🇺🇸 I'm mostly a Java / JVM guy. Now I'm also a Kubernetes user in surface, so I now a few system tricks. ## Generating Java bytecode: Write yourself a compiler, Part V DevFeed: [Generating Java bytecode: Write yourself a compiler, Part V]() Original publisher: [Read original article]() Published: 2026-09-14T22:00:00Z Content type: tutorial Language: en Sources: [Tomasz Nurkiewicz around Java and concurrency]() Topics: [Java](), [Compiler](), [Programming]() Tags: [bytecode](), [compiler](), [file](), [go](), [interpreter](), [java](), [jvm](), [virtual-machine](), [writing-compiler]() ### AI overview This tutorial explains how to extend a toy-language compiler to emit valid JVM bytecode in a .class file that can run on the Java Virtual Machine. It introduces JVM instruction families for pushing integer values and explains how the constant pool stores constants and symbolic references for reuse. ### Source excerpt Last time we created a virtual machine for our toy language. I think you can agree that designing a language which barely recognizes expressions like 2 + 3w and building a brand-new virtual machine for it seems a bit tedious. So what about keeping our microscopic language for now, but running it on a real, production-ready, battle-proven virtual machine? Like the Java Virtual Machine? Our task for today is to emit JVM bytecode in the form of a valid .class file. That file can then be fed directly to the JVM to run our program. ## Value Classes Still Need Compiler Sympathy DevFeed: [Value Classes Still Need Compiler Sympathy]() Original publisher: [Read original article]() Author: Johan Sjölén Published: 2026-08-24T00:00:00Z Content type: article Language: en Sources: [Inside Java]() Topics: [JDK 28](), [Optimization](), [Compiler]() Tags: [compiler](), [immutability](), [jdk-28](), [jep-401](), [jvm](), [openjdk](), [optimization](), [payload](), [profiling](), [project-valhalla](), [valhalla]() ### AI overview This article examines value classes as a preview feature in JDK 28 and explains how giving up object identity can enable JVM optimizations such as flattening and scalarization. It also describes limitations caused by representation changes, abstraction boundaries, mutability, and generic virtual calls. ### Source excerpt Declaring a value class is first and foremost a semantic decision. It tells our fellow programmers that its instances are defined entirely by their state and do not need identity. That clearer model is valuable in itself! The JVM's additional freedom to optimize how those values are represented is a welcome bonus. C2 can do amazing things with that freedom, but it cannot always recover information hidden behind abstraction boundaries. Profiling and inspecting the generated code remain the best ways to understand what is happening. To get the best results, we may still need to have a little sympathy for the compiler. ## Propagating User Identity Chains Across JVM Service Calls DevFeed: [Propagating User Identity Chains Across JVM Service Calls]() Original publisher: [Read original article]() Author: Peter Firmstone Published: 2026-08-23T00:00:00Z Content type: article Language: en Sources: [Nicolas Fränkel]() Topics: [Security](), [Java](), [Authorization](), [Protocol (disambiguation)]() Tags: [authorization](), [dirtychai](), [java](), [jgdms](), [jini](), [jvm](), [microservices](), [protocol](), [security](), [technical](), [tls](), [tokens]() ### AI overview This article explains how a chain of user identities crosses service calls on the wire. It distinguishes TLS machine authentication from in-band user claims, describes receiver-side limits and principal handling, and notes that standard Java 24 lacks the required authorization support without DirtyChai on both ends. ### Source excerpt Alice calls the order service. The order service calls the ledger on her behalf. At the second hop, the ledger has to decide whose authority the debit is being made under. Most stacks answer badly. Forward Alice's bearer token verbatim, and the ledger cannot tell her from the service that relayed it. Drop the token and the ledger sees a machine, with no record that a human started the chain. Neither option lets the ledger authorize the combination. ## We Gave Our Service More CPU -- and It Took Down Production DevFeed: [We Gave Our Service More CPU -- and It Took Down Production]() Original publisher: [Read original article]() Author: PULKIT GARG Published: 2026-08-10T06:48:00Z Content type: article Language: en Sources: [Housing.com]() Topics: [cpu](), [Kubernetes](), [incident]() Tags: [cpu](), [deadcode](), [incident](), [jvm](), [kubernetes](), [parallelstream](), [production](), [production-outage]() ### AI overview An incident report explains how increasing a service from 1.5 to 2.5 CPU cores caused a lead-creation API to stop creating leads across the web and app. The investigation found that Kubernetes CPU requests and limits had been treated differently: the request was reverted, but the elevated limit remained, leaving the service in its broken state. ### Source excerpt Every engineer has a story about the "harmless" change that wasn't. This is mine. Ours didn't start with a bad deploy. No risky feature flag, no sketchy migration, no Friday-evening hotfix. It started with a change every ops playbook calls safe: We gave a struggling service more CPU. We went from 1.5 cores to 2.5 cores. That's it. And within minutes, our lead-creation API -- the thing that turns a visitor tapping "Contact" into an actual business lead -- stopped creating leads. Entirely across web and app. The twist that cost us hours: the more CPU we threw at it, the worse it got. This is the story of why -- and the three-year-old landmine we stepped on. The incident in five beats -- including the "rollback" that changed nothing.Act 1: The pager goes off It's mid-afternoon. Leads flatline. Not "slow" -- zero. New listings get intermittently sluggish too. Instinct says: something downstream is down. A database. A cache. Elasticsearch. So we do what everyone does -- we start pointing fingers at infrastructure: Is Postgres healthy? Looks fine. Redis? Fine. Elasticsearch? Fine. Is the DB connection pool exhausted? Let's bump it -- 20 connections to 30. Let's add a live monitor to watch it. We even stopped incoming traffic to let the system breathe. Nothing helped. And here's the detail that made everyone's head hurt: CPU utilization wasn't even high. We had just added CPU. The graphs looked calm. The service looked healthy by every metric we trusted. Yet requests went in and never came out. When your dashboards say "fine" and your users say "down," you're not looking at the right layer. Act 2: The rollback that didn't roll back Eventually someone said the obvious thing: "Wasn't the only change today the CPU bump? Roll it back." So we did. Or we thought we did. We reverted the CPU request. The service kept failing. What we missed -- and what burned an embarrassing amount of the incident -- is that Kubernetes has two CPU knobs: request -- what the scheduler reserves for you limit ## Security Baked Into the JVM: two Subjects, one call DevFeed: [Security Baked Into the JVM: two Subjects, one call]() Original publisher: [Read original article]() Author: Peter Firmstone Published: 2026-08-09T00:00:00Z Content type: article Language: en Sources: [Nicolas Fränkel]() Topics: [Security](), [SPIFFE](), [SPIRE]() Tags: [certificates](), [dirtychai](), [java](), [jgdms](), [jini](), [jvm](), [jwt](), [microservices](), [oidc](), [permission](), [process](), [security](), [spiffe](), [spire](), [technical]() ### AI overview This article examines identity and security in the JVM through DirtyChai. It describes separate process and user identities, including SPIFFE workload credentials delivered through SPIRE and JWT/OIDC-based user identity, and explains how these identities coexist across request dispatch and privilege boundaries. ### Source excerpt The constraint system stops a bad call before it leaves the JVM. The Safe Codebase Audit Pipeline stops bad code before a client ever loads it. What remains is identity: who is calling, and can you verify it? Most frameworks answer with a token check at the door. A filter validates a bearer token, sets a thread-local variable, and hopes that nothing downstream forgets to look at it. DirtyChai answers differently. ## Install, Launch, Update: Shipping a CLI on Five Platforms -- the devrig Approach DevFeed: [Install, Launch, Update: Shipping a CLI on Five Platforms -- the devrig Approach]() Original publisher: [Read original article]() Author: Eugene Petrenko Published: 2026-08-06T00:00:00Z Content type: tutorial Language: en Sources: [Eugene Petrenko]() Topics: [Command-line interface](), [Kotlin](), [ide]() Tags: [agents](), [ai-agents](), [ai-coding](), [architecture](), [cli](), [command-line](), [devrig](), [distribution](), [eugene-petrenko](), [jdk](), [jonnyzzz](), [jvm](), [kotlin](), [mcp-steroid](), [open-source](), [sha-256](), [tag-41199d53f463]() ### AI overview This tutorial presents the devrig approach to distributing and updating a JVM command-line tool across five platforms. It describes generated install scripts with verified JDK coordinates and baked-in URLs and SHA-256 hashes, content-addressed side-by-side installations, binary-owned launchers, and updates performed by running a fresh install script. ### Source excerpt A JVM command-line tool is easy to write and miserable to ship. You need five platforms, a JDK the user does not have, an update path that never overwrites a running install, and a trust story for a `curl | sh` one-liner. Here is the architecture we ended up with in `devrig`: generate the install script from a model whose JDK coordinates are signature-verified, make installs content-addressed and side-by-side, let the binary own its own launcher, and make "update" mean nothing more than running a fresh install script ## Security Baked Into the JVM: the Safe Codebase Audit Pipeline DevFeed: [Security Baked Into the JVM: the Safe Codebase Audit Pipeline]() Original publisher: [Read original article]() Author: Peter Firmstone Published: 2026-07-19T00:00:00Z Content type: article Language: en Sources: [Nicolas Fränkel]() Topics: [Security](), [Java](), [Architecture & Design](), [systems]() Tags: [analysis](), [bytecode](), [dirtychai](), [distributed](), [java](), [jgdms](), [jini](), [jvm](), [microservices](), [security](), [supply-chain](), [systems](), [technical]() ### AI overview This article presents the Safe Codebase Audit Pipeline, or SCAP, for analyzing third-party Java JARs before clients deserialize objects from them. It focuses on supply-chain risks from malicious bytecode and blocking static initializers, and describes distributing the pipeline across hosts with separate responsibilities and restricted network access. ### Source excerpt In Part 1, the minimal deployment showed constraints traveling with the proxy: authentication, encryption, hardened deserialization, all declared in configuration and enforced at the call boundary. The proxy is a JAR. That JAR was downloaded and unmarshalled before any constraint ran. That step is the earlier problem. Distributed Java systems that load remote code are vulnerable to supply chain compromise: an attacker can replace a legitimate JAR with one containing malicious bytecode. ## Security Baked Into the JVM: why fork Apache River and OpenJDK? DevFeed: [Security Baked Into the JVM: why fork Apache River and OpenJDK?]() Original publisher: [Read original article]() Author: Peter Firmstone Published: 2026-06-28T00:00:00Z Content type: opinion Language: en Sources: [Nicolas Fränkel]() Topics: [Security](), [Java](), [openjdk](), [Architecture & Design](), [Remote Procedure Call (RPC)](), [Networks]() Tags: [authorization](), [dirtychai](), [discovery](), [distributed](), [ipv6](), [java](), [jgdms](), [jini](), [jvm](), [lock-free](), [microservices](), [openjdk](), [rpc](), [security](), [self-healing](), [technical]() ### AI overview This article introduces DirtyChai, a community fork of OpenJDK that restores Java authorization infrastructure, and JGDMS, a security-hardened fork of Apache River for dynamically discoverable microservices over IPv6. It argues that distributed systems require security beyond network firewalls and outlines the projects' complementary roles, including authorization, service discovery, hardened deserialization, transport security, proxy trust verification, and codebase safety checks. ### Source excerpt The more distributed a system, the harder it is to secure. Code crosses JVM boundaries. Objects are serialized across trust boundaries. Third-party proxies run inside your process. The usual answer is a network firewall. It helps, but it operates at the wrong level. Java 17 deprecated the SecurityManager, Java 24 put the final nail in its coffin. Most developers didn't notice. ## Hardwood 1.0: A Fast, Lightweight Apache Parquet Reader for the JVM DevFeed: [Hardwood 1.0: A Fast, Lightweight Apache Parquet Reader for the JVM]() Original publisher: [Read original article]() Published: 2026-06-25T05:30:00Z Content type: release Language: en Sources: [Gunnar Morling]() Topics: [parquet](), [releases](), [Java](), [Library](), [Open Source](), [Maven Central]() Tags: [apache-parquet](), [compatibility](), [compression](), [cpu](), [java](), [jvm](), [library](), [maven-central](), [open-source](), [parquet](), [performance](), [releases]() ### AI overview The article announces Hardwood 1.0, an open-source Apache Parquet library for Java 21 or newer and the JVM. It focuses on fast, multi-threaded reading with no mandatory dependencies, supports local and remote files, and is available from Maven Central. ### Source excerpt Table of Contents Why Hardwood What's in Hardwood 1.0 Performance The Hardwood CLI Building Open-Source With AI A Big Thank You What's Ahead Hardwood is a new Parquet library for the JVM, written from scratch to do one thing well: read (and soon, write) Apache Parquet files fast, with no mandatory dependencies. It is performance-focused and multi-threaded at its core, fanning page decoding out across all your CPU cores by default. Today, Hardwood reaches 1.0. After five preview releases since the start of the year (Alpha1, Beta1, Beta2, CR1, CR2), we now consider Hardwood ready for production, and its public API will evolve with a strong focus on backwards compatibility going forward. Hardwood targets Java 21 or newer, is open-source (Apache License 2.0), and is available from Maven Central. ## How Gradle Is Javamaxxing DevFeed: [How Gradle Is Javamaxxing]() Original publisher: [Read original article]() Author: Laura Kassovic Published: 2026-05-28T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Java](), [toolchains](), [toolchain]() Tags: [bytecode](), [compiler](), [garbage-collectors](), [gradle](), [java](), [java-8](), [jdk](), [jvm](), [openjdk](), [optimization](), [performance-optimization](), [release]() ### AI overview Gradle aggressively adopts new JDK releases because newer JVMs can improve build speed, memory use, startup behavior, and maintainability. JVM toolchains allow Gradle to run on JDK 26 while compiling and testing projects for older Java versions, including producing Java 8-compatible bytecode. ### Source excerpt Some people optimize one part of their lives to the absolute limit, then past it. They call it "-maxxing." Houseplantmaxxing. Sleepmaxxing. Tokenmaxxing. The Gradle Build Tool is Javamaxxing. TL;DR Breathe easy knowing you can run modern Gradle on JDK 26 while still shipping Java 8-compatible artifacts: Gradle aggressively adopts new JDKs because newer JVMs make builds faster, leaner, and easier to maintain. Upgrading the JDK that runs Gradle is often the easiest performance win. JVM toolchains fully separate the JVM running Gradle, the JVM compiling your code, and the JVM running your tests. NOT TL;DR We aggressively adopt new JDK releases as soon as we responsibly can. Not because it's trendy. Because newer JDKs make Gradle faster, leaner, and easier to maintain. Every OpenJDK release ships improvements to the JVM; garbage collectors, compiler infrastructure, startup behavior, memory layout, and runtime APIs. As a high-performance JVM build tool, Gradle benefits directly from all of it. The question people immediately ask is: Does this mean my project also has to run on the newest JDK? No. That coupling effectively disappeared once Gradle introduced JVM toolchains. With toolchains, the JVM that runs Gradle is completely separate from the JVM that compiles, tests, and executes your code. You can run Gradle on JDK 26 today and still produce Java 8 bytecode. What Is the Current State of Gradle and Java? We add daemon support for every new JDK as soon as the ecosystem permits: Java 24 in Gradle 8.14.0, Java 25 in 9.1.0 (released two days after JDK 25 GA), Java 26 in 9.4.0. The full mapping is in the Compatibility Matrix. We then bump the minimum JVM required to execute Gradle as users move. Gradle 9.0.0, released on July 31, 2025, raised the minimum JVM required to run the Gradle daemon to Java 17. That was the first daemon JVM floor increase since Gradle 5.0 made Java 8 the minimum back in 2018. The next major transition is already underway, Gradle 10.0.0 will likely ## Endive and the Next Chapter of WebAssembly on the JVM DevFeed: [Endive and the Next Chapter of WebAssembly on the JVM]() Original publisher: [Read original article]() Author: Andrea Peruffo Published: 2026-05-26T00:00:00Z Content type: release Language: en Sources: [Bytecode Alliance]() Topics: [WebAssembly](), [Java](), [Compiler](), [Open Source]() Tags: [announcement](), [compiler](), [fork](), [java](), [jvm](), [open-source](), [webassembly]() ### AI overview Bytecode Alliance announces Endive, a fork of Chicory and a hosted project for running WebAssembly on the JVM. The project aims to let Java developers embed, package, test, and deploy Wasm modules through familiar Java workflows, while integrating the experimental Redline compiler for native machine-code compilation. ### Source excerpt Announcement: Endive begins In September 2023, a small group of contributors set out to answer a simple question: can WebAssembly run on the JVM with zero native dependencies? The project they built, Chicory, proved it could. Within two years it was powering JRuby's Prism parser, a pure-Java SQLite driver, an embedded PostgreSQL, a pure-Java QuickJs runtime, TrinoDB Python UDFs, and many more. What started as an experiment became infrastructure. ## Metro DI for KMP mobile: From God Objects and manually checked Singletons to Compile-Time Injection DevFeed: [Metro DI for KMP mobile: From God Objects and manually checked Singletons to Compile-Time Injection]() Original publisher: [Read original article]() Author: FunkyMuse Published: 2026-05-24T17:30:00Z Content type: tutorial Language: en Sources: [FunkyMuse]() Topics: [Mobile](), [Code](), [Android](), [iOS](), [Java](), [Dagger]() Tags: [android](), [code](), [dagger](), [di](), [ios](), [jvm](), [kmp](), [kotlin](), [mobile]() ### AI overview This article describes migrating the mobile side of the Rudio Kotlin Multiplatform project from God Objects, custom thread-safe singletons, and manually managed lazy dependencies to Metro's compile-time dependency-injection graph. It explains different startup and platform-binding requirements for Android, iOS, and JVM desktop, including Android integration with Room and platform-specific Metro hooks. ### Source excerpt The Starting Point: God Object, Custom Singletons, and Lazy Maps In the previous article i talked about how the Ktor backend replaced a God Object BackendComponent with Metro's compile-time graph. The mobile side of Rudio had a remarkably similar story, except it was more interesting because there were actually two God Objects working together and someone (looks in the code, realizes it was me... ## Oracle CDC now available in Redpanda Connect DevFeed: [Oracle CDC now available in Redpanda Connect]() Original publisher: [Read original article]() Author: Prakhar Garg Published: 2026-04-09T00:00:00Z Content type: article Language: en Sources: [Redpanda]() Topics: [Databases](), [Streaming](), [Structured-data](), [Transactions](), [data](), [systems]() Tags: [announcement](), [data](), [debezium](), [event](), [jvm](), [oracle](), [redpanda-connect](), [schema](), [streaming](), [transactions]() ### AI overview Redpanda Connect v4.83.0 introduces a native Oracle CDC connector that captures inserts, updates, and deletes without a JVM, Kafka Connect cluster, or separate workers. It can snapshot existing tables, stream subsequent changes from Oracle redo logs, resume from checkpoints, and route schema-tracked Avro events to per-table Redpanda topics. ### Source excerpt Native CDC for Oracle enables real-time access without rearchitecting. No JVM, middleware, or operational overhead. ## Chicory: A JVM-Native WebAssembly Runtime for Java Libraries DevFeed: [Chicory: A JVM-Native WebAssembly Runtime for Java Libraries]() Original publisher: [Read original article]() Author: Andrea Peruffo Published: 2025-12-23T03:03:36Z Content type: article Language: en Sources: [Java Advent Calendar]() Topics: [WebAssembly](), [Java]() Tags: [2017](), [java](), [java-libraries](), [jvm](), [native](), [webassembly]() ### AI overview This article explains how Chicory brings WebAssembly execution to Java applications through a JVM-native runtime with zero native dependencies or JNI. It describes portability, JVM sandbox integration, and execution modes, and discusses Chicory's use in Java libraries. ### Source excerpt Introduction: the promise of "embed once, run anywhere" reimagined What if you could embed native-level capabilities into your Java applications, think of database engines, scripting runtimes, policy interpreters, even compilers and still remain pure Java, with no JNI, no native binaries, no concerns about OS or architecture compatibility? That is the promise of combining [...] The post Bring WebAssembly to the JVM. How Chicory Is Powering a New Generation of Java Libraries appeared first on JVM Advent. ## Delegating Java tasks to Supervised AI Dev Pipelines DevFeed: [Delegating Java tasks to Supervised AI Dev Pipelines]() Original publisher: [Read original article]() Author: Juan Antonio Breña Moral Published: 2025-12-22T03:03:48Z Content type: tutorial Language: en Sources: [Java Advent Calendar]() Topics: [cursor](), [AI Agent](), [Artificial Intelligence](), [Automation](), [Frontier Model](), [API](), [Development](), [Cross-origin resource sharing (CORS)](), [GitHub](), [GitLab](), [Hackathon-Kit]() Tags: [2025](), [ai](), [ai-agent](), [api](), [automation](), [cursor](), [dev](), [frontier-model](), [github](), [gitlab](), [jvm](), [pipeline](), [rest]() ### AI overview This tutorial explains how to use Cursor Agent CLI and Cursor Cloud Agents to delegate Java-related software tasks to frontier models. It covers running Cursor Agent CLI in development pipelines, submitting pull requests for review, and using Cursor Cloud Agents through REST endpoints with repositories, prompts, models, and API keys. ### Source excerpt During the second part of this year, Anysphere, the company behind Cursor IDE, released 2 new products that could help you in 2026 increase the level of automation in your software operations. The names of both products are: Cursor Agent CLI and Cursor Cloud Agents. The article will explain the features that both products share [...] The post Delegating Java tasks to Supervised AI Dev Pipelines appeared first on JVM Advent. ## Using Ahead-of-Time Cache Optimizations in Recent JDK Releases DevFeed: [Using Ahead-of-Time Cache Optimizations in Recent JDK Releases]() Original publisher: [Read original article]() Author: Ana-Maria Mihalceanu Published: 2025-12-17T03:03:45Z Content type: tutorial Language: en Sources: [Java Advent Calendar]() Topics: [Java](), [Caching](), [JIT](), [Memory safety verification]() Tags: [2025](), [cache](), [guides](), [java](), [java-advent](), [jdk](), [jdk25](), [jit](), [jvm](), [openjdk](), [performance](), [project-leyden](), [startup]() ### AI overview This tutorial explains how to use Ahead-of-Time cache features in recent JDK releases to improve Java application startup time and warm-up performance. It covers the train, assemble, and run workflow introduced in JDK 24 and method profiling improvements in JDK 25. ### Source excerpt As the year comes to a close, turn your focus to boosting your Java application performance by applying Ahead-of-Time (AOT) cache features in recent JDK releases. This article guides you through using AOT cache optimizations in your application, thereby minimizing startup time and achieving faster peak performance. What is the Ahead-of-time cache in the jdk [...] The post Run Into the New Year with Java's Ahead-of-Time Cache Features appeared first on JVM Advent. ## Discover Roq, the Quarkus Way for Static Site Generation in Java DevFeed: [Discover Roq, the Quarkus Way for Static Site Generation in Java]() Original publisher: [Read original article]() Author: Andy Damevin Published: 2025-12-09T02:02:47Z Content type: tutorial Language: en Sources: [Java Advent Calendar]() Topics: [Quarkus](), [Java](), [Development](), [Tailwind CSS](), [gatsby](), [Jekyll]() Tags: [2025](), [cms](), [dev](), [github-action](), [hugo](), [java](), [javascript](), [jvm](), [quarkus](), [ssg](), [static-site-generator](), [tailwindcss](), [themes]() ### AI overview This tutorial introduces Roq, a static-site generator built as a thin layer on Quarkus for Java. It explains how Roq uses Quarkus features such as Qute templates, extensions, Dev Mode, plugins, themes, data files, and static-site export, then demonstrates setup and live reloading with a Quarkus, Roq, and Tailwind project. ### Source excerpt Did you know about Roq? A powerful new tool that combines Java and Quarkus. Ok, prep a warm drink and put on some soft music and let's find out why Roq is so cool with the comfort of Quarkus Dev Mode and all its eco-system. Bonus: a touch of TailwindCss to make it look great! The post Discover Roq, the Quarkus Way for Static Site Generation in Java appeared first on JVM Advent. ## Java Hello World, LLVM Edition DevFeed: [Java Hello World, LLVM Edition]() Original publisher: [Read original article]() Author: James Hamilton Published: 2025-12-07T02:02:37Z Content type: tutorial Language: en Sources: [Java Advent Calendar]() Topics: [Java](), [LLVM](), [API](), [JIT]() Tags: [2025](), [api](), [assembly](), [bytecode](), [compilers](), [java](), [java-advent](), [jdk](), [jit](), [jvm](), [llvm]() ### AI overview This tutorial shows how to use Java's Foreign Function & Memory API to call the LLVM C API, generate LLVM IR for a Hello World program, and JIT-compile it to native code. It also introduces LLVM, its IR representations, and local installation on Ubuntu or Debian. ### Source excerpt After exploring Java bytecode in previous years (2022, 2023, 2024), this year we'll take an unexpected detour for a Java advent: instead of generating Java bytecode, we'll use Java to build and execute LLVM IR, the intermediate language behind compilers like clang. Using Java's Foreign Function & Memory (FFM) API, we'll call the LLVM C [...] The post Java Hello World, LLVM Edition appeared first on JVM Advent. ## Java Dependency and Classpath Problems in Gradle and Maven Builds DevFeed: [Java Dependency and Classpath Problems in Gradle and Maven Builds]() Original publisher: [Read original article]() Author: Tony Robalik Published: 2025-11-24T20:15:12Z Content type: opinion Language: en Sources: [DEV Community: Tony Robalik]() Topics: [Java](), [Gradle](), [Maven](), [Kotlin](), [Back end]() Tags: [analysis](), [build-tool](), [coding](), [community](), [compilers](), [dependencies](), [dependency](), [development](), [ecosystem](), [engineering](), [gradle](), [inclusive](), [java](), [jvm](), [kotlin](), [maven](), [software](), [software-supply-chain-attack]() ### AI overview This opinion article examines dependency and classpath problems in the Java ecosystem, including misleading metadata, fat JARs, split packages, reflection, protobuf usage, and compiler differences. It explains how classloader behavior can create conflicts and notes that classpath properties can also enable software supply-chain attacks. ### Source excerpt I am the author of the moderately popular (⭐ 2k) Dependency Analysis Gradle Plugin, a static analysis tool that helps Gradle build authors maintain a healthy dependency graph. I also maintain some of the largest Gradle repos on the planet: a Kotlin backend repo with over 2500 subprojects, and an Android repo with more than 7200 subprojects (both proprietary). I have... seen some shit. Note: I refer to both the cases above as being part of the "Java ecosystem," though both use Kotlin as the preferred language, and one runs on the JVM while the other runs on ART (the Android runtime) on mobile devices. I come to you with a simple proposition: I believe the Java ecosystem is cursed. Hear me out. We are cursed with... Lying metadata, overuse of "fat" jars with underuse of package relocation, split packages, undocumented usage of reflection to access upstream dependencies, usage of terms like "upstream" that have different meanings in different contexts, misuse of protobuffers, different compilers with different notions of their obligations vis-a-vis the Java class file format... Lying metadata This was already covered in-depth in This is why we can't have nice things: When POM files lie, but the summary is: sometimes dependencies have hand-written metadata, which is certainly A Choice given that build tools exist. I suppose it's harder to teach a build tool to lie. It's just a list, man Despite the bewildering complexity of dependency resolution engines in tools like Gradle and Maven, at the end of the day a classpath is just a list of class files (and jars that package class files). When your running program "sees" a class or interface for the first time, it has to load it. It does this with a ClassLoader. The classloader searches the classpath (just a list of class files!)1 and picks the first class file that matches the class it just encountered. Importantly, your classpath may have more than one class file for that class. Even well-behaved builds may have this problem, fo ## Good Neighbors: How to Reduce Maven Central Traffic from Gradle Builds DevFeed: [Good Neighbors: How to Reduce Maven Central Traffic from Gradle Builds]() Original publisher: [Read original article]() Author: Louis Jacomet Published: 2025-08-01T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Caching](), [Programming](), [Java](), [Kotlin](), [CI/CD](), [Automation]() Tags: [automation](), [caching](), [ci-cd](), [gradle](), [how-to](), [java](), [jvm](), [maven-central]() ### AI overview This article explains how organizations can reduce Maven Central traffic from Gradle builds by using an internal caching Maven repository proxy. It discusses the cost, delay, slowdown, and throttling risks of direct access, and describes configuring Gradle's centralized repository declarations to route dependency resolution through the organization's repository. The configuration also affects plugin dependency resolution through the Gradle Plugin Portal. ### Source excerpt Maven Central is a vital resource for Java, Kotlin, and other JVM communities. It provides the most popular repository for open source libraries, developer tools, documentation, and other artifacts. This service is heavily used not only by developers but also by CI/CD pipelines and automation tools. While it's best practice to use a caching proxy for Maven Central, not everyone does. This results not only in excessive traffic costs and build delays but also exposes your builds and pipelines to more slowdowns and failures due to throttling mechanisms to protect Maven Central. As Brian Fox, Sonatype's CTO, wrote in this blog post in June 2024, "83% of the total bandwidth of Maven Central is being consumed by just 1% of the IP addresses. Further, many of those IPs originate from some of the world's largest companies... we will start to work with our providers to implement throttling mechanisms aimed at the extremely heavy consumers, which are effectively abusing a community resource." As this work progresses, more organizations will face throttling, including those using Gradle, especially if they rely heavily on Maven Central without a caching proxy in place. While Gradle currently does not have a built-in equivalent of Maven's mirrorOf feature to route all dependency resolution through a caching proxy, organizations can deploy a configuration that has the same effect and is compatible with existing Gradle releases. This is possible thanks to Gradle's flexibility and rich programming model. ℹ What about the Gradle Plugin Portal? In this blog post, we showcase configuration changes that also impact the use of the Gradle Plugin Portal for resolving plugin dependencies. This is also a community resource provided for free by Gradle Inc. and, just like Maven Central, it needs to manage its workload and bandwidth usage. Note that the Plugin Portal also uses rate limiting for artifact resolution to cope with the increasing load. Using an internal artifact repository Having a ## KotlinConf 2025 Highlights Backend-Oriented Kotlin Language and Ecosystem Updates DevFeed: [KotlinConf 2025 Highlights Backend-Oriented Kotlin Language and Ecosystem Updates]() Original publisher: [Read original article]() Author: Julien Published: 2025-05-22T14:34:02Z Content type: opinion Language: en Sources: [Thoughts, stories and ideas.]() Topics: [Kotlin](), [jetbrains](), [Back end](), [Programming](), [destructuring](), [Error Handling](), [Null-Safety]() Tags: [2025](), [conference](), [destructuring](), [development](), [error-handling](), [jetbrains](), [jvm](), [kotlin](), [kotlinconf](), [null-safety](), [programming]() ### AI overview A personal assessment of KotlinConf 2025 that focuses on JetBrains' renewed attention to backend developers. The article highlights Kotlin language updates including name-based destructuring and richer error handling, while also discussing the K2 compiler and Kotlin's backend developer experience. ### Source excerpt With their keynote that JetBrains intentionally started putting backend developers in the spotlight again. They made big, impactful announcements, both at an ecosystem and language levels and I can't wait to try out all of the new goodies. ## JEP 483: Ahead-of-Time Class Loading and Linking in Java 24 DevFeed: [JEP 483: Ahead-of-Time Class Loading and Linking in Java 24]() Original publisher: [Read original article]() Published: 2025-03-27T13:00:00Z Content type: article Language: en Sources: [Gunnar Morling]() Topics: [Java](), [openjdk](), [Kafka](), [apache-flink]() Tags: [building](), [java](), [jvm](), [openjdk](), [performance]() ### AI overview This article examines JEP 483, which loads and links Java classes ahead of time and caches the results to reduce application startup time. It explains the feature's role in Project Leyden, its relationship to AppCDS, the training-run and classpath requirements, and examples using Apache Kafka and Apache Flink. ### Source excerpt Table of Contents Building an AOT Cache for Apache Kafka AOT Caching With Apache Flink Summary In the "Let's Take a Look at...!" blog series I am exploring interesting projects, developments and technologies in the data and streaming space. This can be KIPs and FLIPs, open-source projects, services, relevant improvements to Java and the JVM, and more. The idea is to get some hands-on experience, learn about potential use cases and applications, and understand the trade-offs involved. If you think there's a specific subject I should take a look at, let me know in the comments below. Java 24 got released last week, and what a meaty release it is: more than twenty Java Enhancement Proposals (JEPs) have been shipped, including highlights such as compact object headers (JEP 450, I hope to spend some time diving into that one some time soon), a new class-file API (JEP 484), and more flexible constructor bodies (JEP 492, third preview). One other JEP which might fly a bit under the radar is JEP 483 ("Ahead-of-Time Class Loading & Linking"). It promises to reduce the start-up time of Java applications without requiring any modifications to the application itself, what's not to be liked about that? Let's take a closer look! [Next page]()