Java experts weigh in on the future of modular Java and reveal what’s on their Java 11 wish list
© Shutterstock / Rasdi Abdul Rahman
Never a dull moment with Java! In the last part of our interview series, our interviewees weigh in on the future of modular Java and present their Java 11 wish list.
“Introducing the concept of a module into Java as a first-class citizen is a good idea”
Our Java 10 interview series is coming to an end but we still have two more topics to discuss: the future of modularity and the Java 11 wish list.
Simon Ritter explained that “modularity means we can now build runtime Java images that only contain the modules required for an application or service. This is particularly appropriate with the rise in popularity of micro-services; being able to create a runtime that ships in a container along with the service is very efficient.”
Was it a good idea to introduce the concept of a module into Java as a first-class citizen? As Trisha Gee noted, time will tell how to ecosystem works. However, Nicolai Parlog believes that the future of modularity might be bright — “we will live in a modular ecosystem in a couple of years. That will teach the wider Java community a lot about modularity, just as Java 8 taught us about functional programming.”
If you want to read more about modular Java, check out this interview series.
Don’t miss our Java 10 interview series:
- Part 1: 11 experts weigh in — Local-Variable Type Inference is the biggest new feature in Java 10
- Part 2: Java 10 — What do Java developers want? Projects Amber and Valhalla! When do they want them? When they’re ready!
- Part 3: Java 10 migration: Is it a breeze or a tornado?
- Part 4: Java 10 after 9 is fine; Java 10 after 8 (or earlier) be feared
Back to our interview series!
11 answers: How do you feel about the modular ecosystem? Have you given it a try?
Meet our Java experts
I always thought the practical problems in using OSGi outweighed the benefits. I see the same issues with Java Modularity.
Greg Luck: We already have a modular ecosystem which works great. It is called Maven. What is being done with Java modularity is quite similar to OSGi, the module system originally from IBM.
All modularity systems seek to conquer complexity and to allow easier parallel and at scale development. Which is a good thing. All try to enforce the software principles of Single Responsibility, and Encapsulation. Which are good things.
OSGi and Java Modularity are compile time and runtime modularity enforcement systems. Maven is a dependency modularity system. I always thought the practical problems in using OSGi outweighed the benefits. I see the same issues with Java Modularity.
Hazelcast IMDG moved from a monolith to a modular system by breaking itself into more than 35 Maven modules. Hazelcast Jet was always planned as a modular system with about 10 modules currently. We got 99% of the benefits of modularity with dependency-based modularity.
Simon Ritter: I think the modular ecosystem is a great thing. Java is a compelling platform with a very rich set of libraries (there are over 4,500 classes in the JDK 8 library). This is great because developers don’t need to write their own List interface or Semaphore class but having a single rt.jar file has made the JDK monolithic.
Modularity means we can now build runtime Java images that only contain the modules required for an application or service. This is particularly appropriate with the rise in popularity of micro-services; being able to create a runtime that ships in a container along with the service is very efficient.
Lukas Eder: I’m very happy that it exists for the future of the JDK itself. Java 11 will remove Java EE packages (e.g. JAXB) and CORBA. Finally! Hardly anyone will miss CORBA, and most people will be able to explicitly add JAXB dependencies easily. This makes for a much slimmer JDK, which everyone will profit from.
Of course, there could have been a better module system, but there’s already been enough criticism about that, and I don’t really have an opinion myself.
Trisha Gee: Yes, this is what I was playing with when I migrated my code to Java 9. I haven’t made much use of other people’s modules (other than the JDK modules) because there weren’t many available when I was experimenting. But I think introducing the concept of a module into Java as a first-class citizen is a good idea. Time will tell how the ecosystem works.
Markus Eisele: Modularity isn’t new per se. It has been said before that Java implemented this way too late for it to be effective. It is a tool that developers can use in various ways. I believe it is still too new to call it a success or failure.
My impression is that the module topic got some uptick lately which might be an indicator that developers are actually starting to work with it. I personally found Paul and Sander’s book Java 9 Modularity — Patterns and Practices for Developing Maintainable Applications a great start into the topic.
Marcus Biel: To me, Java modules are a great way to finally achieve a truly clean, modular architecture. I am currently preparing a talk about exactly that matter. Before Java 9, a big problem I saw with layered architectures was that it was easy to define a layer as a theoretical boundary, but as this boundary was not technically enforced, all monolithic architectures inevitably became a big ball of mud.
In that respect, despite all their challenges, microservices had a big advantage – running in different environments, they provide very strong and clear boundaries. But now, with the Java module system, strong and clear boundaries can be maintained without sacrificing the simplicity of a monolithic architecture.
Wayne Citrin: I’m enthusiastic about the modular ecosystem. I particularly like the fact that it’s designed to allow developers to dip their toes in the water, and to adopt it at their own pace. I’ve certainly played with it, and like what I see, but at the moment modularizing our existing product codebase hasn’t been at the top of our list of priorities.
David Heffelfinger: Quite frankly I haven’t had a chance to use modules much, since a lot of my work is still in Java 8, however, I am excited about the possibilities that the module system enables.
For example, traditionally, we’ve had Java EE application servers bundling several implementations of the different Java EE specifications. With the module system, it would be possible to, instead of downloading an application server, just include different implementations of Java EE specification and build a custom application server with our preferred implementations. It would also enable only including the Java EE APIs that are actually needed in our applications. There were some talks about this possibility at the JavaOne conference a couple of years ago, I hope Jakarta EE moves in this direction.
Nicolai Parlog: Well, I’ve dabbled with the module system, but nobody had a chance to enjoy the modular ecosystem because we’re not there yet. There simply aren’t many libraries and frameworks that ship modular JARs yet. And that’s understandable, too, since there’s not much benefit for the project in doing that before they raised their requirements to at least Java 9.
All that said, I strongly believe that we will live in a modular ecosystem in a couple of years. That will teach the wider Java community a lot about modularity, just as Java 8 taught us about functional programming.
Richard Gall: Modular ecosystem needs a lot more time to be used widespread. It delivers value only to large projects that have hundreds of thousands or millions lines of code and developed by many development teams. Smaller projects survive without it and for smaller projects it is more a pain in the … wherever.
What would you like to see in Java 11?
Donald Smith: I’m excited to see Java EE and CORBA modules removed, as well as the opening of more previously closed-source Oracle JDK features like Mission Control. But most of all, I’m excited to get to the point where Oracle’s OpenJDK builds are completely interchangeable with the Oracle JDK!
Greg Luck: Local Variable Inference for Lambda method parameters and Value Types.
Simon Ritter: There are some exciting ideas for changes to the Java syntax, which are grouped under project Amber. Hopefully, some of those (like pattern matching) will make it into JDK 11. I think those would be useful.
Other languages have long ago understood the advantage of making everything an expression.
Lukas Eder: Thus far, the release doesn’t look very exciting yet.
I’m definitely hoping for JEP 326 Raw String Literals to make it. Everyone working with embedded SQL, XML, JSON, Regular Expressions, XSLT, CSV, etc. etc. etc. will greatly profit from this JEP. It’s a very boring feature compared to what the team at Oracle is working on in Amber and Valhalla, I know, but I do think it adds a lot of value without being very intrusive to the language. I’m very happy with the JEP, and I do hope it’ll be part of Java 11.
JEP 325 Switch Expressions is also very cool. Other languages have long ago understood the advantage of making everything an expression. Statements are very boring, procedural constructs. Expressions are much more powerful when implementing a functional-ish programming style. As a SQL person, this is really a very good thing. Since JEP 325 could be implemented as syntax sugar, there might be a good chance for this to make it in Java 11.
There’s much more I’d wish for, of course, but the above certainly is realistic.
Trisha Gee: I’m hoping we get Lambda Leftovers (JEP 302). I’m keen to be able to express in my code when a lambda parameter is intentionally unused.
Markus Eisele: I really don’t have specific wishes for 11 right now. I do believe that there is more potential to support container environments even better. From a developer perspective, I probably would be most excited to see Data Classes in the JDK!
Marcus Biel: Besides pattern matching, I’m eagerly awaiting the addition of value types.
Wayne Citrin: This might be pretty specialized, and not of interest to anyone, but I’d like to see dynamic class generation (that is, class generation at runtime) built into Java. In .NET, there’s a very powerful feature called Reflection.Emit that we use in our .NET-side programming, but it would be nice to have something similar in Java. Right now, we rely on an open-source library called BCEL, which generally works fine, but I think things would be simpler if it were integrated into the Java platform.
David Heffelfinger: Over the years, features that were once popular have been added to Java, some of these features are no longer that popular, however, due to backwards compatibility issues, they can’t really be removed, the classic example for this is CORBA support. CORBA was very popular back in the 1990’s, however, it is seldom used anymore.
Now that the JDK is modular, these legacy features can be removed from Java but can be included as modules if anybody needs them. Some of these legacy features are scheduled to be removed in Java 11, resulting in a leaner Java runtime.
Nicolai Parlog: I’m trusting Oracle’s Java team to drive the language forward at a reasonable speed and I’m happy to see whatever ends up in Java 11.
Richard Gall: Value types on the JVM and fibers to compete with Golang and to have the possibility to effectively compile Swift and Golang for the JVM. Both are great languages.
12 JEPS for Java 10
- (JEP 286) Local-Variable Type Inference: Enhances the Java Language to extend type inference to declarations of local variables with initializers. It introduces var to Java, something that is common in other languages.
- (JEP 296) Consolidate the JDK Forest into a Single Repository: Combine the numerous repositories of the JDK forest into a single repository in order to simplify and streamline development.
- (JEP 204) Garage Collector Interface: Improves the source code isolation of different garbage collectors by introducing a clean garbage collector (GC) interface.
- (JEP 307) Parallel Full GC for G1: Improves G1 worst-case latencies by making the full GC parallel.
- (JEP 301) Application Data-Class Sharing: To improve startup and footprint, this JEP extends the existing Class-Data Sharing (“CDS”) feature to allow application classes to be placed in the shared archive.
- (JEP 312) Thread-Local Handshakes: Introduce a way to execute a callback on threads without performing a global VM safepoint. Makes it both possible and cheap to stop individual threads and not just all threads or none.
- (JEP 313) Remove the Native-Header Generator Tool: Remove the javah tool from the JDK since it has been superseded by superior functionality in javac.
- (JEP 314) Additional Unicode Language-Tag Extensions: Enhances java.util.Locale and related APIs to implement additional Unicode extensions of BCP 47 language tags.
- (JEP 316) Heap Allocation on Alternative Memory Devices: Enables the HotSpot VM to allocate the Java object heap on an alternative memory device, such as an NV-DIMM, specified by the user.
- (JEP 317) Experimental Java-Based JIT Compiler: Enables the Java-based JIT compiler, Graal, to be used as an experimental JIT compiler on the Linux/x64 platform.
- (JEP 319) Root Certificates: Provides a default set of root Certification Authority (CA) certificates in the JDK.
- (JEP 322) Time-Based Release Versioning: Revises the version-string scheme of the Java SE Platform and the JDK, and related versioning information, for present and future time-based release models.