DZone Research: The Problems With Java

To gather insights on the current and future state of the Java ecosystem, we talked to executives from 14 companies. We began by asking, "What are the most common problems with the Java ecosystem today?" Here's what the respondents told us:

Verbosity

• It’s a bit verbose. Other languages are simpler. A lot of libraries – hard to choose which one. The JDK is complete but there are a lot of dependencies. 
• The most common complaint about Java is that it tends to be long-winded, meaning you have to type more characters to get what you want done than some other, more modern languages. That’s something newer languages have been trying to tackle, with the goal of trying to get the quality, features, and power of Java without needing to do quite as much typing. The ability to write code faster is one of the biggest reasons that some people prefer languages that are actually worse languages when compared at side-by-side with Java. 
• Java developers have no problems with Java. Those on the outside will complain that it’s too verbose. The Java 9 upgrade is not seamless, you must add dependencies to adopt. It will not be supported long term. Java 10 will be out this month and may result in a lot of people skipping the Java 9 upgrade. 
• Java itself is verbose but there are alternatives like Kotlin, Scala, and project Lombok.

Nothing

• I think the ecosystem is pretty healthy right now, relatively speaking. A benevolent dictator and an engaged community is probably the best mix. Feels like good energy stemming from more frequent releases. 
• If you had asked me this same question one year ago, I would have suggested that the uncertainty of Oracle’s intentions around Java EE was a substantial problem.   As previously mentioned, Java dominates the enterprise.  While we did have folks like IBM, Tomitribe, Red Hat, Payara and others working to create MicroProfile, it was unclear what would happen if Oracle remained neutral. Now, we have Jakarta EE at Eclipse and we are open for innovation yet again.

Other

• Software engineering quality is degrading with less care and pride of workmanship. No real engineering processes. No one is nailing down well-known methodologies.
• It can be hard to consume all that’s contained in a release every six months.
• 1) The Maven repository was revolutionary in its time as a central repository for Java libraries, but it is starting to show its age, especially compared with the npm library. Compare the simplicity of searching for quality libraries in the npm libraries, which includes a great search tool, a way to grade the quality of a library, and a culture of readmes that help you figure out what the library is all about at a glance. 2) Java libraries tend to be too large and try to include as much stuff as possible in a library, with, in the best case, huge documentation that is very difficult to comprehend due to the number of things to understand, and to the worst case where all you get is a huge Javadoc. Compare and contrast that with the JS library ecosystem that tends to favor small libraries, a “pick and choose” methodology, which enables easy understanding of a library. 3) The slowness of the evolution of the language is a big advantage, but because it was too slow, it has driven many developers, especially thought leaders, away from the language.
• Governance of the JVM. Eclipse is a good steward of open source. The rate of innovation into the JVM is stalling. Java 9 represents the last attempt to push technology into the platform. I’m not sure where the product roadmap goes after that. The language goes in circles. Every generation needs their own language. It's nicer to be part of a vibrant ecosystem. Java’s guarantee of compatibility gives you a wide variety of languages to choose from.
• Participation and engagement, growing real-world developer interest. We want to hear from every user, not just architects. We encourage developers to contribute as a group. The Brazilian User Groups have adopted the JSR concept to forward feedback as a group. To continue the momentum, we have an open JDK adoption group.
• The freedom can sometimes become a curse. In languages such as .Net where you are more "within boundaries" it is easier to not make the wrong decisions. The different permutations of what dependencies you can use together can make your system become an unproven snowflake. There's also the notion of Java being an "old and grumpy" language. Though I don't agree with this notion the rumor can be a bit hurtful. Hopefully, this will change with the new release cadence.
• It lags behind because it’s used by large enterprises. With slowness comes stability. It lacks some of the niceties of other languages; however, it provides quick wins with fast coding.
• The main problem will be release fatigue. The increase in cadence means developers have to keep up with new versions of Java. So much going on in open source community it’s hard to get a handle on new APIs, components, projects. Every time you try to learn something new you’re placing a bet with your mindshare on whether or not it will be relevant in a couple of years. 

Here’s who we spoke to: