# Multi-release JARs in Java 9: Risks and Gradle Usage

DevFeed: [Multi-release JARs in Java 9: Risks and Gradle Usage](<https://devfeed.tech/articles/multi-release-jars-good-or-bad-idea-24671.md>)

Original publisher: [Read original article](<https://blog.gradle.org/mrjars>)

Author: Cédric Champeau

Published: 2017-12-19T05:00:00Z

Content type: opinion

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Java](<https://devfeed.tech/topics/java.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>)

Tags: [gradle](<https://devfeed.tech/tags/gradle.md>), [java](<https://devfeed.tech/tags/java.md>), [java-8](<https://devfeed.tech/tags/java-8.md>)

## AI overview

This article examines Java 9 multi-release JARs, which package different versions of the same class for different Java runtimes. It argues that the technology carries significant adoption risks while explaining how to produce and consume multi-release JARs with Gradle.

## Source excerpt

With Java 9 came a new feature of the Java runtime called multi-release jars. For us at Gradle, it's probably one of the most controversial additions to the platform. TL/DR, we think it's a wrong answer to a real problem. This post will explain why we think so, but also explain how you can build such jars if you really want to. Multi-release JARs, aka MRJARs, are a new feature of the Java platform, included in the Java 9 JDK. In this post, we will elaborate on the significant risks of adopting this technology and provide how one can produce and consume multi-release JARs with Gradle, if desired. In a nutshell, multi-release jars allow you to package several versions of the same class, for consumption by different runtimes. For example, if you run on JDK 8, the Java runtime would use the Java 8 version of the class, but if you run on Java 9, it would use the Java 9 specific implementation. Similarly, if a version is built for the upcoming Java 10 release, then the runtime would use it instead of the Java 9 and default (Java 8) versions. Use Cases for multi-release JARs Optimized runtime. This answers a problem that lots of developers have faced in real world: when you develop an application, you don't know in what runtime it's going to be executed. However, you know that for some runtimes you can implement optimized versions of the same class. For example, imagine that you want to display the Java version number that your application is currently executed on. For Java 9, you can use the Runtime.getVersion method. However, this is a new method only available if you run on Java 9+. If you target more runtimes, say, Java 8, then you need to parse the java.version property. So you end up with 2 different implementations of the same feature. Conflicting APIs : Another common use case is to handle conflicting APIs. For example, you need to support 2 different runtimes, but one has deprecated APIs. There are currently 2 widely used solutions to this problem: The first one i