JAX London Blog

Where will Java go?

Jul 26, 2017

Source: Shutterstock

In this interview, Trisha Gee, part of the JCP Executive Committee, reasons why Java will keep on to coexist with further languages. She also explains the details of JCP deciding to not approve the Public Review Ballot for JSR 376.

Some people seem to believe that Node.js might have a chance at overtaking Java in the near future. Can Java really be dethroned? Why/why not?

I think we’re trying to compare oranges to apples here. Java is a fantastic server-side language, heavily used by enterprises for many reasons, including rock-solid backwards compatibility; cross-platform support (in terms of operating systems); and the very large pool of Java developers (from junior to extremely experienced) that are available to hire.

Node.js is also used in the enterprise environment as well, but not for the same types of applications — we see it much more in startups, used for rapid prototyping and nimble application development (in organizations of all sizes). I personally believe that given the enormous numbers of problems that are/can be solved with technology, there’s plenty of space for both languages, as well as many other languages and frameworks.

But the more reduction in boilerplate we get [..] the more I realize that a language can be succinct without losing all meaning.

This year, Stanford’s famous introductory course for programming dropped Java in favor of JavaScript. What does this say about the relevance and popularity of Java?
Again, this is a case of using the right tool for the job. JavaScript is arguably easier to teach to beginners — it is lower-ceremony, much less boilerplate, and you can use tools like a REPL to get fast feedback. Although Java 9 will have a REPL, overall Java has quite a lot of ceremony (setting up your environment, classpaths, an IDE or editor) plus more boilerplate for typing, all of which gets in the way of learning programming. It’s understandable that anyone teaching coding would want something lightweight and easy to get started.

Java is still being taught at Stanford for more advanced courses, which shows it’s still relevant and important to learn. In particular, some of the things which may at first seem to get in the way, like static typing, a stricter structure (in terms of classes etc) may seem more useful to a developer once they get the hang of how basic coding works.

What did you think of the fact that Java 9 was delayed to September? Do you agree with the JCP Executive Committee’s decision not to approve the Public Review Ballot for JSR 376?
I’m actually a representative for JetBrains on the JCP Executive Committee, so I’m very close to this issue! Personally, I was torn about the decision — I’m keen to see Java 9 released as soon as possible, it feels like we’ve been waiting a long time. But as developers, we really should understand it takes time to get things right, and it’s much better to get feedback from your users (for example, the Executive Committee and the developer communities they represent) and make changes according to that feedback than to push out a solution which may not be right for certain parts of the community.

The very thing that makes Java appealing to many of its users, particularly the large enterprises, is that it’s mature and stable with a commitment to not breaking existing applications — the cost of this is that it takes time to make big changes to the platform because they must be right for the community.

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.

Georges Saab, chairperson of the OpenJDK governing board and vice president of development for the Java Platform Group at Oracle told JAXenter in early June that many developers will probably get started on JDK 9 without modules. How do you feel about the modular ecosystem?
I’ve read a lot about it and also worked a little with it, migrating one of my microservices applications to make use of JPMS. I think making modules a first class citizen of the language is a good thing, and it made me, as a developer, apply good design practices like encapsulation and separation of concerns much more carefully. However, the lack of modularity in Java (the language) has led to others developing their own solutions (the project I just mentioned, for example, used Gradle sub-projects). Modularity in Java 9 is not meant to replace any of these, but it does need to play nicely with them, and that’s part of what they’ve been working hard on.

My overall feeling on Java 9 modularity is that new projects will probably want to investigate whether using JPMS will give them any benefits, but most existing large code bases will not be migrated to use it (indeed, they might not see any benefit from it unless they were already going to re-architect into smaller pieces, for example for migrating from a monolith to microservices).

The difficult part, in my opinion, falls upon the developers of library code, those open source jar files we all use daily. Some developers will want the libraries they depend upon to be true modular jar files, not automatic modules, which puts pressure on library developers to migrate their code. There are benefits to doing this, especially for library developers, for example, they can hide away implementation details and internal APIs (the very thing Jigsaw was designed to do), but it will be non-trivial for many to do this migration and the benefits need to outweigh the costs.

Top 20 Java Influencer Trisha Gee

What is the most important misconception about Java 9? How about Jigsaw?
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.

What would you like to see in Java 10?
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.

Behind the Tracks

Software Architecture & Design
Software innovation & more
Microservices
Architecture structure & more
Agile & Communication
Methodologies & more
DevOps & Continuous Delivery
Delivery Pipelines, Testing & more
Big Data & Machine Learning
Saving, processing & more