What Java Did Right

If you read my blog you probably know that I am no fan of Java. However, Java is a popular language, and because I believe that people are rational that means that it must have some advantages. Obviously Java is not a hacker’s language, nor is it wonderful for quick solutions, or elegant solutions for that matter. What Java does do right is team programming, i.e. any project with three or more people working on it.

First let’s consider Java’s use of types, specifically the fact that they are everywhere. Not a single argument or variable declaration or exception may have its type omitted, even when the compiler could have inferred that information from other sources. This practice is highly cumbersome when you are programming on your own, after all you know what type of arguments your functions expect, because you wrote them, but when looking at someone else’s code it can be salvation itself. Sure your teammates may name their variables inscrutably, but at least knowing the type immediately gives you some hint of what they do. The same argument can be made about Java’s exception handling. Yes it seems silly for the single programmer to declare exactly which exceptions can be thrown, but once again this kind of information is necessary when using someone else’s code. You don’t want to examine the body of the function for throw statements, you want that information in the function declaration where you can see it, and Java gives you this.

Java’s excessive object orientation can also be seen as feature that aids the programming team work together. For example public and private are meaningless in a single programmer’s project, but when working with a team they let you notify your coworkers which functions should be called, and more importantly they provide an implicit promise that you won’t be changing the signature of the public functions. Object oriented programming as a whole also makes it easier to break up who is responsible for what functionality, since the notion of an object that can do certain things is fairly intuitive. Finally, objects, used properly (not singletons), allow programmers working on different parts of the project to both use your code without interfering with each other’s state. For example if you simply wrote a package that exported some methods then it is possible that when the code that programmer A wrote properly using your package and the code that programmer B wrote properly using your package happen to step on each other’s toes when put together (for example the package methods store data in some global variables). On the other hand if your code was an object then A and B would each create their own instances of the object, and there would be no need to worry about shared state.

Now here is the problem: while these features might be nice for teams we want a language that is friendly to the lone coder, so can a language be easy to use in a team project without saddling us with excessive typing and object orientation? Unfortunately I think that no language can, which leaves us with only two options: be able to document everything in the project plan (impossible), or create better IDEs. Ideally the IDE should be able to display visually all the information that Java makes you declare explicitly. For example if the compiler figures out types by inference the IDE should figure them out as well, and display that information where it is useful. Yes I know this doesn’t fix the need for published/public/private functions or objects, I am still thinking about those.

Feel free to chime in with your own ideas.