Interview series with Java influencers — Part 3

Java 9 misconceptions & Java 10 wish list: A tell-it-all interview with Java influencers

Gabriela Motroc
Java 9
© Shutterstock / ALEX S

Java 9’s due date is coming but there are still some things we need to understand before its arrival. In the last part of our interview series, Java influencers bust some Java 9 misconceptions and reveal what they’d like to see in Java 10.

It’s time to bust those Java 9 misconceptions

Java 9 will arrive in September even if we’re ready for it or not but there are still some things we need to understand before its arrival. We need to stop thinking that Maven doesn’t work on Java 9 and that Java 9 cannot be used without Jigsaw. There are at least 11 misconceptions that we’ll bust in the last part of our interview series but let’s not spoil all the fun from the very beginning.

One last remark on our imminent modular future: The modular ecosystem is not everyone’s cup of tea and, according to some Java influencers, the community is unlikely to rely on the new module features immediately. Is the world ready for modularity? It depends on whom you ask. Should developers dive into modularity as soon as Java 9 is out? Read on to find out.


Interview series recap

In this 3-part interview series, 11 Java influencers weigh in on Java’s popularity, talk about the modular ecosystem and reveal what’s on their wish list for Java 10.

In the first part of this interview series, we invited our Java influencers to talk about the possibility that Node.js might overtake Java and comment on Stanford’s decision to teach its famous introductory course in Javascript instead of Java. The second part of the interview series was all about Java 9: we dissected the JCP Executive Committee’s decision not to approve the Public Review Ballot for JSR 376 [Reconsideration Ballot has been approved] and we talked about the modular ecosystem. 

In the final part of the interview series, we talk about the biggest misconceptions about Java 9 and JSR 376. Are you eager to find out what our influencers want to see in Java 10?    


11 answers: What is the most important misconception about Java 9?

Meet the Influencers

Markus Eisele is the Head of Developer Advocacy at Lightbend and a Java Champion.

Mario Fusco is a senior software engineer at Red Hat working on Drools, the JBoss rule engine and a Java Champion.

Marcus Biel is a Software Craftsman, JCP member and CleanCode Evangelist.

Lukas Eder is the founder and head of R&D at Data Geekery GmbH, the company behind jOOQ and a Java Champion.

Trisha Gee is a Developer Advocate at JetBrains, a key member of the London Java Community and a Java Champion.

Vlad Mihalcea is CEO at Hypersistence and author of High-Performance Java Persistence.

Jake Wharton is an Android Engineer at Square Inc.

Thorsten Heller is CEO at greenbird Integration Technology providing Grid Intelligence Platform Metercloud

Baruch Sadogursky is the Developer Advocate of JFrog.

Quentin Adam is the CEO of Clever Cloud.

Bruno Borges is Oracle’s ‎Principal Product Manager responsible for Developer Engagement on Oracle Cloud Platform, Java, and related technologies for application development.

Markus Eisele: I have two favorites. One is the inclusion of the Reactive Streams specification. I’ve seen the first blog posts about how to use it in your own applications. It shouldn’t be used directly but together with a reference implementation, for example, Akka Streams. Here is one of the better blog posts that I know giving an introduction to it.

The second one is Jigsaw or, better said, the Java Platform Module System. There are many aspects that will cause a lot of confusion at best and a module hell at worst. Stephen Colebourne published three good articles about it that try to clear a little of the confusion. He talks about module naming, automatic modules and how modules aren’t artifacts.

The misconception is that upgrading to Java 9 or migrating to Jigsaw is more expensive and riskier than not doing it.

Marcus Biel: As with all changes, the misconception is that upgrading to Java 9 or migrating to Jigsaw is more expensive and riskier than not doing it. Every upgrade involves a risk, it’s true, but sooner or later you will have to upgrade anyway.

The sooner you upgrade, the better because the sooner you can benefit from all its advantages. In the case of Jigsaw, you’ll benefit from the advantage of proper encapsulation on module level. Jigsaw will allow us to build modular systems, with a much clearer, more precise structure, which will be understood much faster by new developers joining the team or by business people.

SEE ALSO: Java is alive and well, thank you, and is just as relevant as ever

Trisha Gee: Many people don’t realize you can use Java 9 and all its shiny new features WITHOUT using Jigsaw, i.e. you can use Java 9 very happily without migrating any of your code. There are some things which have changed in Java 9 (e.g. hiding away internal APIs) but theoretically, if your application was doing all the right things to begin with, there should be no problem compiling and running with Java 9.

Modularity feels like impending doom to a lot of tooling authors.

Vlad Mihalcea: Jigsaw, for sure.

Jake Wharton: I would say modularity feels like impending doom to a lot of tooling authors. The migration from classpath to modulepath doesn’t have to be one that’s an overnight switch. There are sufficient flags and options that should allow a migration at a pace that’s comfortable for your organization. Despite this, however, it’s not something that should be indefinitely deferred.

Hopefully, the potential benefits will be enough of a carrot to incentivize migration. That is, at least until Java 10 starts using the stick and removes some of these flags and options.

Thorsten Heller: For me, there are two “MOST” important misconceptions: The Maven discussion (meaning that Maven etc. won’t work) and the need to port all code over to the new module system.

Baruch Sadogursky: The most important misconception is that the industry massively rejected Jigsaw and it was removed from Java 9. The industry forced a dialogue that ended up in a good compromise that kept Jigsaw in Java 9 but in a more developer-friendly way.

Quentin Adam: The way java.lang.reflect is de facto deprecated is a mistake because it will create a lot of errors and frustration. Lots of developers use it using frameworks and do not know how it works, and pedagogy will be needed. Interesting to see how it will work.

Bruno Borges: For real, it is the one that developers would have to rewrite their programs and organize their packages as modules. No one is required to make changes!


What would you like to see in Java 10?

Markus Eisele: Developer productivity would be my biggest interest. Further improve Lambdas, better streams support in all APIs (e.g. JDBC), and there are a couple of interesting draft JEPs that I would like to see.

SEE ALSO: Java is on a slippery slope, Tiobe index shows

Mario Fusco: I’m really excited about everything that is planned in Project Valhalla. Value types will be for sure the most relevant improvement, and generic specialization will allow users to avoid tons of unnecessary boxing/unboxing operations that are very time-consuming. Probably the usefulness of reified generics will be a bit more limited, but they will help a lot of programmers like me who work on the development of frameworks and libraries that in general require a heavier use of reflections. 

Finally, I recently saw an email from Brian Goetz that announced the possibility of introducing pattern matching in Java. This will help limit the use (and abuse) of the visitor pattern. However, any change that could increase the functional programming capabilities of Java is very welcome for me.

Removing features and revising wrong decisions of the past is much more important to me than adding new features.

Marcus Biel: Well, if I were granted one wish —

Removing features and revising wrong decisions of the past is much more important to me than adding new features.

I would love to see some new changes that would not be backward compatible. For instance, I would love to see Checked Exceptions removed, but this is not going to happen too soon.

Anyway, to list a few new features that would be nice to see with Java 10:

  • Pattern Patching
  • Value Objects
  • Multiline Strings
  • List<int>

Lukas Eder: Everything that is being discussed in the context of project Valhalla and other projects, including:

  • Array 2.0
  • Value types
  • Generic specialization
  • ADT and pattern matching (I’m also personally hoping for first class union and intersection types)
  • Declaration site variance on generics
  • Generic enums
  • Named and defaulted parameters

Oh, and if I could get those multi line strings in Java, as a SQL person, I’d be extremely delighted! I’d also love to see other sugar such as:

  • Data classes
  • Flow sensitive typing (no need to cast inside of an “if-instanceof” block)
  • Destructuring of Map entries and other types
  • List and Map access literals
  • Much more powerful Stream API with many new features
  • Type aliases
  • Local methods
  • Local imports

Some of you may have noticed that these features would have been stolen from languages like Kotlin or Ceylon.

Trisha Gee: I would like to see Local-Variable Type Inference. For a long time, I was one of those long-term Java programmers who didn’t care about all the boilerplate because it becomes invisible to you over time. But the more reduction in boilerplate we get (e.g. lambda expressions, method references, and the new Collections factory methods) the more I realize that a language can be succinct without losing all meaning.

From a performance point of view, I would really like to see something along the lines of Value Types.  I know there’s some discussion about what to do, how to do it, and what purpose it serves, but I think these discussions are really important, and that something like this can move Java even further forward in terms of performance.

Vlad Mihalcea: Multi-line Strings.

Jake Wharton: Aside from all the fancy things that I think we’ll get such as value types, generics over primitives, and better pattern matching, I would really love to see support for partial classes (similar to what C# provides). As an author of a few annotation processors, the inability to modify classes is an understandable but limiting restriction. Partial classes would allow a class author to define a contract that must be fulfilled by one or more other partial classes for the same type. This would allow annotation processors to automatically fill in the gaps of these classes rather than being restricted to generating a subclass or delegate as we do today.

Thorsten Heller: More focus on “built-in” DevOps support in the core Java Platform.

Baruch Sadogursky: I am waiting for project Valhalla. It will really change the way we write Java.

Quentin Adam: Pattern matching and Value class, but I’m a functional developer, so I’m biased.

Bruno Borges: I actually have two ERs filled on OpenJDK’s JIRA that I’d like to see implemented.

One is JDK-8149423, about having a fingerprint of source code in the bytecode, so IDEs could validate whether a source code opened in the editor is really the one being debugged. Did it ever happen to you — debugging a line and seeing the breakpoint jump over to an empty line? Yeah, I hate that. Because source code is not the one in the JVM memory.

The other one is minor: an enhancement to the JAR tool to restore file permissions (JDK-8149423). Anyways, there are lots of proposals for Java 10, and they are all great, but these two are my ideas… :-)

If you’d like to meet the top Java movers and shakers, join us in London in October.


Gabriela Motroc
Gabriela Motroc was editor of and JAX Magazine. Before working at Software & Support Media Group, she studied International Communication Management at the Hague University of Applied Sciences.

Inline Feedbacks
View all comments