Why Linux Distributions Should Stop Caring About Java Packages

All Linux distributions have their own package management and their main goal is to provide stable, secure and working software to end users. 

This almost always works well .. Almost .. Unless you are a Java developer who needs many libraries and different server softwares.

The added value by package maintainers becomes ultimately useless. Because:

  • Java ecosystem is only loosely connected to the underlying operating system and its traditions. Operating system is no more than a container. There is no gain to obey standards of the host system.
  •  Most of the time, people prefer to have all Java stuff under same directory, which is irrelevant to other host files, like /opt .. 
  • Developers follow the release of new versions so closely that package maintainers can not update fast enough. Plus, package repositories include only a small subset of all available libraries
  • Developers use multiple versions of libraries in different modules. Package managers by default present you the latest version. Build tools are just simpler to work this way.
  • In most places dependencies, installation, deployment etc are also managed by Maven/Ant or sbt in case of Scala without relying on anything else. 
  • In many places, developers use combination of Linux, Windows, OSX machines that also rely on build management tools, not OS packages.
  • Continuous integration systems also work with build management tools and they also don’t care about packages provided by distribution.


Efficiency, ease of use, flexibility and general availability of native build tools make distribution packages useless for most businesses. So, why do distributions spend huge amount of effort on this eventhough it is just not possible to make people’s life better ? When did you last use deb packages of Spring framework rather than just defining them in your pom file ?
 

No EMACS For Java

There is not much application software like Emacs that has roots from decades ago and still regarded as one of the best, if not the best. That well deserved fame leads many developers to use it for Java. What I will repeat after James Gosling is, “just don’t”. As your project scope widens, you will be tackled more by the missing features.

First of all, Emacs does not understand the language by itself. It is a very powerful editor environment but it relies on addons to behave as you wish. These addons know the language and try to understand what you are doing. They basically tell Emacs what to do. So the editors capability to be powerful IDE, becomes limited to the capability of the addon. 

Currently there two reasonable addons to develop Java on Emacs:

  1. JDEE:
  • The most feature rich Emacs addon. However, the development status is almost frozen. Debian has no package in unstable and testing anymore. Mailing list activity is very low. Even the official website still refers to Sun as the trademark owner of Java.
  • It relies on BeanShell to understand what you are trying to do. BeanShell is a dead project which does not even support Java 5.
  • malabar-mode:
  • Developed by Espen Wiborg after some frustration due to JDEE. Though it is much better and modern than JDEE (support for Groovy console, unit tests, maven etc) it still lacks the the important points that I will describe. Plus, Espen has no time to maintain anymore and he is using Intellij IDEA for himself.

Before getting crucified, I would like to tell what you will miss when using those two:

  • Perfect code navigation: As I mentioned, Emacs does not understand what you are trying to do. Java IDEs on the contrary, does well. They understand what an interface, inheritance, EJB, annotation, xyz framework, exception etc is .. They can correctly guide you in all those features and frameworks.
     
  • Better refactoring: Since Java IDEs undertand the language, they can provide much detailed refactoring options. Note that eventhough refactoring is a text replacement and file operation, the editor should be able to understand the language constructs to be able to provide more options.
     
  • Integration with crucials like maven, application servers, frameworks etc: 
     
  • Better debugging: Java IDEs provide better debugging interfaces with multiple windows, easy runtime evaluations with code complete in all those runtime operations. 
     
  • Better diff: Helpers in diff windows are easier to use because visualization of them are better. When it comess to a diff, visualization is the most important thing to be able to navigate and find what you are looking for  
     
  • Multithreaded editor: Emacs is a single process that communicates with external tools but Java IDEs are multithreaded UI applications that all threads works harmonously. So the editor can check your typing, do suggestions, see if any files changes, update maven dependencies, colorize, notify you about updates from ticket system etc.
     
  • Intentions and inspections: You may know the language well. You may know many frameworks as well. But unless you are extremely knowledgable in all those you use, you will write suboptimal code that may even end up faults. Intentions are simple but effective fixes to code like importing a class static instead of inline access. Inspections are suggestions from IDE so that you will be saved from mostly runtime issues like ineffective comparisons, mission serialization version in a serializable class and many more
     
  • SCM visualization: There is nothing wrong with command line scm tools but sometimes GUI versions are more useful and time saving, especially when you need visualization of branching history of a complex tree
     
  • Group reviews: It is not difficult to setup collaborative code editing with Emacs, but the things that you will mostly need are already there with less effort. With those features, peers can just see each others versions, work on the same file, diff them, talk with each other.
These features are very important time savers when you are working in projects with tens of different maven modules, few heavy frameworks, tens of thousands of lines. 

Still, there are things that I miss a lot from Emacs. The most important one is to be able to easily define a new command and keystrokes for my own needs. Java IDEs support Emacs keymap and they let users assign keys for all functions accessible from GUI. However, you can not easily define a keystroke so that -for example- the editor will search only the files in test scope with class names starting Mock*. (I don’t find macros easy enough) So eventhough virtually all functions are accessible from keyboard, there will always be some need to use mouse, unfortunately. 

The next is the contrast color themes that make my eyes happy. Java IDEs have various contrast themes but they are never as complete as Emacs alternatives. (As an example, consider that the code window is colored but a some popups or windows are still grey/white. Terrible experience ..)

This is written by a long time Emacs user who still uses Emacs for things other Java/Scala. For the latter, I prefer Intellij IDEA.