{"id":26130,"date":"2017-10-09T09:49:38","date_gmt":"2017-10-09T09:49:38","guid":{"rendered":"https:\/\/blog.jetbrains.com\/idea\/?p=16178"},"modified":"2020-07-31T09:28:17","modified_gmt":"2020-07-31T09:28:17","slug":"real-world-java-9","status":"publish","type":"idea","link":"https:\/\/blog.jetbrains.com\/ja\/idea\/2017\/10\/real-world-java-9","title":{"rendered":"Real World Java 9"},"content":{"rendered":"<p>Last\u00a0week we hosted a live webinar covering the features of Java 9 that are most interesting to developers.\u00a0 The recording is available here for those who missed it,\u00a0and we also wanted to take this opportunity to answer all those questions we didn&#8217;t\u00a0have time for during the session. If you\u00a0read beyond the fold you&#8217;ll find the timeline of which features are covered (with links to that section in the video) and\u00a0answers to all the questions\u00a0(with links and more detail where relevant).<\/p>\n<p><iframe loading=\"lazy\" width=\"560\" height=\"315\" src=\"https:\/\/www.youtube.com\/embed\/QqmQ_0tV978\" frameborder=\"0\" allowfullscreen=\"allowfullscreen\"><\/iframe><br \/>\n<!--more--><br \/>\n<iframe loading=\"lazy\" width=\"595\" height=\"485\" style=\"border: 1px solid #CCC; border-width: 1px; margin-bottom: 5px; max-width: 100%;\" src=\"\/\/www.slideshare.net\/slideshow\/embed_code\/key\/218BTngwhybX5v\" frameborder=\"0\" marginwidth=\"0\" marginheight=\"0\" scrolling=\"no\" allowfullscreen=\"allowfullscreen\"> <\/iframe><\/p>\n<h3>Timeline<\/h3>\n<ul>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=1m25s\" target=\"_blank\" rel=\"noopener\">1:25 Why Java 9?<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=3m15s\" target=\"_blank\" rel=\"noopener\">3:15 The Case Study<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=4m17s\" target=\"_blank\" rel=\"noopener\">4:17 Compiling with Java 9<\/a>\n<ul>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=5m16s\" target=\"_blank\" rel=\"noopener\">5:17 Underscore as an identifier no longer valid<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=6m43s\" target=\"_blank\" rel=\"noopener\">6:43 Encapsulate Most Internal APIs<\/a><\/li>\n<\/ul>\n<\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=9m07s\" target=\"_blank\" rel=\"noopener\">9:07 Jigsaw<\/a>\u00a0(screen freezes here until 11:32, but it&#8217;s mostly talking anyway)<\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=12m04s\" target=\"_blank\" rel=\"noopener\">12:04 Java Platform Module System<\/a>\n<ul>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=14m21s\" target=\"_blank\" rel=\"noopener\">14:21 module-info.java and live coding using JPMS in an existing application<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=18m10s\" target=\"_blank\" rel=\"noopener\">18:10 Automatic modules<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=20m20s\" target=\"_blank\" rel=\"noopener\">20:20 Using my custom modules<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=23m59s\" target=\"_blank\" rel=\"noopener\">23:59 A more complex module-info.java example<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=25m40s\" target=\"_blank\" rel=\"noopener\">25:40 Disadvantages of applying JPMS to existing code<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=28m46s\" target=\"_blank\" rel=\"noopener\">28:46 Advantages of JPMS<\/a><\/li>\n<\/ul>\n<\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=29m50s\" target=\"_blank\" rel=\"noopener\">29:50 Reactive Streams API<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=32m12s\" target=\"_blank\" rel=\"noopener\">32:12 Questions<\/a> (the answers are also covered below).\n<ul>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=34m07s\" target=\"_blank\" rel=\"noopener\">34:07 Module diagrams in IntelliJ IDEA<\/a><\/li>\n<\/ul>\n<\/li>\n<li>All Other Features\n<ul>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=43m49s\" target=\"_blank\" rel=\"noopener\">43:39 Convenience Factory Methods for Collections<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=43m49s\" target=\"_blank\" rel=\"noopener\">49:43 Private Methods on Interfaces<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=51m01s\" target=\"_blank\" rel=\"noopener\">51:01 New Methods on the Streams API<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=54m17s\" target=\"_blank\" rel=\"noopener\">54:17 New Methods on Optional<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=52m58s\" target=\"_blank\" rel=\"noopener\">58:52 The Stack Walking API<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=59m47s\" target=\"_blank\" rel=\"noopener\">59:47 Process API Updates<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=1h1m58s\" target=\"_blank\" rel=\"noopener\">1:01:58 Multi Release JAR Files<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=1h1m58s\" target=\"_blank\" rel=\"noopener\">1:05:19 Updated Deprecation<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=1h6m43s\" target=\"_blank\" rel=\"noopener\">1:06:43 HTML 5 Javadoc &amp; Javadoc Search<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=1h7m32s\" target=\"_blank\" rel=\"noopener\">1:07:47 JShell &amp; Support in IntelliJ IDEA<\/a><\/li>\n<\/ul>\n<\/li>\n<li><a href=\"https:\/\/youtu.be\/QqmQ_0tV978?t=1h9m33s\" target=\"_blank\" rel=\"noopener\">1:09:33 Summary<\/a><\/li>\n<\/ul>\n<h3>Questions<\/h3>\n<p><strong>Is there Maven support for modules? Using the standard Maven folder structure? Eg: src\/main\/java\/&#8230;\/<\/strong><\/p>\n<p>Yes, you can use the standard Maven\/Gradle file structure with Java 9 modules.\u00a0 All you need is to make sure you put your module-info.java file\u00a0into the &quot;java&quot; folder, i.e.\u00a0the root folder your packages start from.<\/p>\n<p>Maven\u00a0has full support for Java 9, although <a href=\"https:\/\/cwiki.apache.org\/confluence\/display\/MAVEN\/Java+9+-+Jigsaw\" target=\"_blank\" rel=\"noopener\">not all plugins will work<\/a>.\u00a0 See also <a href=\"https:\/\/maven.apache.org\/plugins\/maven-compiler-plugin\/examples\/module-info.html\" target=\"_blank\" rel=\"noopener\">Older projects with module-info<\/a>. Now <a href=\"https:\/\/guides.gradle.org\/building-java-9-modules\/\" target=\"_blank\" rel=\"noopener\">Gradle<\/a>\u00a0also works with Java 9\u00a0(since Gradle 4.1).<\/p>\n<p><strong>Can you use the new module system for creating android applications (in the future)?<\/strong><\/p>\n<p>I don&#8217;t know the answer to that question, nor\u00a0does there appear to be an official answer from Google.\u00a0 However, since Android now supports a <a href=\"https:\/\/developer.android.com\/studio\/write\/java8-support.html\" target=\"_blank\" rel=\"noopener\">subset of Java 8 features<\/a>, one can assume that even with the addition of official support for Kotlin on Android, the support for Java will continue to evolve to include language features from Java 9 and upwards.\u00a0 The\u00a0switch to <a href=\"https:\/\/arstechnica.com\/tech-policy\/2016\/01\/android-n-switches-to-openjdk-google-tells-oracle-it-is-protected-by-the-gpl\/\" target=\"_blank\" rel=\"noopener\">using the OpenJDK for Android<\/a>\u00a0should help this, and there is\u00a0a <a href=\"http:\/\/openjdk.java.net\/projects\/mobile\/android.html\" target=\"_blank\" rel=\"noopener\">JDK 9 Android port<\/a>.<\/p>\n<p><strong>Do you plan to clarify situation about using libraries without module-info? For example about using google adwords API.<\/strong><\/p>\n<p>You can use libraries that are not\u00a0Java 9 modules as if they were modules. Java 9 supports all non-modular Jar files as <a href=\"http:\/\/openjdk.java.net\/projects\/jigsaw\/spec\/sotms\/#automatic-modules\" target=\"_blank\" rel=\"noopener\">Automatic Modules<\/a>.\u00a0 These have special rules to make them behave like they used to before Java 9, but you should consider that\u00a0the names of these modules and their behaviour may change if or when they are ever migrated to true Java 9 modules.\u00a0 It&#8217;s worth reading <a href=\"http:\/\/cr.openjdk.java.net\/~mr\/jigsaw\/spec\/\" target=\"_blank\" rel=\"noopener\">more about the whole module system<\/a> to understand this a bit better, but for now it may be enough to know that you can still depend upon external libraries that are not modules even if you switch to using the Java 9 module system.<\/p>\n<p><strong>How we can\u00a0find all unsupported packages?<\/strong><\/p>\n<p>I assume what you want to do is find if any bits of your code are going to break before you migrate to Java 9.\u00a0 There&#8217;s a tool called <a href=\"https:\/\/docs.oracle.com\/javase\/8\/docs\/technotes\/tools\/unix\/jdeps.html\" target=\"_blank\" rel=\"noopener\">jdeps<\/a> which is designed to do this, and you can run it from Java 8 so you don&#8217;t even need to download Java 9 before checking your code.\u00a0 It has a bunch of options and can be a bit tricky to run, but basically you want to run it with the\u00a0-jdkinternals flag set.\u00a0 I wrote about how to do this <a href=\"http:\/\/www.javamagazine.mozaicreader.com\/JulyAug2017#&amp;pageSet=17&amp;page=0&amp;contentItem=0\" target=\"_blank\" rel=\"noopener\">in this tutorial<\/a> (on page 19).<\/p>\n<p><strong>The module needs to be named the same as the package name?<\/strong><\/p>\n<p>No.\u00a0 A module can contain more than one package, so it doesn&#8217;t have to have a one-to-one relationship with package name.\u00a0 However,\u00a0it&#8217;s <a href=\"http:\/\/blog.joda.org\/2017\/04\/java-se-9-jpms-module-naming.html\" target=\"_blank\" rel=\"noopener\">strongly recommended<\/a> that module names follow\u00a0<a href=\"https:\/\/en.wikipedia.org\/wiki\/Reverse_domain_name_notation\" target=\"_blank\" rel=\"noopener\">reverse-DNS<\/a>\u00a0conventions (i.e. com.jetbrains.someproduct):<\/p>\n<blockquote class=\"twitter-tweet\" data-lang=\"en\">\n<p dir=\"ltr\" lang=\"en\">Module names should be reverse-DNS, and so automatic modules can be given stable names: <a href=\"https:\/\/t.co\/llq0uSwUPw\" target=\"_blank\">https:\/\/t.co\/llq0uSwUPw<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/java?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener\">#java<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/jigsaw?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener\">#jigsaw<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/jdk9?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener\">#jdk9<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/openjdk?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener\">#openjdk<\/a><\/p>\n<p>\u2014 Mark Reinhold (@mreinhold) <a href=\"https:\/\/twitter.com\/mreinhold\/status\/860187405445242882?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener\">May 4, 2017<\/a><\/p><\/blockquote>\n<p><script src=\"\/\/platform.twitter.com\/widgets.js\" async=\"\" charset=\"utf-8\"><\/script><\/p>\n<p>Therefore you&#8217;ll see in my examples my modules are called things like com.mechanitis.demo.sense.client &#8211; where com.mechanitis.demo.sense is effectively the application, and client is the module.\u00a0 My client module has more than one package inside:<\/p>\n<p><a href=\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2017\/10\/idea-01-module-and-packages.png\" rel=\"attachment wp-att-16183\"><img decoding=\"async\" loading=\"lazy\" class=\"alignnone size-full wp-image-16183\" src=\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2017\/10\/idea-01-module-and-packages.png\" alt=\"01-module-and-packages\" width=\"1000\" height=\"300\" \/><\/a><\/p>\n<p>Module names don&#8217;t need to follow this convention, but it is a reasonable suggestion in order to make it easier to\u00a0select unique and stable module names.<\/p>\n<p><strong>In Java 9, to take advantage of Jigsaw, is it recommended\/required that packages are contained in a single module?<\/strong><\/p>\n<p>A single package can only appear in a single module.\u00a0 Therefore\u00a0if I have a package com.mechanitis.demo.sense.mood, this can only appear in one module (in my case, the mood module) and I can&#8217;t have a package with the same name in any other module.\u00a0 If I have this package in more than one module, it&#8217;s called a <a href=\"https:\/\/nirmalsasidharan.wordpress.com\/2010\/09\/02\/split-packages-an-osgi-nightmare\/amp\/\" target=\"_blank\" rel=\"noopener\">split package<\/a>\u00a0and\u00a0<a href=\"https:\/\/youtu.be\/gtcTftvj0d0?t=16m26s\" target=\"_blank\" rel=\"noopener\">isn&#8217;t allowed in the module system <\/a>(video &#8211; the discussion of split packages goes on for about eight minutes). \u00a0In fact the tool <a href=\"https:\/\/docs.oracle.com\/javase\/8\/docs\/technotes\/tools\/unix\/jdeps.html\" target=\"_blank\" rel=\"noopener\">jdeps<\/a> we talked about earlier will warn you if\u00a0the libraries you depend on right now have this problem.<\/p>\n<p><strong>Is it correct that with modules I have to type the package names twice: once as module\u2019s require part, the other as import\u2019s part?<\/strong><\/p>\n<p>Not quite true but nearly.\u00a0 The module-info.java &quot;requires&quot; directive needs a module name, not a package.\u00a0 It might look like a package name, and might even match a package name, but it&#8217;s important to understand that you require a module, and when you do you get access to all the packages\u00a0that have been exported from that module.<\/p>\n<p>So if I have:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"java\" data-enlighter-title=\"\">requires com.mechanitis.demo.sense.client<\/pre>\n<p>in\u00a0the module-info.java file of my module,\u00a0and the module-info.java file of the client module looks something like:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"java\" data-enlighter-title=\"\">module com.mechanitis.demo.sense.client {\n    exports com.mechanitis.demo.sense.client;\n    exports com.mechanitis.demo.sense.client.mood;\n    exports com.mechanitis.demo.sense.client.user;\n}\n\n<\/pre>\n<p>I can use anything from the client, client.mood and client.user packages in my own classes.\u00a0 And then yes, I will have to also import those packages in my class like\u00a0I always did, for example:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"java\" data-enlighter-title=\"\">import com.mechanitis.demo.sense.client.Dashboard;\nimport com.mechanitis.demo.sense.client.user.LeaderboardData;\nimport com.mechanitis.demo.sense.client.mood.MoodChartData;\n\npublic class MyClass {\n}\n\n<\/pre>\n<p>Note that I don&#8217;t have to add &quot;requires\u00a0com.mechanitis.demo.sense.client&quot; and &quot;requires\u00a0com.mechanitis.demo.sense.client.mood&quot; and\u00a0&quot;requires\u00a0com.mechanitis.demo.sense.client.user&quot;, because I don&#8217;t require packages, I require modules.\u00a0 Just &quot;requires\u00a0com.mechanitis.demo.sense.client&quot; gives me access to all three exported packages in that module.<\/p>\n<p>Of course if you&#8217;re using IntelliJ IDEA, you&#8217;re not &quot;typing&quot; anything twice, you&#8217;ll use code completion and quick fixes for these things.<\/p>\n<p><strong>If there were two packages: java.lang.logging, java.util.logging. How would I\u00a0know which one I require by require java.logging in module-info.java?<\/strong><\/p>\n<p>Well, the short answer to this is that you don&#8217;t need to know, IntelliJ IDEA will fix this up for you.\u00a0 If your code\u00a0is using\u00a0java.util.logging.Logger, IntelliJ IDEA sees that this package is exported in the java.logging module:<\/p>\n<p><a href=\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2017\/10\/idea-02-java-logging-module.png\" rel=\"attachment wp-att-16184\"><img decoding=\"async\" loading=\"lazy\" class=\"alignnone size-full wp-image-16184\" src=\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2017\/10\/idea-02-java-logging-module.png\" alt=\"02-java-logging-module\" width=\"1629\" height=\"721\" \/><\/a><\/p>\n<p>and will therefore suggest you add java.logging to your module-info.java:<\/p>\n<p><a href=\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2017\/10\/idea-03-require-java-logging.png\" rel=\"attachment wp-att-16185\"><img decoding=\"async\" loading=\"lazy\" class=\"alignnone size-full wp-image-16185\" src=\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2017\/10\/idea-03-require-java-logging.png\" alt=\"03-require-java-logging\" width=\"1000\" height=\"260\" \/><\/a><\/p>\n<p>But I think what&#8217;s important to understand is that a package can only belong to one module, and that when you &quot;require&quot; that module you get access to all its exported packages.\u00a0 The question is unclear about where those two packages are, whether they are in the same module or not, but in actual fact it doesn&#8217;t matter &#8211; if there were two packages, java.lang.logging and java.util.logging (for full clarification, java.lang.logging doesn&#8217;t exist but let&#8217;s assume it did for a minute) and they were both\u00a0exported from the java.logging module with:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"java\" data-enlighter-title=\"\">module java.logging {\n    exports java.util.logging;\n    exports java.lang.logging;\n}\n<\/pre>\n<p>Then when your module has &quot;requires java.logging&quot; you get access to both these packages, and you just import the Logger that you want as usual.\u00a0 You either use<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"default\" data-enlighter-title=\"\">import java.util.logging.Logger;<\/pre>\n<p>or<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"default\" data-enlighter-title=\"\">import java.lang.logging.Logger;<\/pre>\n<p>From a Java class file point of view, all of this is exactly the same as it ever was.<\/p>\n<p>If the two packages were in two different modules, then to use either one you have to identify which module the package is in.\u00a0 We saw earlier that IntelliJ IDEA will suggest you require java.logging if you try to<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"default\" data-enlighter-title=\"\">import\u00a0java.util.logging.Logger;<\/pre>\n<p>and similarly if you want to import java.lang.logging.Logger, it would suggest adding the module that contains that package to module-info.java (provided that module was either in the JDK, e.g. is something like java.fictionallogger, or is on the classpath as\u00a0an external JAR\u00a0file).<\/p>\n<p><strong>For external dependencies, are those put into the project by Maven or some other package manager when added to the module-info.java?<\/strong><\/p>\n<p>Dependency management is completely independent of the module system.\u00a0 It looks like you&#8217;re declaring dependencies when you state which modules you require, but the <a href=\"http:\/\/openjdk.java.net\/projects\/jigsaw\/spec\/\" target=\"_blank\" rel=\"noopener\">JPMS<\/a>\u00a0is not a system for defining and fetching dependencies.\u00a0\u00a0All you&#8217;re doing is telling the JVM which modules you&#8217;re going to use in advance, not what they look like as jar files or where to get them from.\u00a0 You should still be using Maven, Gradle, or whatever dependency management you&#8217;re using right now as well as the new module system.<\/p>\n<p>Similarly, JPMS specifically also doesn&#8217;t care about versioning, again this is a problem for the dependency management tool. The key thing to understand is that <a href=\"http:\/\/blog.joda.org\/2017\/04\/java-se-9-jpms-modules-are-not-artifacts.html\" target=\"_blank\" rel=\"noopener\">JPMS modules are not artifacts<\/a>.<\/p>\n<p><strong>Can we have many Java 9 modules in single IntelliJ sub-project (sub-module?), or every Java 9 module should be in separate InteliJ sub-project (module)?<\/strong><\/p>\n<p>Every\u00a0<a href=\"https:\/\/blog.jetbrains.com\/idea\/2017\/03\/support-for-java-9-modules-in-intellij-idea-2017-1\/\">Java 9 module should map to a single IntelliJ IDEA module<\/a>, there should be a one-to-one relationship between your JPMS (Java 9) module and your IntelliJ IDEA module.<\/p>\n<p><strong>Can Jigsaw point to an external repository and pull down dependencies? Like Maven central for example.<\/strong><\/p>\n<p>No, Jigsaw is not intended to replace the dependency management tools we&#8217;re using right now.<\/p>\n<p><strong>Do I have to take any special measures to make my app working with Dependency Injection Frameworks? They usually relied on reflection.<\/strong><\/p>\n<p>If you are using libraries that use reflection, you may\u00a0need to make some changes if you move to Java 9, although in theory everything should work as before &quot;out of the box&quot;\u00a0if you don&#8217;t move your application to use the new module system.\u00a0You may have to set some command line options, you might find <a href=\"https:\/\/www.sitepoint.com\/reflection-vs-encapsulation-in-the-java-module-system\/\" target=\"_blank\" rel=\"noopener\">this article useful<\/a>. \u00a0I just tested my original Java 8 application running with Java 9, and it all works without me having to make any changes, and my JavaFX UI\u00a0relies on reflection.<\/p>\n<p>If you do\u00a0adopt the module system, you simply have to &quot;open&quot; the relevant packages to the modules that need access, like I did in my client module to allow JavaFX to use reflection on my code:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"java\" data-enlighter-title=\"\">module com.mechanitis.demo.sense.client {\n    exports com.mechanitis.demo.sense.client to javafx.graphics;\n\n    opens com.mechanitis.demo.sense.client to javafx.fxml;\n    opens com.mechanitis.demo.sense.client.mood to javafx.fxml;\n    opens com.mechanitis.demo.sense.client.user to javafx.fxml, javafx.base;\n}\n<\/pre>\n<p><strong>Do you think module versioning will be introduced in future updates?<\/strong><\/p>\n<p>It&#8217;s possible, the JDK team have said they will continue to improve\u00a0the module system over the next few versions of Java.<\/p>\n<p><strong>What\u2019s the main benefit to use Java 9 modules over Maven\/Gradle?<\/strong><\/p>\n<p>You should still be using Maven\/Gradle if you&#8217;re using them now, so it&#8217;s not an either\/or.\u00a0 You&#8217;ll use Maven\/Gradle AND Java 9 modules.<\/p>\n<p><strong>Can it be used with Spring? In what version?<\/strong><\/p>\n<p>Older version of Spring may work with Java 9, and\u00a0the latest version 5.0 has <a href=\"https:\/\/spring.io\/blog\/2017\/09\/28\/spring-framework-5-0-goes-ga\" target=\"_blank\" rel=\"noopener\">specific support for JDK 9<\/a>.<\/p>\n<p><strong>How does Jigsaw impact Kotlin?<\/strong><\/p>\n<p>We had to do some work on the tooling and fix a number of library issues, like every other project on this planet! But 1.2 supports all of Jigsaw, and 1.1.50 has most of it already<\/p>\n<p><strong>Is there a way to use jlink with a Maven build?<\/strong><\/p>\n<p>Apparently there&#8217;s a <a href=\"https:\/\/maven.apache.org\/plugins-archives\/maven-jlink-plugin-LATEST\/\" target=\"_blank\" rel=\"noopener\">jlink plugin,<\/a>\u00a0although it&#8217;s still at pre-release stage.\u00a0 It would be worth trying this out and\u00a0giving any feedback you have to the team that&#8217;s working on it.<\/p>\n<p><strong>If the file is not public in the module definition, but your implementation does need it, how would you get that file?<\/strong><\/p>\n<p>You can&#8217;t, that&#8217;s the point.<\/p>\n<p>However. If you&#8217;re talking about accessing internal classes in the JDK that you&#8217;ll need while you migrate your code to a suitable replacement, you can\u00a0potentially use one of the <a href=\"http:\/\/mail.openjdk.java.net\/pipermail\/jigsaw-dev\/2017-June\/012841.html\" target=\"_blank\" rel=\"noopener\">&quot;permit illegal access&quot; flags<\/a>.<\/p>\n<p><strong>What about automodules with different versions if they used in your different modules?<\/strong><\/p>\n<p>If you have more than one version of the same library (e.g. two\u00a0jar files with different versions, like ext-library-0.1.jar and ext-library-0.2.jar) on your application classpath at the moment, this kinda works but is never really a good idea.\u00a0 If you make your application modular (i.e. start breaking your application into modules with module-info.java files and start using module path instead of classpath) and have dependencies on these same jar files, you&#8217;ll get an error.\u00a0 You&#8217;ll need to select just one version to put on your module path, and your automatic module will refer to that version.<\/p>\n<p>Remember, there&#8217;s no versioning support so if you have ext-library-ver-0.1.jar and ext-library-ver-0.2.jar on your module path, both of them map to a module name of ext.library and the module system has no way of knowing which one you mean, so you can only have one version on the module path.<\/p>\n<p><strong>Can Java 9 modules be used in Java 8 code like they where just regular external jars?<\/strong><\/p>\n<p>Since Java 8 has no concept of modules, there&#8217;s no way to use modules in Java 8 &#8211; you can&#8217;t add a module-info.java file (it won&#8217;t compile) and there&#8217;s no other way to define which modules you want to use.<\/p>\n<p>If what you mean is, can you use a JAR\u00a0file that&#8217;s a Java 9 modular jar as a dependency in a Java 8 project, then yes, you can do that (I believe &#8211; I haven&#8217;t tried it).\u00a0 Java is always designed to be backwards compatible, and the JAR\u00a0file structure for basic classes etc remains the same, it&#8217;s just if it&#8217;s modular there&#8217;s some additional info in there that Java 8 can ignore.<\/p>\n<p><strong>How can we get a list of modules which are exported by some library?<\/strong><\/p>\n<p>A single JAR\u00a0file is a single module.\u00a0 You can see which packages are in that module by looking at its module-info.java file.<\/p>\n<p><strong>Can a module export a specific class instead of an entire package?<\/strong><\/p>\n<p>No, modules export packages.<\/p>\n<p><strong>If two module definitions use the same name, is there a way to import them under a synonym so as to not cause conflicts?<\/strong><\/p>\n<p>No.\u00a0 Basically two modules can&#8217;t have the same name.\u00a0 This should be fine for &quot;real&quot; Java 9 modules but could potentially be a problem in the early days of migration when\u00a0automatic module names are determined by the name of the JAR\u00a0file.\u00a0 One of the reasons to add a <a href=\"http:\/\/mail.openjdk.java.net\/pipermail\/jpms-spec-experts\/2017-May\/000687.html\" target=\"_blank\" rel=\"noopener\">Automatic-Module-Name<\/a>\u00a0to the MANIFEST.MF file of a JAR\u00a0even if it&#8217;s not using Java 9 modules (yet) is to\u00a0encourage\u00a0sensible unique names.<\/p>\n<p><strong>For Collection factories: Are there IDEA-hints and quickfixes for many of the use cases?<\/strong><\/p>\n<p>Yes, for <a href=\"https:\/\/blog.jetbrains.com\/idea\/2017\/09\/java-9-and-intellij-idea\/\">List.of\u00a0and Set.of.<\/a>\u00a0 Not for Map, at the moment.<\/p>\n<p><strong>The List.of \/ Map.of &#8230; are those unmodifiable lists in the sense of vavr ? Can add elements to the list\/map and get a new instance, that contains the old map + the new element?<\/strong><\/p>\n<p>No, these are AbstractImmutableList implementations (at the moment, anyway), which do not allow you to append to them or to alter them.\u00a0 You don&#8217;t get the feature that you get from some immutable collections of &quot;changing&quot; the list but actually getting a new instance with the new values.\u00a0 This isn&#8217;t a pattern\u00a0that&#8217;s seen much in JDK classes.<\/p>\n<p>&nbsp;<\/p>\n<p>Phew.\u00a0 What a lot of really great questions!\u00a0 I hope some of those answers help.\u00a0 Jigsaw and the JPMS is a <strong>massive<\/strong> topic that can&#8217;t easily be covered by 30 minutes of webinar and a blog post of FAQs, so I recommend a) checking out some of the articles I link to in my <a href=\"https:\/\/trishagee.github.io\/presentation\/real_world_java_9\/\" target=\"_blank\" rel=\"noopener\">Real World Java 9 Resources<\/a> page and b) consider reading one of the many books on the topic, it&#8217;s big and complicated enough to deserve further reading.<\/p>\n","protected":false},"author":360,"featured_media":0,"comment_status":"open","ping_status":"open","template":"","categories":[30,89],"tags":[3140,3264],"cross-post-tag":[],"acf":[],"_links":{"self":[{"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/idea\/26130"}],"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\/360"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/comments?post=26130"}],"version-history":[{"count":0,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/idea\/26130\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/media?parent=26130"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/categories?post=26130"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/tags?post=26130"},{"taxonomy":"cross-post-tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/cross-post-tag?post=26130"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}