# jdk Published articles for jdk. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Java 27 adds improvements to garbage collection, headers, data security, and quantum key support DevFeed: [Java 27 adds improvements to garbage collection, headers, data security, and quantum key support]() Original publisher: [Read original article]() Author: Joab Jackson Published: 2026-09-16T04:50:00Z Content type: news Language: en Sources: [www.theregister.com - Articles]() Topics: [java-27](), [Java](), [Security](), [data]() Tags: [devops](), [garbage-collection](), [improvements](), [java](), [java-27](), [jdk](), [jdk-27](), [openjdk](), [post-quantum-cryptography]() ### AI overview Java 27 introduces improvements to JDK garbage collection, header sizes, data security, and quantum key support, with the stated aim of reducing developer friction. ### Source excerpt Improvements in JDK garbage collection, header sizes, data security and quantum key support all should minimize developer friction ## JDK 27 Is Generally Available with Nine JEP-Backed Enhancements DevFeed: [JDK 27 Is Generally Available with Nine JEP-Backed Enhancements]() Original publisher: [Read original article]() Author: On September Published: 2026-09-15T00:00:00Z Content type: release Language: en Sources: [Inside Java]() Topics: [JDK 27](), [Java](), [Security](), [Cryptography](), [Quantum Computing]() Tags: [announce](), [cryptography](), [improvements](), [java](), [jdk](), [jdk-27](), [oracle](), [quantum](), [security]() ### AI overview Oracle announces the general availability of JDK 27, which includes nine enhancements covered by JDK Enhancement Proposals, including preview and incubator features across the Java language, security, performance, runtime, and libraries. ### Source excerpt JDK 27 is now available! Oracle is proud to announce the general availability of JDK 27 for developers, enterprises, and end-users. ## Java 27 Technically Within 2 Minutes DevFeed: [Java 27 Technically Within 2 Minutes]() Original publisher: [Read original article]() Author: Billy Korando Published: 2026-09-13T00:00:00Z Content type: article Language: en Sources: [Inside Java]() Topics: [JDK 27]() Tags: [java](), [jdk](), [jdk-27](), [livestream](), [release](), [review]() ### AI overview A brief review of the nine JDK Enhancement Proposals included in the JDK 27 release, with an invitation to a Java 27 livestream featuring live demos and guests. ### Source excerpt Let's review in about 2 minutes the 9 JEPs (JDK Enhancement Proposals) that were included in the JDK 27 release! ## Episode 69 "Declassifying Java 27" \[IJN\] DevFeed: [Episode 69 "Declassifying Java 27" \[IJN\]]() Original publisher: [Read original article]() Author: Billy Korando Published: 2026-09-10T00:00:00Z Content type: news Language: en Sources: [Inside Java]() Topics: [Java](), [openjdk](), [Programming]() Tags: [java](), [jdk](), [jdk-27](), [news](), [openjdk](), [podcast](), [release]() ### AI overview This episode discusses Java 27, scheduled for release on September 15, and reviews developer-impacting changes, including new features and changes to existing behavior. ### Source excerpt Java 27 is set to be released on September 15th, let's review what's coming! ## Principles of Memory Management in Java DevFeed: [Principles of Memory Management in Java]() Original publisher: [Read original article]() Author: Ron Pressler Published: 2026-09-04T00:00:00Z Content type: article Language: en Sources: [Inside Java]() Topics: [Java](), [cpu]() Tags: [2026](), [cpu](), [garbage-collectors](), [java](), [javaone](), [jdk](), [memory](), [performance](), [talk]() ### AI overview This talk explains the design choices behind the JDK's garbage collectors and how Java memory management affects application performance. It also examines the relationship between RAM and CPU and questions whether Java's memory use is inherently wasteful. ### Source excerpt In this talk, we'll explore why the JDK's garbage collectors work the way they do and how Java memory management affects application performance. We'll look at the sometimes non-obvious relationship between RAM and CPU, and why they must always be considered together. ## Acceleration of Curve25519 Field Operations with Java Software and Intrinsics DevFeed: [Acceleration of Curve25519 Field Operations with Java Software and Intrinsics]() Original publisher: [Read original article]() Author: Shawn Emery Published: 2026-09-03T00:00:00Z Content type: article Language: en Sources: [Inside Java]() Topics: [Java](), [JDK 27](), [JDK 28](), [Security](), [Post-Quantum]() Tags: [crypto](), [ed25519](), [java](), [jdk](), [jdk-27](), [jdk-28](), [performance](), [post-quantum](), [security](), [tls](), [x86]() ### AI overview JDK 27 and JDK 28 improve Curve25519 field-operation performance through software changes and architecture-specific intrinsics. The improvements benefit X25519, Ed25519, and X25519MLKEM768 operations, with gains varying by algorithm, JDK build, and x86_64 or AArch64 platform. ### Source excerpt Find out about the improved Curve25519 field performance in JDK 27 and JDK 28. ## Episode 67 "Keeping Up With the Java Release Train" \[I/O\] DevFeed: [Episode 67 "Keeping Up With the Java Release Train" \[I/O\]]() Original publisher: [Read original article]() Author: Billy Korando Published: 2026-08-20T00:00:00Z Content type: article Language: en Sources: [Inside Java]() Topics: [Java](), [Development]() Tags: [2026](), [community](), [java](), [jdk](), [release](), [release-cadence]() ### AI overview Episode 67 of the Inside Java Podcast discusses whether organizations can keep up with Java's six-month release cadence. Recorded during JavaOne 2026, Billy Korando interviews SIXT Senior Staff Engineer Danish Nawab about perspectives from outside OpenJDK on the Java ecosystem. ### Source excerpt Since Java moved to a six-month release cadence with JDK 10 in March of 2018, there has been a question if it was practical or possible for organization to keep up with such a release cadence. ## 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 ## Essential Tips for Gradle on Ephemeral CI Environments - Part 2 DevFeed: [Essential Tips for Gradle on Ephemeral CI Environments - Part 2]() Original publisher: [Read original article]() Author: Louis Jacomet Published: 2026-07-08T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Caching](), [benchmarking](), [Spring Boot](), [Docker](), [GitHub]() Tags: [benchmarking](), [build-performance](), [cache](), [docker](), [github](), [gradle](), [jdk](), [spring-boot]() ### AI overview Part 2 examines Gradle configuration-phase performance in ephemeral CI environments, focusing on dependency and script caching and the roles of the setup-gradle GitHub Action and Develocity Universal Cache. ### Source excerpt In Part 1, we explored foundational strategies for improving Gradle build performance in ephemeral CI environments, focusing on the Startup and Initialization phase. Now, in Part 2, we shift our focus to the Configuration phase: the work Gradle does after startup but before it executes any tasks. We'll benchmark dependency and script caching, then look at where the setup-gradle GitHub Action and Develocity's Universal Cache fit. Benchmarking Performance in Ephemeral CI The methodology is the same as in Part 1: each scenario builds a fresh Docker image of the Spring Boot Project with --no-cache, base images are pre-pulled, and every figure is the average of ten runs against one consistent baseline. Individual runs vary by a second or two, so read small differences as approximate rather than exact. These numbers are not intended as universal Gradle performance claims. They show the relative impact of configuration-phase optimizations for one small Spring Boot project, one Gradle version, one JDK image, and one local Docker environment. Larger builds, with more dependencies and more build logic, will generally see bigger gains from dependency and script caching than a small sample project does. NOTE: All measurements in this post are pinned to Gradle 9.5.1. If you repeat the experiment with a newer Gradle version, rebuild the prime image and update any version-specific cache paths accordingly. One difference from Part 1: for the Configuration phase, we prime the cache by building the complete Spring Boot Project, not the empty Prime Project. Caching configuration-phase work only means something when there are real dependencies and real build scripts to cache, so the prime image must reflect a realistic project. As in Part 1, that prime image is built once and only restored from, so the timed builds measure cache restore, not cache creation. Building the full project populates the following directories in the Gradle User Home: .gradle/ <-- Gradle User Home (default: ~/. ## 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 ## Official Experimental Java 17 Support for Codename One Projects DevFeed: [Official Experimental Java 17 Support for Codename One Projects]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-03-14T00:00:00Z Content type: release Language: en Sources: [CodeName One]() Topics: [Java](), [toolchain]() Tags: [experimental](), [java](), [jdk](), [language](), [release](), [toolchain]() ### AI overview Codename One projects generated with the Initializr now have official experimental support for Java 17. The support covers selected Java 17 language features and most targets, while desktop and UWP targets have limitations. Record support is planned for Codename One 7.0.229 on March 20, 2026, and newer language levels are planned for a future update. ### Source excerpt Codename One projects generated with the Initializr can now use official experimental Java 17 support, with record support arriving in Codename One 7.0.229 on March 20, 2026, and more JDK support planned next. ## 10 or more reasons to not use JDK's HttpClient DevFeed: [10 or more reasons to not use JDK's HttpClient]() Original publisher: [Read original article]() Author: brice.dutheil@gmail.com (Brice Dutheil) Published: 2026-02-08T16:53:00Z Content type: opinion Language: en Sources: [The Coffee Workshop]() Topics: [Java HttpClient](), [Java](), [HTTP](), [client](), [TLS (Transport Layer Security)]() Tags: [article](), [http](), [java](), [jdk](), [tls]() ### AI overview This opinion article argues that JDK's HttpClient, introduced with Java 11, may not be the best choice for most use cases. It discusses limitations involving Unix domain sockets, API customization, timeout behavior, SSL/TLS configuration, and certificate pinning, while noting that the JDK team has continued improving the client. ### Source excerpt This article explains 10+ reasons why after 14 JDK releases the JDK's HttpClient introduced with Java 11 is unlikely to be the best option in your app. ## 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. ## A Glance at GPU Goodness in Java: LLM Inference with TornadoVM DevFeed: [A Glance at GPU Goodness in Java: LLM Inference with TornadoVM]() Original publisher: [Read original article]() Author: Edoardo Vacchi Published: 2025-12-11T03:03:21Z Content type: tutorial Language: en Sources: [Java Advent Calendar]() Topics: [TornadoVM](), [Large Language Model](), [GPU](), [Inference](), [Java](), [openjdk](), [Programming]() Tags: [2025](), [c-c-plus-plus](), [c-plus-plus](), [gpu](), [inference](), [java](), [jdk](), [linux](), [llama3](), [llm](), [openjdk](), [tornadovm]() ### AI overview This tutorial introduces TornadoVM, an OpenJDK plugin that compiles annotated Java code for heterogeneous hardware, and explains how it can run LLM inference on GPUs. It covers installation, a basic GPU kernel, and the GPULlama3 project, which demonstrates running a Llama 3 model in Java with GPU acceleration. ### Source excerpt It seems like it's become a tradition that I announce I have joined a new company for the Java Advent of Code. At least this time it's actually an old friend: I am excited to be back at Red Hat, in the llm-d team! Does that mean I forgot about Java? Of course not. If [...] The post A Glance at GPU Goodness in Java: LLM Inference with TornadoVM 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. ## New Chainguard Images December 2024: Adoptium, AWX, CouchDB DevFeed: [New Chainguard Images December 2024: Adoptium, AWX, CouchDB]() Original publisher: [Read original article]() Published: 2025-01-16T00:00:00Z Content type: release Language: en Sources: [Chainguard: Unchained]() Topics: [Adoptium](), [openjdk](), [Ansible](), [Java](), [NoSQL](), [Open Source](), [Erlang](), [.NET MAUI](), [Process]() Tags: [adoptium](), [ansible](), [apache](), [awx](), [chainguard](), [chainguard-images](), [container-images](), [couchdb](), [erlang](), [helm](), [java](), [jdk](), [linkerd](), [net-11](), [nosql](), [open-source](), [opentofu]() ### AI overview Chainguard describes its December 2024 batch of 39 new Chainguard Images, highlighting images for Adoptium, AWX, and Apache CouchDB. The article notes FIPS-enabled variants and summarizes the intended uses and image characteristics. ### Source excerpt Chainguard released several new images in December 2024, including images for Adoptium, AWX, CouchDB, and others. Check out the full list. ## Using Renovate to update build JDK DevFeed: [Using Renovate to update build JDK]() Original publisher: [Read original article]() Published: 2025-01-08T00:00:00Z Content type: tutorial Language: en Sources: [Jake Wharton]() Topics: [Java](), [GitHub Actions](), [ci](), [Spring Boot](), [JSON](), [Development](), [Homebrew](), [toolchains]() Tags: [build](), [ci](), [dependencies](), [github-actions](), [gradle](), [java](), [jdk](), [json](), [jvm](), [renovate](), [toolchains](), [update]() ### AI overview This article explains how to use Renovate to keep the JDK used by a GitHub Actions CI build updated automatically. It moves the Java version into a .github/.java-version file, configures setup-java to read that file, and adds a custom regex manager in renovate.json to update the file. The approach allows local development with the latest JDK while preserving compatibility with older Java versions for targeting and testing. ### Source excerpt You want to be using the latest JDK for development. Don't use Gradle toolchains, they'll needlessly force you to use old JDKs. You can still target and test on old JVM versions but develop with the latest and greatest. Java and the JDK are literally built for this. Locally this hasn't been a problem. Homebrew (or your favorite equivalent) will keep your default JDK at the latest. Keeping my GitHub actions up-to-date, however, frequently slips my mind. I find projects using 19 or 20 simply because I haven't touched the CI build in the two years since 19 or 20 was the latest. We're already using Renovate to keep dependencies up to date. With a little extra programming in JSON (wince) we can have the JDK version updated to latest as well. First, migrate the existing build JDK version in your GitHub Action to a .github/.java-version file1. 21 Next, change the setup-java action to use this file rather than a hard-coded version. - uses: actions/setup-java@v4 with: distribution: 'zulu' - java-version: 21 + java-version-file: .github/.java-version Finally, in your renovate.json52, add a custom manager to update this file3. ignorePresets: [ // Ensure we get the latest version and are not pinned to old versions. 'workarounds:javaLTSVersions', ], customManagers: [ // Update .java-version file with the latest JDK version. { customType: 'regex', fileMatch: [ '\\.java-version$', ], matchStrings: [ '(?.*)\\n', ], datasourceTemplate: 'java-version', depNameTemplate: 'java', // Only write the major version. extractVersionTemplate: '^(?\\d+)', }, ], Commit, push, and wait for Renovate to send you a PR4. Now your CI build automatically tracks the latest JDK. I'm putting the .java-version file into the .github/ folder because I don't want to force this version on people using jenv or the like. The whole point of this setup is you can build with any version of Java newer than our very, very old baseline of Java 8 (although things like Gradle have a higher minimum ## Building OpenJDK From Source On macOS DevFeed: [Building OpenJDK From Source On macOS]() Original publisher: [Read original article]() Published: 2024-11-16T14:25:00Z Content type: tutorial Language: en Sources: [Gunnar Morling]() Topics: [openjdk](), [macOS](), [Xcode](), [Compiler]() Tags: [compiler](), [installation](), [jdk](), [macos](), [openjdk](), [release](), [xcode]() ### AI overview A practical guide to building JDK 24 from OpenJDK source on macOS 14.7.1. It covers the required boot JDK, Xcode, Autoconf, source checkout, configuration, and build steps, and notes a clang issue in Xcode 16.1 with alternatives. ### Source excerpt Every now and then, it can come in very handy to build OpenJDK from source yourself, for instance if you want to explore a feature which is under development on a branch for which no builds are published. For some reason I always thought that building OpenJDK is a very complex processing, requiring the installation of arcane tool chains etc. But as it turns out, this actually not true: the project does a great job of documenting what's needed and only a few steps are necessary to build your very own JDK. ## Kotlin's JDK release compatibility flag DevFeed: [Kotlin's JDK release compatibility flag]() Original publisher: [Read original article]() Published: 2024-03-13T00:00:00Z Content type: tutorial Language: en Sources: [Jake Wharton]() Topics: [Kotlin](), [Java](), [Android](), [Compiler](), [Code]() Tags: [android](), [app](), [code](), [compatibility](), [compiler](), [exception](), [ide](), [java](), [jdk](), [kotlin]() ### AI overview This article explains how compiling Kotlin code with JDK 21 can expose newer JDK APIs even when the Kotlin JVM bytecode target is set to Java 8. That caused a Kotlin extension call to resolve to the newer List member method, producing NoSuchMethodError on Android. It presents Kotlin's jvm-target validation flag, which restricts compilation against APIs unavailable in the intended target JDK. ### Source excerpt Yesterday, our Android app crashed with a weird NoSuchMethodError. java.lang.NoSuchMethodError: No interface method removeFirst()Ljava/lang/Object; in class Ljava/util/List; or its super classes (declaration of 'java.util.List' appears in /apex/com.android.art/javalib/core-oj.jar) at app.cash.redwood.lazylayout.widget.LazyListUpdateProcessor.onEndChanges(SourceFile:165) at app.cash.redwood.lazylayout.view.ViewLazyList.onEndChanges(SourceFile:210) at app.cash.redwood.protocol.widget.ProtocolBridge.sendChanges(SourceFile:125) at app.cash.redwood.treehouse.ViewContentCodeBinding.receiveChangesOnUiDispatcher(SourceFile:419) at app.cash.redwood.treehouse.ViewContentCodeBinding$sendChanges$1.invokeSuspend(SourceFile:383) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(SourceFile:33) at kotlinx.coroutines.DispatchedTask.run(SourceFile:104) at android.os.Handler.handleCallback(Handler.java:938) at android.os.Handler.dispatchMessage(Handler.java:99) at android.os.Looper.loop(Looper.java:250) at android.app.ActivityThread.main(ActivityThread.java:7868) The offending code is written in Kotlin, and looks like this: The IDE showing an italicized blue style for removeFirst means it's a Kotlin extension function which compiles down to a static helper in the bytecode. However, the exception clearly indicates we are calling a member function on List directly. What gives? In JDK 21, as part of the sequenced collection effort, the List interface added removeFirst() and removeLast() methods. According to the Kotlin docs on extension functions: If a class has a member function, and an extension function is defined which has the same receiver type, the same name, and is applicable to given arguments, the member always wins. When we bumped our build JDK to 21, the new member became available and accidentally took precedence. Oops! But wait, we set our Kotlin jvmTarget to 1.8 in order to be backwards compatible. Is that not enough? val javaVersion = JavaVersion.VERSION_1_ ## Pick the right JDK for Android Studio DevFeed: [Pick the right JDK for Android Studio]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2024-03-06T08:00:00Z Content type: tutorial Language: en Sources: [Kaushik Gopal's Site]() Topics: [Android Studio](), [Android](), [Gradle](), [ide](), [Java]() Tags: [android](), [android-studio](), [command-line](), [gradle](), [ide](), [java](), [jdk](), [sdk]() ### AI overview A guide for Android developers on configuring the JDK for Android Studio. It recommends using the JDK bundled with Android Studio, selecting it as the Gradle JDK, and keeping it aligned with JAVA_HOME to avoid conflicting Gradle daemons and IDE or build errors. ### Source excerpt If Android developers don't setup the JDK correctly, you'll be greeted with nasty errors like this: Check your module classpath error Cannot access 'java.lang.constant.Constable' which is a supertype of 'java.lang.Class'. Check your module classpath for missing or conflicting dependencies Your app might compile fine but the IDE will keep surfacing pesky errors. This is because Android developers have a variety of ways to setup the JDK for your development environment. Too many. On episode #249 of Fragmented we discussed the numerous JDK options and what they're used for. Google now has an excellent developer doc for this.1 Courtesy: Android Developer docs If you don't have time to catch up on all the valuable content above, here's the takeaways: 1. Use the JDK that comes with Android Studio # JBR2 is battle tested with Android Studio and includes enhancements for running Android Studio well. To use it as your SDK, switch your Gradle JDK to JBR: how to set jbr as your gradle jdk Do a File > Invalidate Caches after this... mother of all fixes 2. Match yourJAVA_HOME with the Gradle JDK # The Gradle JDK from Step 1 is used to compile your app from Android Studio. If you use the command line to build your app on the other hand, the JDK from your $JAVA_HOME3 is used. If both of these don't match, you can have multiple gradle daemons running around. Make sure to match the two. # ~/.zshenv export JAVA_HOME=$HOME/Applications/Android\ Studio.app/Contents/jbr/Contents/Home If you're not sure where the jbr-jdk is located: This is the way. no seriously, it's really good. ↩︎ JetBrains Runtime ↩︎ ...if you haven't customized your environment too much. It's a little more involved. ↩︎ ## Tracking Java Native Memory With JDK Flight Recorder DevFeed: [Tracking Java Native Memory With JDK Flight Recorder]() Original publisher: [Read original article]() Published: 2023-12-17T18:29:00Z Content type: tutorial Language: en Sources: [Gunnar Morling]() Topics: [JDK Flight Recorder](), [Java](), [Monitoring](), [Streaming]() Tags: [java](), [jdk](), [jdk-flight-recorder](), [jvm](), [memory](), [monitoring](), [performance](), [streaming]() ### AI overview This article explains how JDK Flight Recorder can continuously track Java native memory usage through Native Memory Tracking data. It covers the relevant JFR event types introduced in Java 20, example off-heap allocations, and streaming the data to monitoring dashboards. ### Source excerpt Table of Contents An Example Tracking RSS As regular readers of this blog will now, JDK Flight Recorder (JFR) is one of my favorite tools of the Java platform. This low-overhead event recording engine built into the JVM is invaluable for observing the runtime characteristics of Java applications and identifying any potential performance issues. JFR continues to become better and better with every new release, with one recent addition being support for native memory tracking (NMT). ## Setting JDK level in Android Gradle builds DevFeed: [Setting JDK level in Android Gradle builds]() Original publisher: [Read original article]() Author: blundell Published: 2023-11-18T09:51:40Z Content type: tutorial Language: en Sources: [Blundell]() Topics: [Gradle](), [Java](), [Android](), [toolchain](), [modules]() Tags: [android](), [androiddev](), [gradle](), [intermediate](), [intermediate-reference-androiddev-gradle-java-jdk](), [java](), [jdk](), [module](), [reference](), [toolchain]() ### AI overview A practical guide to configuring Java and JVM versions in Android Gradle projects. It recommends Java 17 when possible, Java 11 for compatibility issues, and explicit version settings for every module. ### Source excerpt The correct, complete, 2024, settings to configure the Java version in Gradle for Android. The post Setting JDK level in Android Gradle builds first appeared on Blundell. ## Installing and managing Java on macOS DevFeed: [Installing and managing Java on macOS]() Original publisher: [Read original article]() Author: Keshav Malik Published: 2023-10-12T05:00:00Z Content type: article Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [macOS]() Tags: [article](), [awareness](), [blog](), [contentlab](), [developer](), [engineering](), [guide](), [how-to](), [installation](), [java](), [jdk](), [macos](), [reviews]() ### AI overview A guide to installing and managing multiple Java versions on macOS, including manual installation, distribution choices, compatibility testing, and configuring environment variables such as JAVA_HOME. ### Source excerpt This article reviews how to install and manage different versions of Java on your macOS system to help you simplify this process. ## Using JLink to create smaller Docker images for your Spring Boot Java application DevFeed: [Using JLink to create smaller Docker images for your Spring Boot Java application]() Original publisher: [Read original article]() Author: Brian Vermeer Published: 2023-08-24T05:00:00Z Content type: article Language: en Sources: [Blog RSS Feed | Snyk]() Topics: [Docker](), [Spring Boot](), [Java](), [Docker Image](), [Application Security](), [Application Development](), [Deployment]() Tags: [acquisition](), [application-security](), [awareness](), [blog](), [blog-post](), [command-line](), [container-security](), [containers](), [deployment](), [developer](), [devrel](), [docker](), [docker-images](), [java](), [jdk](), [modules](), [performance](), [snyk-container](), [spring-boot]() ### AI overview This article explains how to use JLink with Docker to create smaller custom Java runtime images for Spring Boot and other Java applications. It describes how reducing the runtime to the modules and dependencies required by the application can lower image size, improve deployment performance, reduce storage costs, and limit container attack surface. ### Source excerpt In this blog post, we'll present an in-depth exploration of utilizing JLink to optimize Docker image sizes, enhancing application security and performance. [Next page]()