Enterprise Reasons Why Java Is Not Ready
August 16, 2013
Posted by on
Java is not an enterprise-ready language. That’s a big call to make considering it has been around for the best part of a decade and is one of the most popular languages in use across all industries – including financial, media, telecommunications.
Java is lacking serious and basic features. They include:
- no unsigned integer support – according to Java language designer James Gosling, “Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is”. Personally I think signed arithmetic is hard – because you need to find out what happens to the most-significant bit when you left-shift. The lack of unsigned arithmetic has stifled and frustrated many a network developer.
- no conditional compilation support – I have two classes I want to link against for different situations. But one class has support for an overridden method, the other doesn’t. There’s no simple way for my dependent class to quickly include or exclude the methods in question.
- hard limit of 64KB on method size – no normal subroutine will ever exceed 64KB in size so this limitation is rarely encountered by developers. But when you write a code generator to emulate captured code you quickly find yourself hitting this limit and are forced to introduce complexity by breaking up your generated code into smaller methods.
- hard limit of 64KB on automatic variable count – while a tree or hashmap can contain megabytes of data you may not declare too many objects in your method or you will hit this 64KB limit.
Java also makes life unnecessarily difficult:
- forcing exceptions to be handled – this results in extremely verbose code – the try .. catch blocks can often bloat code by a factor of 300+% and this is unacceptable when unnecessary. Exception handling is useful, being forced to use it is wrong.
- refusing inner scope local variables with the same name as one in an outer scope – in an effort to protect inexperienced developers from making simple mistakes more advanced developers are stopped from re-using utility variable names in an inner scope with the same name as a variable used in an outer scope. This should be an optional warning at worst rather than a compile-time error.