Why Java Sucks

Of course this list here isn't just by me and you will find it elsewhere, but i guess its still entertaining. Guess you will find a comparable list also in your local scala and groovy guide.

A first comment: This list is not intended to say "the designers of java were wrong. Instead there are some decisions which arguably proved false in the aftermath, some plain language quirks, and some fields were the language is definitely missing a thing or two.

Part 1 - Not so nice Ideas (or: the designer was wrong)
- Primitives are not Objects.
This is just the problem with the fact that java Objects are all references, while the rest are valuetypes. Guess they could have gotten around this problem which causes bad effienciency and übercrappy syntax in pre java 5 by just making a virtual "base object" which is not instanciable but from which the "reference object" inherits as well as the virtual final "value objects" (int, char, ...). The only restriction would have been the fact that creating arrays of "base object" would have been impossible (as it has no defined length and access method). Of course this is just an idea where billions of other might have been just as well.
- Checked Exceptions
This is not really a rant, but a saddening nod. They had been a nice idea, which did not work out, as the designer of C# pointed out when being asked why he excluded them. I strongly support his position, although i really like them in the rare situations where they are used correctly. Nowadays, however, java has annotations which could provide exactly the same feature. Also, the way how subclassed had to deal with exceptions when overriding methods was not very elegant.
- Generics
This is a biased thing - Now java has generics, but no reification, as C# has. On the one hand, this really sucks, on the other hand this makes way for individual implementations of this feature in other languages which run on the jvm, like scala. This might make up for the performance loss, and the advantage of analysing the current generic class like in C# is not real an advantage (to me, its just the same antipattern as most instanceof checks are). There is however STILL ONE BIG BIG DOWNSIDE, and you know it. Arrays again?
- Method Overloading
While Operator overloading is not possible, method overloading is. I regret this, deeply, as it was one of the features that was nearly squeezed out. However, it did not. I guess that a lot of people will tell me now how important method overloading is and that is able to design elegant API's with methods like print, or the common methods of class Array. Ok, there are cleary some places where this method would be very useful.
The problem is imho, that method overloading has two problem domains: First, it is not possible to overload also the return value (which is a bit inconsistent, as this forces many getter methods for collections to explicitly define individual return types). And second, mostly its just used for default parameters, which could also be defined much more elegant - IF java had them...
Also, theres a gazillion of problems with method overloading which could result to the caller of the method to do crazy stuff like actually typecasting an object to get the right method, and it could be quite confusing. Also, reflection is much more complicated, as the method name alone is not sufficient. This alone could also result in even more problems if java had default parameters, as parameter lists might then even be more complicated to deal with.
In short: Its a nice feature with not-so-nice interactions and problems, and its crap that is impossible with return values.

Part 2 - Plain Crap
- Arrays and Collections
What are arrays? A kind of strange pseudoclass for containing multiple values (which is at least typecastfree in java 4). I like arrays (j4), but its still strange that they have no kinds of convienience methods directly attached to them to convert them to their collection correspond (the list) and vice versa. To me more exactly: The folks at sun should have just put a litte thought into how to integrate collections and list. I know there are static convenience methods, but this is OO, right?
- Exception hierarchy
Checked exceptions would IMHO a bit less messed up, when they were not so strangely inherited. To be exactly, the problem is the (misleading named) RuntimeException, which inherits from Exception. Not intuitively and strange, and it also makes catch Exception impossible for almost all cases without a seperate catch RuntimeException. This is clearly a very early design problem which was impossible to fix later.
- Limited-to-useless type inference
Its nice and such that java is statically typed, but its really dumb that there is no way to loosen the declaration restriction for local (thereby harmless) variables, to make code more beautiful: It would be completely sufficiently to omit the type of local variables in their declaration (using a keyword like var instead) as they type could be automatically read out by the compiler during the first initialization. This would enable this like declaring anymous inner classes and use their methods at least in local contexts, (see the scala blogs and tutorials about this problem). Also, the main use of this would be to make code less verbose:

var a = "hello";
String b = "hello";
var c = new FileOutputStream("hi")
FileOutputStream d = new ....

and so on. It also omits the usual question, wether the List or ArrayList base type should be used, as the compiler knows anyway. This is not even a feature which they could not easily introduce, i guess they just do not want to..


Part 3 - Missing features
- No Operator overload
Ok, it prevented stupid people doing stupid things, horray. It also prevented intelligent people doing perfectly credible things. Just think about how ugly it is in java to compare Strings for equal. Note that i am not talking about full operator overload like C++ has (not talking of Scala), i would have just appreciated sugar like == deriving from equals and the like. At least the == Operator is unfixable (and with him the core java ugliness of equals), but some others like + - * / are still possible to allow in future versions.
- Weak case selection
Just another one which directs into the face of operator overloading, a weak syntax. Just as it is not possible to use == naturally on strings, it isnt as well to use it in Case statements, thereby encougaring ugly int comparisons and nested-if loops. At least Java 5 enums proved a small solution here. I still prefer QBasic, my first programming language, here...
- No Closures
Inner classes were designed as a way to show that a pure object oriented language do not need function pointers and the like, as inner classes are a convienent way to circumenvent this problem. The desingers couldn't have been more wrong, although the classes were a noble approach to stay pure OO - if there were just a syntax construct to turn them into closures without 5 lines of overhead, i would even agree...

This is just a small list, maybe I will post some more in the future. This list is for java 5 of course. Every half-minded human should now that java 1.1-1.4 (which i have to deal with at work) are just disgusting.