Java Concerns Addressed

Oracle seems to be addressing the biggest concerns with the Java ecosystem -- deterioration of quality (with people not learning from their mistakes) and release fatigue.

When I was at DZone, we were publishing research guides every month. Because DZone had evolved from Java Lobby, Java-related articles received 4X the number of readers as any other topic. However, due to the age of the language and lack of novelty, it was difficult to get as many technology professionals to share their thoughts about Java as other topics.


In 2018, when I asked, "What’s your biggest concern with the current state of the Java ecosystem?", I received contributions from executives from 14 companies. Unlike many topics I researched, there was little unanimity about concerns.


Here's what the respondents told us:


Quality, not learning from mistakes, not evolving to the next stage of software engineering. How to build for resilience over time. Need a well-defined lifecycle. People need to understand the value of the ecosystem and libraries and how they contribute to quality.


Adding modules to Java 9 is a dead feature. Ultimately, Oracle will realize no one switched and stop supporting.


Release fatigue.


Competition from other JVM languages that are simpler. Competition with containers that provide build once run anywhere in a more integrated way.


The Java ecosystem does not take security seriously enough. The applications that run the U.S. economy and many, many other critical apps are written in Java. It’s way too hard to build a secure Java EE application. It requires a massive amount of specialized knowledge and tricky code. Even preventing very well-known vulnerabilities, like SQL injection, XSS, XXE, CSRF, and OGNL injection are far too difficult. I think there’s an opportunity to cement Java as the go-to platform for the next decade if a serious effort were put into making Java security great.


No concerns. People dismiss Java, but I see plenty of opportunities. It still provides a large set of users, the best technology around, with strong features. We are actively trying to make Java smaller and more lightweight for microservices. We’re still innovating to make it smaller for dynamic scaling in the cloud, reconfiguration on the fly, and more Java SE platforms.


As the language ages, at some point, it will no longer be an interesting career path for new engineers. When a new language starts to take over, the whole community of engineers will also start moving to that new, more exciting language and no one will want to work on the old languages. It’s really a people concern because if the pool of talent available to you starts to shrink, then the availability of quality engineers also shrinks.


Adoption of Java 9 and 10. If they are not adopted there will not be sufficient feedback in the feedback loop. If they are integrated into open source projects developers are more likely to adopt.


Not attracting enough younger people into the Java programming career path.  More youth would add to the vibrancy of our ecosystem.  In general, I would like to see greater diversity, especially in the OSS portion of the Java ecosystem. 


Progress has been slow relative to .Net which has evolved more rapidly. Backward compatibility. Closures as a programming construct. Object-oriented versus future-oriented introduced in Java 8 still working to improve. Java 9 and 10 are too little too late.


How will Oracle's role as a steward look in the future? It's really good that they've opened up insights into Java with the OpenJDK and letting go of the JavaEE specs but what are their future plans for Java now that they are becoming a big cloud company?


It's interesting to read these concerns today as Oracle recently released Java 14.


I had the opportunity to discuss these with Aurelio Garcia-Ribeyro, Senior Director of Product Management at Oracle. He shared the challenge of keeping various members of the Java ecosystem happy.


Developers are excited about features and functionality and would like to see a new release every week or two. System administrators want stability. They'd prefer updates or major releases every five years. They want bug and security vulnerability fixes that enable the platform to continue to run continuously. It's impossible to keep both happy.


According to Aurelio, "The six-month release cadence benefits both. With feature releases every six months, we ensure bugs are worked out of features so they are not rushed due to a long-term release cycle. Tools used to lag a long time after releases. Today, users already have access to IntelliJ and Netbeans support for JDK 14."


Java releases continue to be the result of industry-wide development and collaboration involving open review, weekly builds, and extensive collaboration between Oracle engineers and members of the worldwide Java developer community via the OpenJDK Community and the Java Community Process.


Aurelio urges Java developers to become involved in the process of contributing to and enhancing the JDK by going to https://openjdk.java.net/to see what projects are currently being pursued, reviewing those, contributing suggestions, making bug fixes, or downloading a beta.   


Here’s who shared their thoughts for the 2018 research:


Drop Me a Line, Let Me Know What You Think

© 2020 by Tom Smith | ctsmithiii@gmail.com | @ctsmithiii