{"id":73628,"date":"2020-09-09T14:16:39","date_gmt":"2020-09-09T14:16:39","guid":{"rendered":"https:\/\/blog.jetbrains.com\/?post_type=idea&p=73628"},"modified":"2021-10-04T14:56:37","modified_gmt":"2021-10-04T13:56:37","slug":"java-15-and-intellij-idea","status":"publish","type":"idea","link":"https:\/\/blog.jetbrains.com\/ja\/idea\/2020\/09\/java-15-and-intellij-idea","title":{"rendered":"Java 15 and IntelliJ IDEA"},"content":{"rendered":"

Java 15 introduces a new language feature \u2013 sealed classes and interfaces<\/a>. The language syntax allows you to restrict the classes or interfaces that can extend or implement other classes or interfaces. The goal is to let you define the possible hierarchies in your business domain in a declarative manner, so that it is easier to process them. This language feature is introduced as a preview language feature<\/a>.<\/p>\n

Java 15 also modifies the preview language feature Records<\/a>, introduced in Java 14, and enhances the interfaces and enums you are used to working with. Pattern Matching for instanceof<\/a>, introduced as a preview language feature in Java 14, is in its second preview in Java 15, without any changes. Introduced in Java 13, Text Blocks<\/a> are being added to Java 15 as a standard language feature. There are no changes to Text Blocks from Java 14.<\/p>\n

In this article, I will cover all the new and updated language features in Java 15, why you need them, and I\u2019ll show you how to use them in IntelliJ IDEA<\/a>. Let\u2019s get started.<\/p>\n

\"\"
\n<\/p>\n

Sealed classes and interfaces (a preview language feature)<\/h2>\n

By defining a class as a sealed class<\/em>, you can explicitly define which other classes can extend it. On the one hand, it lets you reuse a class with inheritance, and on the other hand, it lets you restrict which classes can extend it. But why would you need to create restricted hierarchies?<\/p>\n

Need for creating restricted hierarchies<\/h3>\n

Imagine you are creating an application that helps its users with gardening activities. Depending on the type of plant, a gardener might need to do different activities. Let\u2019s model the plant hierarchy as follows (I\u2019m not detailing the classes on purpose):<\/p>\n

class Plant {}\n\nclass Herb extends Plant {}\nclass Shrub extends Plant {}\nclass Climber extends Plant{}\n\nclass Cucumber extends Climber {}<\/pre>\n
The following is an example of how the Gardener class might use this hierarchy:<\/p>\n
\npublic class Gardner {\n   int process(Plant plant) {\n       if (plant instanceof Cucumber) {\n           return harvestCucumber();\n       } else if (plant instanceof Climber) {\n           return sowClimber();\n       } else if (plant instanceof Herb) {\n           return sellHerb();\n       } else if (plant instanceof Shrub) {\n           return pruneShrub();\n       } else {\n           System.out.println("Unreachable CODE. Unknown Plant type");\n           return 0;\n       }\n   }\n\n   private int pruneShrub() { .. }\n   private int sellHerb() { .. }\n   private int sowClimber() { .. }\n   private int harvestCucumber() { .. }\n}<\/pre>\n
The problem code is the assumption that a developer has to deal with in the else<\/code> part. Though unreachable now, what happens if another developer adds a class to this hierarchy? Sealed classes can impose this restriction on the hierarchies at the language level.<\/p>\n
Define secure hierarchies with sealed classes<\/h3>\n
With the modifier sealed<\/code>, you can declare a class as a sealed class. A sealed class uses the reserved keyword permits<\/code> to list the classes that can extend it directly. The subclasses can either be final, non-sealed, or sealed.<\/p>\n
The following gif shows how to change the declaration of a regular class to a sealed class and modify the declaration of the classes that extend it:<\/p>\n
\"\"<\/p>\n
Here\u2019s the modified code for reference:<\/p>\n
\nsealed public class Plant permits Herb, Shrub, Climber {\n}\n\nfinal class Herb extends Plant {}\nnon-sealed class Shrub extends Plant {}\nsealed class Climber extends Plant permits Cucumber{}\n\nfinal class Cucumber extends Climber {}<\/pre>\n
By allowing a predefined set of classes to extend your class, you can decouple accessibility from extensibility. You can make your sealed class accessible to other packages and modules, but you can still control who can extend it. In the past, to prevent classes from being extended, developers created package-private classes. However, this also meant that these classes had limited accessibility. This is no longer the case if you use sealed classes.<\/p>\n
You can get the permitted subclasses via reflection using the Class.permittedSubclasses()<\/code> method. This makes it possible to enumerate the complete sealed hierarchy at runtime, which can be useful.<\/p>\n
Let\u2019s quickly check the configuration of IntelliJ IDEA on your system to ensure you can get the code running it.<\/p>\n
IntelliJ IDEA Configuration<\/h3>\n
Java 15 features are supported in IntelliJ IDEA<\/a> 2020.2, which was released in July 2020. You can configure it to use Java 15 by selecting the Project SDK as 15 and choosing the \u2018Project language level\u2019 as \u201815 (Preview) \u2013 Sealed types, records, patterns, local enums and interfaces\u2019 for your Project and Modules settings.<\/p>\n
\"\"<\/p>\n
Java 15 will be GA (General Availability) on September 15, 2020, after which you will also be able to download it directly from IntelliJ IDEA. To do so, click on SDKs, under \u2018Platform Settings\u2019, then click the \u2018+\u2019 sign at the top, choose \u2018Download JDK\u2019, then select the Vendor and the version and the directory to download the JDK to.<\/p>\n
Revisiting processing of Plant types in class Gardner<\/h3>\n
After creating a sealed hierarchy, you will be able to process an instance from the hierarchy in a precise manner and won\u2019t need to deal with any \u2018general\u2019 implementations. The process<\/code> method in class Gardner<\/code> will work with no chance of running the else<\/code> clause. However, the syntax of the if<\/code>–else<\/code> construct will still need you to define the else<\/code> part (this may change in a future Java version).<\/p>\n
Type-test-patterns<\/em>, introduced with Pattern Matching for instanceof in Java 14, might be added to the switch expressions in future Java versions. With the enhanced switch expressions, you are able to work with the exhaustive list of extended types. This lets you eliminate the definition of any \u2018general code\u2019 to execute for an unmatched Plant<\/code> type passed to the method processInAFutureJavaVersion<\/code>:<\/p>\n
\n\/\/ This code doesn't work in Java 15.\n\/\/ It would work in a future Java version after the addition of \n\/\/ type-test-pattern to the switch expressions\nint processInAFutureJavaVersion(Plant plant) {\n   return switch (plant) {\n       case Cucumber c -> c.harvestCucumber();\n       case Climber cl -> cl.sowClimber();\n       case Herb h -> h.sellHerb();\n       case Shrub s -> s.pruneShrub();\n   }\n}<\/pre>\n
Package and module restrictions<\/h3>\n
Sealed classes and their implementations can\u2019t span across multiple modules. If a sealed base class is defined in a named module, all its implementations must be defined in the same module. However, they can appear in different packages.<\/p>\n
For a sealed class defined in an unnamed module, all its implementations must be defined in the same package.<\/p>\n
Rules for base and extended classes<\/h3>\n
The classes that extend a sealed class must either be final, non-sealed, or sealed. A final class, prohibits further extension. A non-sealed class allows other classes to extend it. And a sealed subclass must follow the same set of rules as the parent base class \u2013 it could be extended by an explicit list of other classes.<\/p>\n
A sealed class can be abstract too. The extended classes could be defined as abstract or concrete classes.<\/p>\n
Let\u2019s modify the set of classes I used in the preceding section and define the class Plant<\/code> as an abstract class with an abstract method grow()<\/code>. Since the derived class Herb<\/code> is a final class, it must implement the method grow()<\/code>. The non-sealed derived class Shrub<\/code> is now an abstract class, and it may not implement the method grow()<\/code>. The sealed derived class Climber<\/code> implements the abstract method grow()<\/code>, if it doesn\u2019t need to be defined as an abstract class:<\/p>\n
\"\"<\/p>\n
Here\u2019s the modified code for reference:<\/p>\n
\nsealed abstract public class Plant permits Herb, Shrub, Climber {\n   abstract void grow();\n}\n\nfinal class Herb extends Plant {\n   @Override\n   void grow() {\n   }\n}\n\nnon-sealed abstract class Shrub extends Plant {}\n\nsealed class Climber extends Plant permits Cucumber{\n   @Override\n   void grow() {\n   }\n}\n\nfinal class Cucumber extends Climber {}<\/pre>\n
If you define a sealed class and its derived classes in the same source file, you can omit the modifier permits<\/code> and the name of the derived classes that are included in the declaration of a sealed class. In this case, the compiler can infer the hierarchy.<\/p>\n
Sealed interfaces<\/h3>\n
A sealed interface allows you to explicitly specify the interfaces that can extend it and the classes (including records) that can implement it. It follows rules similar to sealed classes.<\/p>\n
However, since you can\u2019t declare an interface using modifier final<\/code> \u2013 because doing so would clash with its purpose, as interfaces are meant to be implemented \u2013 an inheriting interface can be declared using either sealed<\/code> or non-sealed<\/code> modifiers. The permits<\/code> clause of an interface declaration lists the classes that can directly implement a sealed interface and interfaces that can extend it. An implementing class can be either final, sealed or non-sealed. Since records, introduced in Java 14, are  implicitly final, they don\u2019t need any additional modifiers:<\/p>\n
\"\"<\/p>\n
Here\u2019s the code for reference:<\/p>\n
\nsealed public interface Move permits Athlete, Person, Jump, Kick {\n}\n\nfinal class Athlete implements Move {}\nrecord Person(String name, int age) implements Move {}\nnon-sealed interface Jump extends Move {}\nsealed interface Kick extends Move permits Karate {}\n\nfinal class Karate implements Kick {}<\/pre>\n
Let\u2019s move on to the next enhancement in Java 15 \u2013 the introduction of local records.<\/p>\n
Records<\/h2>\n
A new type of class, Records introduced a compact form to model value objects. A preview language feature in Java 14, Records is in its second preview in Java 15, with a few changes.<\/p>\n
If you are new to Records, or if you want to find out how Records are supported in IntelliJ IDEA, please refer to my Java 14 and IntelliJ IDEA<\/a> blog post. IntelliJ IDEA has a lot of features to help you create and use Records and this blog post explains it using hands-on examples.<\/p>\n
In this blog post, I\u2019ll cover the changes to Records from Java 14 to Java 15.<\/p>\n
Java 15 allows you to define local records to model a domain object, while you are processing values in a method. In the following example, the method getTopPerformingStocks<\/code> finds and returns the names of Stocks that have the highest value on a specified date.<\/p>\n
\nList<String> getTopPerformingStocks(List<Stock> allStocks, LocalDate date) {\n   \/\/ TopStock is a local record\n   record TopStock(Stock stock, double stockValue) {}\n\n   return allStocks.stream()\n              .map(s -> new TopStock(s, getStockValue(s, date)))\n              .sorted((s1, s2) -> Double.compare(s1.stockValue(), s2.stockValue()))\n              .limit(2)\n              .map(s -> s.stock.getName())\n              .collect(Collectors.toList());\n\n}<\/pre>\n
Local interfaces and enums<\/h2>\n
Java 15 allows declaration of local enums and interfaces too \u2013 for the same reason. You can encapsulate your data or business logic, which is local to a method, within the method.<\/p>\n
\npublic void createLocalInterface() {\n   interface LocalInterface {\n       void aMethod();\n   }\n   \/\/ Code to use LocalInterface\n}\n\npublic void createLocalEnum() {\n   enum Color {RED, YELLOW, BLUE}\n   \/\/ Code to use enum Color\n}<\/pre>\n
However, they cannot capture any context variable. For example, for the local enum Data<\/code>, the enum constants FOO<\/code> and BAR<\/code> can\u2019t be created by using the method parameter input<\/code> in the method test()<\/code>:<\/p>\n
\nvoid test(int input) {\n   enum Data {\n       FOO(input), BAR(input*2); \/\/ Error. Can\u2019t refer to input\n\n       private final int i;\n\n       Data(int i) {\n           this.i = i;\n       }\n   }\n}<\/pre>\n
Pattern Matching for instanceof<\/h2>\n
Many Java developers use the instanceof<\/code> operator to check whether a given reference variable is of a certain type. They compare a reference variable to a type by using the instanceof<\/code> operator. If the result is true<\/code>, the next obvious step is to explicitly cast it to the type they compared it with to access its members. These steps have an obvious repetition here, like compare-ifResultTrue-castToType<\/em>.<\/p>\n
In Java 14, the usage of the instanceof<\/code> operator was simplified by the addition of Pattern Matching to the instanceof<\/code> operator. It introduces a pattern variable, so you don\u2019t need additional variables or explicit casting, making your code safer and more concise to write and read.<\/p>\n
Pattern Matching for instanceof is in its second preview in Java 15 (without any changes from Java 14).<\/p>\n
Please refer to my Java 14 and IntelliJ IDEA<\/a> blog post, to find out how IntelliJ IDEA supports this new feature by adding new intentions. This blog post also has some excellent examples of how to refactor your code using this feature and other inspections from IntelliJ IDEA, like merging nested if and extracting or inlining variables.<\/p>\n
Text Blocks<\/h2>\n
Multiline Strings, Text Blocks have been added as a standard language feature in Java 15 (without any changes from Java 14).<\/p>\n
Please refer to my Java 14 and IntelliJ IDEA blog post<\/a>, to find out how IntelliJ IDEA supports Text Blocks and you can use it in your applications.<\/p>\n
Preview Language Features<\/h2>\n
Sealed classes and interfaces have been released as a preview language feature in Java 15. With Java\u2019s new release cadence of six months, new language features are released as preview features. They may be reintroduced in later Java versions in the second or third preview, with or without changes. Once they are stable enough, they may be added to Java as a Standard Language feature.<\/p>\n
Preview language features are complete but not permanent, which essentially means that these features are ready to be used by developers, although their finer details could change in a future Java release depending on developer feedback. Unlike an API, language features can\u2019t be deprecated in the future. So, if you have feedback about any of the preview language features, feel free to share it on the JDK mailing list<\/a> (free registration required).<\/p>\n
Because of how these features work, IntelliJ IDEA is committed to only supporting preview features for the current JDK. Preview language features can change across Java versions, until they are dropped or added as a standard language feature. Code that uses a preview language feature from an older release of the Java SE Platform might not compile or run on a newer release. For example, Switch Expressions in Java 12 were released with the usage of break to return a value from a Switch Expression\u2019s branch, which was later changed to yield. Support for using break to return a value from Switch Expressions has already been dropped in IntelliJ IDEA.<\/p>\n
Summary<\/h2>\n
IntelliJ IDEA<\/a> is not only committed to supporting new Java features, but also to ensuring that our existing intentions and inspections work with them.<\/p>\n
IntelliJ IDEA<\/a> 2020.2 already supports all the new language features from Java 15. Try out Sealed classes and interfaces, Records, Pattern Matching for instanceof, and Text Blocks today. You can download it using this link<\/a>.<\/p>\n
We love to hear from our users. Don\u2019t forget to submit your feedback regarding the support for these features in IntelliJ IDEA.<\/p>\n
Happy Developing!<\/p>\n","protected":false},"author":921,"featured_media":73787,"comment_status":"closed","ping_status":"closed","template":"","categories":[808,4759],"tags":[155,6290,76,6758,3390,3389,6291,3372],"cross-post-tag":[],"acf":[],"_links":{"self":[{"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/idea\/73628"}],"collection":[{"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/idea"}],"about":[{"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/types\/idea"}],"author":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/users\/921"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/comments?post=73628"}],"version-history":[{"count":3,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/idea\/73628\/revisions"}],"predecessor-version":[{"id":181686,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/idea\/73628\/revisions\/181686"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/media\/73787"}],"wp:attachment":[{"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/media?parent=73628"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/categories?post=73628"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/tags?post=73628"},{"taxonomy":"cross-post-tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/cross-post-tag?post=73628"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}