JAX London Blog

JAX London Blog

JAX London, 09-12 October 2017
The Conference for JAVA & Software Innovation

Aug 10, 2017

Modularity in Java? Blessing or curse?

Source: Shutterstock

In this interview, Jake Wharton discusses the idea that modularity feels like impending doom to a lot of tooling authors. In his opinion, there are sufficient flags and options that should allow a migration at a pace that’s comfortable for the organization.

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?

The JavaScript community has been backing their way into a lot of the things that make Java really dominant: static typing, stronger tooling, and a breadth and depth of the library ecosystem. While I think this is a step in the right direction, there’s still a lot of work to be done in all three areas to truly supplant Java in the long-term.

 

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?

I don’t think this reflects badly on Java but instead positively on JavaScript. It’s a language which is much more forgiving than Java in its dynamic typing and primitives which also doesn’t require a compilation step to execute. Programming introduction should focus on fundamentals like critical thinking and problem solving and for that you don’t need the benefits Java affords.

Modularity is an important long-term concept for many reasons. 

 

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?

As this JSR has now passed in the second vote, I’m fine with the first vote being used to check Oracle and their decisions around modules. It’s important to remember that there are a lot of highly invested parties in the platform who have explored the modularity space before.

While the platform shouldn’t be beholden to their decisions, it also shouldn’t be ignorant of all their work. Ultimately, I think we’ll get a better product in the end as a result of the changes made between the first and second votes.

The migration from classpath to modulepath doesn’t have to be one that’s an overnight switch. 

 

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?

Modularity is an important long-term concept for many reasons. As a library author, the enhanced encapsulation is extremely appealing, but it will take many years before its use becomes widespread. It’s also an essential tool for building custom, tiny JVMs onto which you can launch your application. As container use spreads, minimizing the resource impact of the JVM required to run our applications means higher density deployments and reduced infrastructure costs.

Top 20 Java Influencer Jake Wharton

 

What is the most important misconception about Java 9?

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.

 

What would you like to see in Java 10?

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.

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