Jan Bessai Publications Students Philosophy Posts ContactJava: An ecosystem worth billions with IDEs in peril ---------------------------------------------------- There are currently 2.5 working options for developing Java: JetBrains/IntelliJ and Eclipse. For a blast from the past (0.5) technically NetBeans is still around and receiving regular releases. But surely there must be an LSP for one of the most popular languages on the planet? Well, there are two: Eclipse JDT [1] and George W. Fraser's Java Language Server [2] based on the Java compiler API. Imagine the AI bubble harms JetBrains and they get bought by Evil/Equity Corp. Think of a scenario similar to Borland and Delphi: slow rot with price gouging. What are we left with? I argue that a multi-billion-dollar ecosystem will be stranded and slowly fade into COBOL territory. A prediction that has hovered over Java for years now - and so far has been avoided as a kind of self-defeating prophecy, where the prophecy has inspired action to avoid the outcome. So what is the problem? ----------------------- Eclipse is stagnant: side projects over side projects, and a gigantic code base with complexities so vast, that only a few experts (at least in JDT space [3]) are left to understand them. I've witnessed a light version of this firsthand at my last workplace with XText -- an Eclipse DSL framework shouldered by more or less two to three people [4]. They are doing the best they can, but you are in for a nightmare trying to learn/use it nowadays. Much of this nightmare is tied to the complex inner workings of Eclipse, with its Equinox/OSGi plugins, EMF EProxy instances, odd build logic (don't get me started on Maven T(Ps)ycho), and aspect(J[5])-oriented contraptions. My guess is that the decline of Eclipse will be propelled by not just IBM cutting costs, but also by European small- and medium-sized company failures, mostly due to a declining car industry (cross-check the main sources of revenue for the experts working on Eclipse technology). NetBeans is stuck in the past [6]: ant builds, Swing and a code base that hard-clones dependencies. Its contributor base [7] seems a bit more healthy, but I have my doubts it can keep up with modernizing. The Java Language Server project also has minimal contributions [8] and its scope (especially regarding build system integration) is far too limited to be useful for complex (especially old) enterprise-level projects. Why is it so hard? ------------------ Unlike modern languages, Java had its build systems as an afterthought. Language servers were not a thing when designing Java or Ant, Maven, Gradle (, or whatever Eclipse builds do). There is a fractured landscape of new and old projects, using a slew of complex ways to build stuff and to interfere with builds and execution. Additionally, the bigger Java Frameworks, mainly Spring, require out-of-compile-time stuff (aspects, reflection, annotations, property loading) to function, which is hard to use without proper custom IDE integrations built around them. Older projects have cruft of their own, like JavaEE XML and JSF horrors, where only a proper IDE will keep you productive. Not to mention anything built around OSGi technology. Just upgrading the compiler to have an API [9] is a start, but won't realistically cut it. Any Suggestions? ---------------- To be clear: the contributors I mentioned [3, 4, 5, 7, 8] are doing valuable work, and I also want to say that each of the projects I wrote about has / had its purpose and its time: design decisions had to be explored, and insights had to come from doing things (sometimes wrong). What I'd do now if I was a big company relying on Java is to minimize risk with a two prone strategy: 1) Support the people mentioned above and make sure they are well-paid, not too overworked, and have enough staff to transfer knowledge too when they eventually do something else. 2) Build something new and adopt what we learned from Rust, Go, .NET, and others. Push the technology forward (maybe leave some of the older stuff to be supported by what you do in 1) ): Deal with dependencies, a proper language server, the need for runtime magic, etc and slowly update your in-house codebases to work with the new modern IDEs. I know that this type of work is not sexy and hard to sell to your boards, because it does not (or only tangentially) involve any AI or other current hype. But I also think that remaining vulnerable to a slow death of IDEs is a risk no one should/needs to take. We are still at a point where required investments are minimal compared to other things going on. I'd guess that 100 (order of magnitude) full time jobs could be created and would be more than enough to greatly increase resiliency of a multi-billion-dollar ecosystem. Let total annual costs per job be $200k + some overhead and you end up with a fraction of what is required for a single AI data center [10]. If governments were reasonable (ex falso quodlibet) they would chip in and make this tax deductible if it is open source, since - at least in Europe - a ton of government IT infrastructure is built on Java. Also so many people have high (tax) paying jobs that depend on Java technology that it would be a very healthy bargain for them - if they keep out of micro managing/regulating developments to death. [1]: https://github.com/eclipse-jdtls/eclipse.jdt.ls [2]: https://github.com/georgewfraser/java-language-server [3]: https://github.com/eclipse-jdt/eclipse.jdt.core/graphs/contributors [4]: https://github.com/eclipse-xtext/xtext/graphs/contributors [5]: https://github.com/eclipse-aspectj/aspectj/graphs/contributors [6]: https://github.com/apache/netbeans/tree/master [7]: https://github.com/apache/netbeans/graphs/contributors [8]: https://github.com/georgewfraser/java-language-server/graphs/contributors [9]: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.compiler/module-summary.html [10]: https://www.alpha-matica.com/post/deconstructing-the-data-center-a-look-at-the-cost-structure-1