Self-described “Java geek” nfrankel writes:
At the beginning of 2019, I wrote about the state of Java modularization. I took a sample of widespread libraries, and for each of them, I checked whether:
– It supports the module system i.e. it provides an automatic module name in the manifest
– It’s a full-fledged module i.e. it provides a module-info
The results were interesting. 14 out of those 29 libraries supported the module system, while 2 were modules in their own right.
Nearly 2 years later, and with Java 16 looming around the corner, it’s time to update the report. I kept the same libraries and added Hazelcast and Hazelcast Jet. I’ve checked the latest version…
Three full years after that release, 10 out of 31 libraries still don’t provide a module-compatible JAR. Granted, 3 of them didn’t release a new version in the meantime. That’s still 7 libraries that didn’t add a simple line of text in their MANIFEST.MF
Meanwhile, long-time Slashdot reader AirHog argues that “Java is in a war for the browser. Can it regain the place it once held in its heyday?”
How can Java increase its relevance? How can Java win back client-side developers? How can Java prevent other technologies from leveraging front-end dominance to win the back-end, like Java once did to other technologies?
To win the war, Java needs a strong client-side option. One that lets developers make modern web applications using Java code. One that leverages web technologies. One that supports components. One that builds quickly. One that produces fast-downloading, high performance, 100-Lighthouse-scoring apps. One that plays nicely with other JVM languages. What does Java need?