# java9 Published articles for java9. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## JPMS modules for library developers - negative benefits DevFeed: [JPMS modules for library developers - negative benefits]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2018-03-22T10:52:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [Java 9](), [modules](), [Open Source](), [.env]() Tags: [developers](), [java](), [java-9](), [java9](), [lts](), [modular](), [modules](), [open-source]() ### AI overview The article examines Java 9's Java Platform Module System (JPMS) from the perspective of open source library developers. It argues that JPMS can provide negative benefits because libraries must balance modularization against compatibility with Java 8 and the adoption risks of moving to newer Java baselines. ### Source excerpt Java 9 introduced a major new feature - JPMS, the Java Platform Module System. After six months I've come to the conclusion that JPMS currently offers "negative benefits" to open source library developers. Read on to understand why. Modules for library developers Java 8 is probably the most successful Java release ever. It is widely used and widely liked. As such, almost all open source libraries run on Java 8 (as library authors want their code to be used!). Some libraries with a long history also still run on older versions. Joda-Convert has a Java 6 baseline, while Joda-Time has a Java 5 baseline. Others have a Java 8 baseline, such as ThreeTen-Extra. Java 9 was released in September 2017, but it is not a release that will be supported for a number of years. Instead, it had a lifetime of six months and is now obsolete because Java 10 is out. And in six months time Java 11 will be out making Java 10 obsolete, and so on. While most releases last six months, some are luckier. Java 11 will be a "long term support" (LTS) release with security and bug support for a few years (Java 8 is also an LTS release). Thus, even though Java 10 is out, Java 8 is still the sensible Java version for open source library developers to target right now because it is the current LTS release. But what happens when Java 11 comes out? Since Java 8 will be unsupported relatively soon after Java 11 is released, you'd think that the sensible baseline would be 11. Unfortunately I believe many companies will be sticking with Java 8 for a long time. An aggressive open source project might move quickly to a Java 11 baseline, but doing so would be a risky strategy for adoption. The module-path Before discussing the JPMS options for open source library developers, it is important to cover the distinction between the class-path and the module-path. The class-path that we all know and love is still present in Java 9+, and it mostly works in the same way. The module-path is new. When a jar file is on ## Java's six-month release cycle makes Java 9 obsolete after Java 10 is released DevFeed: [Java's six-month release cycle makes Java 9 obsolete after Java 10 is released]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2018-02-05T13:10:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [Java 9](), [Java](), [upgrade](), [toolchain]() Tags: [dependencies](), [gradle](), [java](), [java-9](), [java9](), [lts](), [releases](), [toolchain](), [upgrade]() ### AI overview The article explains that Java's six-month release cycle makes Java 9 obsolete when Java 10 is released, ending Oracle security updates for the previous release. It outlines staying on Java 8 LTS, upgrading rapidly through releases, or accepting the security-update tradeoff, and emphasizes testing the full toolchain in advance. ### Source excerpt Java 9 is obsolete in just six weeks (20th March 2018). What? You haven't upgraded yet? Well, Java 10 is only going to last six months before it is obsolete too. Update 2018-03-20: Java 10 is released. Java 9 is obsolete. Release train impact The new Java release train means that there will be a new release of Java every six months. And when the next release comes out, the previous release is obsolete. What do I mean by obsolete? In practical terms it means that there are no more security updates from Oracle. (Theoretically, the OpenJDK community could release security updates, but there is no sign of this yet). And since you don't want to run your software without the latest security updates, you are expected to upgrade to Java 10 as soon as it is released. As a user of Java, here are three possible ways to approach the release train: Stay on Java 8, the current LTS (long term support) release, until the next LTS release occurs (Java 11) Move from Java 9 to Java 10 to Java 11, making sure you update rapidly to get the security updates Stay on Java 9 (or Java 10) and don't worry about security updates If you have already moved to Java 9, you have effectively committed to option 2 or 3. If you care about security updates, you need to be prepared to switch to Java 10 shortly after it is release on 20th March. To do this, you probably should be testing with a Java 10 pre-release now. If you find that to be a challenge, you have to stop caring about security, or consider going back to Java 8 LTS. However you look at it, being on the release train is a big commitment. Will your dependencies work on the next version? Will your IDE be ready? Will your build tool (Maven, Gradle etc.) be ready? Will your other tools (spotbugs, checkstyle, PMD etc.) be ready? How fast are you going to be able to update when the release you are on is obsolete? Lots to consider. And given the number of external tools/dependencies to consider, I think its fair to say that its a bold choice to us ## Java SE 9 - JPMS automatic modules DevFeed: [Java SE 9 - JPMS automatic modules]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2017-05-09T07:14:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [modules](), [migration]() Tags: [java](), [java9](), [migration](), [modules](), [opinion]() ### AI overview This article explains automatic modules in Java SE 9's Java Platform Module System (JPMS), including how they support migration from classpath-based applications when dependencies have not yet been converted to modules. It describes modulepath behavior, automatic-module defaults, and the author's view that this design is problematic. ### Source excerpt This article in my series on the Java Platform Module System (JPMS) is focussed on automatic modules. JPMS was previously known as Project Jigsaw and is the module system in Java SE 9. See also Module basics, Module naming and Modules & Artifacts. Automatic modules Lets say you are in charge of Java, and after 20 years you want to add a module system to the platform. As well as the problems of designing the module system itself, you have to consider migration of all the existing code written in Java (and to a degree, other JVM languages). The solution to this that JPMS has chosen is automatic modules. Unfortunately, my opinion is that it is the wrong solution. To understand automatic modules, we have to start by looking at how jar files will be specified in future. In addition to the classpath, Java SE 9 will also have a modulepath. The basic idea is that modules (jar files containing module-info.class) will be placed on the modulepath, not the classpath. In fact, placing a module on the classpath will cause the module declaration (module-info.class) to be completely ignored, which is usually not what you want. As a basic rule, the modulepath cannot see the classpath. If you create a module and put it on the modulepath, all its dependencies must also be on the modulepath. Thus, in order to write a module at all, all the dependencies must also have been converted to be modules. And many of those dependencies are likely to be open source projects, with varying release schedules. Clearly, this is a bit of a problem. Essentially, it would mean that an application would need to wait until every dependency had become a module before it could add module-info.java. The "solution" to this is automatic modules. An automatic module is a normal jar file - one without a module-info.class file - that is placed on the modulepath. Thus the modulepath will contain two types of module - "real" and "automatic". Since there is no module-info.class, an automatic module is missing the me ## Java SE 9 - JPMS modules are not artifacts DevFeed: [Java SE 9 - JPMS modules are not artifacts]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2017-04-24T08:12:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [modules](), [Maven](), [Maven Central]() Tags: [bug](), [build-tool](), [java](), [java9](), [maven-central](), [modules]() ### AI overview This article explains that Java Platform Module System modules in Java SE 9 are distinct from build artifacts such as JAR files. Each project version can produce a different artifact while retaining the same module name. Build tools such as Maven select the artifact version, while JPMS assembles the runtime module graph and rejects duplicate packages on the module path. ### Source excerpt This is the next article in a series I'm writing to help make sense of the Java Platform Module System (JPMS) in Java SE 9. JPMS was developed as Project Jigsaw. Other articles in the series are Module basics and Module naming. Module != Artifact If you want to grasp what JPMS modules are all about, it turns out that it is critical to understand what they are not. In particular, they are not artifacts. Firstly, lets define an artifact. An artifact is a file produced when developing software. For a project on Maven Central, this includes jar files of bytecode, jar files of sources and jar files of Javadoc. We are interested primarily in the bytecode for this discussion. Secondly, lets assume that a project is going to have the same module name over time. This is just like package names - projects don't change package name with every release. Given this, what is the mapping between an artifact and a module? Versions Each version of a project will consist of a different artifact (jar file), perhaps released on Maven Central. Each version will have the same module name. But, we also know that the Java platform (JPMS) does not know about versions or version-selection. Therefore, when assembling a modulepath for Java SE 9, something else is going to have to choose the correct version of the module. This will typically be the build tool, eg. Maven. But while the classpath will tolerate having two versions of the artifact (typically with bad consequences at runtime), the JPMS modulepath will refuse to start if there two modules contain the same package, as would happen if two versions of the same module are found. Maven already manages versions of course, picking one version from a set of versions, where all with the same groupId:artifactId. With Java SE 9 we can say that Maven is picking one artifact from a set of artifacts to use in the runtime JPMS module graph. Artifacts JPMS runtime module org.joda : joda-convert : 1.2 Build tool must pick one of these artifacts for th ## Java SE 9 - JPMS module naming DevFeed: [Java SE 9 - JPMS module naming]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2017-04-20T14:01:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [modules](), [Java](), [Software]() Tags: [best-practices](), [bestpractice](), [java](), [java9](), [jvm](), [module](), [modules](), [opinion](), [recommendations]() ### AI overview This opinion article recommends naming Java Platform Module System modules with reverse-DNS names related to their packages, preferably matching the super-package name. It explains namespace ownership and grouping packages into sub-modules without overlap. ### Source excerpt The Java Platform Module System (JPMS) is soon to arrive, developed as Project Jigsaw. This article follows the introduction and looks at how modules should be named. As with all "best practices", they are ultimately the opinion of the person writing them. I hope however to convince you that my opinion is right ;-). And as a community, we will certainly benefit if everyone follows the same rules, just like we benefited from everyone using reverse-DNS for package names. TL;DR - My best practices These are my recommendations for module naming: Module names must be reverse-DNS, just like package names, e.g. org.joda.time. Modules are a group of packages. As such, the module name must be related to the package names. Module names are strongly recommended to be the same as the name of the super-package. Creating a module with a particular name takes ownership of that package name and everything beneath it. As the owner of that namespace, any sub-packages may be grouped into sub-modules as desired so long as no package is in two modules. Thus the following is a well-named module: module org.joda.time { requires org.joda.convert; exports org.joda.time; exports org.joda.time.chrono; exports org.joda.time.format; // not exported: org.joda.time.base; // not exported: org.joda.time.tz; } As can be seen, the module contains a set of packages (exported and hidden), all under one super-package. The module name is the same as the super-package name. The author of the module is asserting control over all names below org.joda.time, and could create a module org.joda.time.18n in the future if desired. To understand why this approach makes sense, and the finer details, read on. JPMS naming Naming anything in software is hard. Unsurprisingly then, agreeing an approach to naming modules has also turned out to be hard. The naming rules allow dots, but prohibit dashes, thus lots of name options are closed off. As a side note, module names in the JVM are more flexible, but we are only cons ## Java 9 modules - JPMS basics DevFeed: [Java 9 modules - JPMS basics]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2017-04-17T05:17:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [modules](), [Java 9](), [Java](), [Access Control]() Tags: [access-control](), [java](), [java-9](), [java9](), [jvm](), [maintainability](), [modules]() ### AI overview This article introduces the Java Platform Module System (JPMS), the major new feature of Java SE 9. It explains modules as a new JVM structural element that contains packages and enables stronger access control, while noting compatibility with most existing code. ### Source excerpt The Java Platform Module System (JPMS) is the major new feature of Java SE 9. In this article, I will introduce it, leaving most of my opinions to a follow up article. This is based on these slides. Java Platform Module System (JPMS) The new module system, developed as Project Jigsaw, is intended to raise the abstraction level of coding in Java as follows: The primary goals of this Project are to: * Make the Java SE Platform, and the JDK, more easily scalable down to small computing devices; * Improve the security and maintainability of Java SE Platform Implementations in general, and the JDK in particular; * Enable improved application performance; and * Make it easier for developers to construct and maintain libraries and large applications, for both the Java SE and EE Platforms. To achieve these goals we propose to design and implement a standard module system for the Java SE Platform and to apply that system to the Platform itself, and to the JDK. The module system should be powerful enough to modularize the JDK and other large legacy code bases, yet still be approachable by all developers. However as we shall see, project goals are not always met. What is a JPMS Module? JPMS is a change to the Java libraries, language and runtime. This means that it affects the whole stack that developers code with day-to-day, and as such JPMS could have a big impact. For compatibility reasons, most existing code can ignore JPMS in Java SE 9, something that may prove to be very useful. The key conceptual point to grasp is that JPMS adds new a concept to the JVM - modules. Where previously, code was organized into fields, methods, classes, interfaces and packages, with Java SE 9 there is a new structural element - modules. a class is a container of fields and methods a package is a container of classes and interfaces a module is a container of packages Because this is a new JVM element, it means the runtime can apply strong access control. With Java 8, a developer can express th ## Java Time (JSR-310) enhancements in Java SE 9 DevFeed: [Java Time (JSR-310) enhancements in Java SE 9]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2017-02-07T14:47:00Z Content type: article Language: en Sources: [Stephen Colebourne]() Topics: [DateTime](), [Java](), [LocalDate](), [API]() Tags: [format](), [formatting](), [java](), [java9](), [jdk](), [jsr310](), [localdate](), [stream](), [time]() ### AI overview This article reviews selected enhancements to the java.time API planned for Java SE 9 after its introduction in Java SE 8. It covers new LocalDate date-stream methods, higher clock precision and millisecond-compatible ticking, more efficient epoch-second conversion, expanded Duration operations, new Instant conversion factories, and additional date-time formatting and parsing support. ### Source excerpt The java.time.* API (JSR-310) was added to Java SE 8, but what has been going on since then? Java Time in Java SE 9 There are currently 117 java time issues targetted into Java SE 9. Most of these are not especially interesting, with a lot of mistakes in the Javadoc that needed fixing. What follows are some of the interesting ones: Main enhancements: JDK-8146218 - Add LocalDate.datesUntil method producing Stream. Adds two new methods - LocalDate.datesUntil(LocalDate) and LocalDate.datesUntil(LocalDate,Period) - returning a stream of dates. JDK-8068730 - Increase precision of Clock.systemUTC(). The clock in Java - System.currentTimeMillis() - has ticked in milliseconds since Java was first released. With Java SE 9, users of Clock will see higher precision, depending on the available clock of the operating system. JDK-8071919 - Clock.tickMillis(ZoneId zone) method. With the system clock now returning higher precision, a new method was added - Clock.tickMillis(ZoneId) - that chops off the extra precision to restrore the millisecond ticking behaviour of Java SE 8. JDK-8030864 - Add efficient getDateTimeMillis method to java.time. This adds two methods named epochSecond to Chronology that have no object creation to convert date-time fields to an epoch-second. JDK-8142936 - Duration methods for days, hours, minutes, seconds, etc. The Java SE 8 API of Duration turned out to be incomplete for certain use cases. This change adds a slew of new methods that allow parts of the duration to be reliably returned. JDK-8148849 - Truncating Duration. Adds a method Duration.truncatedTo(TemporalUnit) to allow truncation, similar to the existing method on Instant. JDK-8032510 - Add Duration.dividedBy(Duration). A new method to allow a duration to be divided by another duration. JDK-8133079 - LocalDate and LocalTime ofInstant() factory methods. Add new factory methods in LocalDate and LocalTime to simplify conversion from Instant. JDK-8143413 - Add toEpochSecond methods for efficient acc ## Private methods in interfaces in Java 9 DevFeed: [Private methods in interfaces in Java 9]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2016-09-20T06:26:00Z Content type: tutorial Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [Java 9](), [interfaces](), [Code]() Tags: [code](), [feature](), [interfaces](), [java](), [java-9](), [java9](), [new-feature]() ### AI overview This article explains private methods on interfaces in Java 9. It contrasts them with the public abstract, static, and default methods supported in earlier Java versions and describes supported and invalid modifier combinations. Private interface methods may be static or instance methods and are not inherited by sub-interfaces or implementations. ### Source excerpt Java SE 9 is slowly moving towards the finishing line. One new feature is private methods on interfaces. Private methods on interfaces in Java 9 In Java 7 and all earlier versions, interfaces were simple. They could only contain public abstract methods. Java 8 changed this. From Java 8, you can have public static methods and public default methods. public interface HolidayCalendar { // static method, to get the calendar by identifier public static HolidayCalendar of(String id) { return Util.holidayCalendar(id); } // abstract method, to find if the date is a holiday public abstract boolean isHoliday(LocalDate date); // default method, using isHoliday() public default boolean isBusinessDay(LocalDate date) { return !isHoliday(date); } } Note that I have chosen to use the full declaration, with "public" on all three methods even though it is not required. I have argued that this is best practice for Java SE 8, because it makes the code clearer (now there are three types of method) and prepares for a time when there will be non-public methods. And that time is very soon, as Java 9 is adding private methods on interfaces. public interface HolidayCalendar { // example of a private interface method private void validateDate(LocalDate date) { if (date.isBefore(LocalDate.of(1970, 1, 1))) { throw new IllegalArgumentException(); } } } Thus, methods can be public or private (with the default being public if not specified). Private methods can be static or instance. In both cases, the private method is not inherited by sub-interfaces or implementations. The valid combinations of modifiers in Java 9 will be as follow: public static - supported public abstract - supported public default - supported private static - supported private abstract - compile error private default - compile error private - supported Private methods on interfaces will be very useful in rounding out the functionality added in Java 8. ## Var and val in Java? DevFeed: [Var and val in Java?]() Original publisher: [Read original article]() Author: Stephen Colebourne (noreply@blogger.com) Published: 2016-03-26T00:04:00Z Content type: opinion Language: en Sources: [Stephen Colebourne]() Topics: [Java](), [Java Language](), [Developer experience](), [code productivity]() Tags: [c-sharp](), [coding](), [developer-experience](), [java](), [java-language](), [java9](), [val](), [var]() ### AI overview This opinion examines proposed local variable type inference for Java under JEP-286, including the possible use of var, val, or let. It argues that the feature could reduce Java's verbosity while making some code reviews harder, and considers Java's history when evaluating the keyword choice. ### Source excerpt Should local variable type inference be added to Java? This is the question being pondered right now by the Java language team. Local Variable Type Inference JEP-286 proposes to add inference to local variables using a new psuedo-keyword (treated as a "reserved type name"). We seek to improve the developer experience by reducing the ceremony associated with writing Java code, while maintaining Java's commitment to static type safety, by allowing developers to elide the often-unnecessary manifest declaration of local variable types. A number of possible keywords have been suggested: var - for mutable local variables val - for final (immutable) local variables let - for final (immutable) local variables auto - well lets ignore that one shall we... Given the implementation strategy, it appears that the current final keyword will still be accepted in front of all of the options, and thus all of these would be final (immutable) variables: final var - changes the mutable local variable to be final final val - redundant additional modifier final let - redundant additional modifier Thus, the choice appears to be to add one of these combinations to Java: var and final var var and val - but final var and final val also valid var and let - but final var and final let also valid In broad terms, I am unexcited by this feature and unconvinced it actually makes Java better. While IDEs can mitigate the loss of type information when coding, I expect some code reviews to be significantly harder (as they are done outside IDEs). It should also be noted that the C# coding standards warn against excessive use of this feature: Do not use var when the type is not apparent from the right side of the assignment. Do not rely on the variable name to specify the type of the variable. It might not be correct. Having said the above, I suspect there is very little chance of stopping this feature. The rest of this blog post focuses on choosing the right option for Java Best option for Java When thi