"Java Sucks" revisited
OverviewAn interesting document on Java's short comings (from C developer's perspective) was written some time ago (about 2000? ) but many of the arguments issues are as true (or not) today as they were ten years ago. The original Java Sucks posting.
Review of short comings
Java doesn't have free().The author lists this as a benefit and 99% of the time is a win. There are times when not having it is a downside, when you wish escape analysis would eliminate, recycle or free immediately an object you know isn't needed any more (IMHO the JIT / javac should be able to work it out in theory)
lexically scoped local functionsThe closest Java has is anonymous methods. This is a poor cousin to Closures (coming in Java 8), but it can be made to do the same thing.
No macro systemMany of the useful tricks you can do with macros, Java can do for you dynamically. Not needing a macro system is an asset because you don't need to know when Java will give you the same optimisations. There is an application start up cost that macros don't have and you can't do the really obfuscated stuff, but this is probably a good thing.
Explicitly Inlined functionsThe JIT can inline methods for you. Java can inline methods from shared libraries, even if they are updated dynamically. This does come at a run time cost, but its nicer not to need to worry about this IMHO.
I find lack of function pointers a huge painFunction pointers makes in lining methods more difficult for the compiler. If you are using object orientated programming, I don't believe you need these. For other situations, I believe Closures in Java 8 is likely to be nicer.
The fact that static methods aren't really class methods is pretty dumbI imagine most Java developers have come across this problem at some stage. IMHO: The nicest solution is to move the "static" functionality to its own class and not use static methods if you want polymorphism.
It's far from obvious how one hints that a method should be inlined, or otherwise go real fastMake it small and call it lots of times. ;)
Two identical byte arrays aren't equal and don't hash the sameI agree that its pretty ugly design choice not to make arrays proper objects. They inherit from Object, but don't have useful implementation for toString, equals, hashCode, compareTo. clone() and getClass() are the most useful methods. You can use helper methods instead, but with many different helper classes called Array, Arrays, ArrayUtil, ArrayUtils in different packages its all a mess for a new developer to deal with.
Hashtable/HashMap does allow you to provide a hashing functionThis is also a pain if you want to change the behaviour. IMHO, The best solution is to write a wrapper class which implements equals/hashCode, but this adds overhead.
iterate the characters in a String without implicitly involving half a dozen method calls per characterThere is now String.toCharArray() but this creates a copy you don't need and is not eliminated by escape analysis. When it is, this is the obvious solution. The same applies to "The other alternative is to convert the String to a byte first, and iterate the bytes, at the cost of creating lots of random garbage"
overhead added by Unicode support in those cases where I'm sure that there are no non-ASCII characters.Java 6 has a solution to this which is -XX:+UseCompressedStrings. Unfortunately Java 7 has dropped support for this feature. I have no idea why as this option improves performance (as well as reducing memory usage) in test I have done.
Interfaces seem a huge, cheesy copout for avoiding multiple inheritance; they really seem like they were grafted on as an afterthought.I prefer a contract which only lists functionality offered without adding implementation. The newer Virtual Extension Methods in Java 8 will provide default implementations without state. In some cases this will be very useful.
There's something kind of screwy going on with type promotionThe problem here is solved by co-variant return types which Java 5.0+ now supports.
You can't write a function which expects and Object and give it a shortToday you have auto-boxing. The author complains that Short and short are not the same thing. For efficiency purposes this can make surprisingly little difference in some cases with auto-boxing. In some cases it does make a big difference, and I don't foresee Java optimising this transparently in the near future. :|
it's a total pain that one can't iterate over the contents of an array without knowing intimate details about its contentsIts rare you really need to do this IMHO. You can use Array.getLength(array) and Array.get(array, n) to handle a generic array. Its ugly but you can do it. Its one of the helper class which should really be methods on the array itself IMHO.
The only way to handle overflow is to use BigInteger (and rewrite your code)Languages like Scala support operators for BigInteger and it has been suggested that Java should too. I believe overflow detection is also being considered for Java 8/9.
I miss typedefThis allows you to use primitives and still get type safety. IMHO, the real issue is that the JIT cannot detect that a type is just a wrapper for a primitive (or two) and eliminate the need for the wrapped class. This would provide the benefits of typedef without changing the syntax and make the code more Object Orientated.
I think the available idioms for simulating enum and :keywords are fairly lameJava 5.0+ has enum which are first class objects and are surprising powerful.
there's no efficient way to implement `assert'assert is now built in. To implement it yourself is made efficient by the JIT. (Probably not tens years ago)
By having `new' be the only possible interface to allocation, ... there are a whole class of ancient, well-known optimizations that one just cannot perform.This should be performed by the JIT IMHO. Unfortunately, it rarely does, but this is improving.
The finalization system is lame.Most people agree its best avoided. Perhaps it could be more powerful and reliable. ARM (Automatic Resource Management) may be the answer.
Relatedly, there are no ``weak pointers.''Java has always had weak, soft and phantom references, but I suspect this is not what is meant here. ??
You can't close over anything but final variables in an inner class!There is true of anonymous inner classes, but not nested inner classes referring to fields. Closures might not have this restriction but its likely to be just as confusing. Being used to the requirement for final variables, I don't find this problem esp. as my IDE will correct the code as required for me.
The access model with respect to the mutability (or read-only-ness) of objects blowsThe main complaint appears to be that there are ways of treating final fields as mutable. This is required for de-serialization and dependency injectors. As long as you realise that you have two possible behaviours, one lower level than the other, it is far more useful than it is a problem.
The language also should impose the contract that literal constants are immutable.Literal constants are immutable. It appears the author would like to expand what is considered a literal constant. It would be useful IMHO, to support const in the way C++ does. const is a keyword in Java and the ability to define immutable versions of classes without creating multiple implementations or read only wrappers would be more productive.
The locking model is broken.The memory overhead of locking concern is really an implementation detail. Its up to the JVM to decide how large the header is and whether it can be locked. The other concern is that there is no control over who can obtain a lock. The common work around for this is to encapsulate your lock, which is what you would have to do in any case. In theory the lock can be optimised away. Currently this only happens when the whole object is optimised way.
There is no way to signal without throwingFor this, I use a listener pattern with an onError method. There is no support in the language for this, but I don't see the need to.
Doing foo.x should be defined to be equivalent to foo.x(),Perhaps foo.x => foo.getX() would be a better choice, rather like C# does.
Compilers should be trivially able to inline zero-argument accessor methods to be inline object+offset loads.The JIT does this, rather than the compiler. This allows the calling code to be changed after the callee has been compiled.
The notion of methods "belonging" to classes is lame.This is a "cool" feature which some languages support. In a more dynamic environment, this can look nicer. The down side is that you can piece of code for a class all over the place and you would have to have some way of managing duplicates in different libraries. e.g. library A defines a new printString() method and library B also defines a printString method for the same class. You would need to make each library see its own copy and have some way of determining which version library C would want when it calls this method.
It comes with hash tables, but not qsortIt comes with an "optimised merge sort" which is designed to be faster.
String has length+24 bytes of overhead over byteThat is without considering that each of the two objects are aligned to an 8 byte boundary (making it higher). If that sounds bad, consider that malloc can be 16-byte aligned with a minimum size of 32 bytes. If you use a shared_ptr to a byte (to give you similar resource management) it can be much larger in C++ than Java.
The only reason for this overhead is so that String.substring() can return strings which share the same value array.This is not correct. The problem is that Java doesn't support variable sized objects (apart from arrays). This means that String object is a fixed size and to have variable sized field, you have to have another object. Its not great either way. ;)