genjava / editorials / what I hate about java
What I hate about Java
by Henri Yandell, aged 5 and 1/2
Not 'what I've found painful but accept, like security'
- Sun's JDK management style. Why is the JDK one huge lump (cheaper management probably)? Why no regexp.jar for JDK 1.1->1.3.
- "There's one correct way to do it". Java has a mantra approach that the coders must be protected from doings things wrong/oddly.
- Java's position as a subject of hatred/dislike for most non-java people, especially Microsoft fans and GPL[Linux etc] fans. It gets quite tiring to have them treating us as an enemy.
- static-ness of the classes in a classloader. You cannot add/replace methods at runtime etc. I'm sure you could try to hack it yourself, but Sun have failed to get exciting with ClassLoaders.
- No method literal, 'java.lang.Object.toString(void).method'. Or without the 'method'. This would allow for some nice functional programming style code and would not be hard to implement I believe: java.lang.String.indexOf(char).method etc.
- JCP is a private club in that the JCP project lists are not open for reading. Also there is a seeming dominance of the JCP by corporates, which feels like putting McDonalds/Burger King in charge of the 'Burger specification'.
- Marketing. God the marketing. Does anyone trust a press release?
- Buzzwords. All the people who easily accepted that J2EE meant using EJB.
- Lack of mixins and other literals like regexps and URLs. Basically syntax sugar to make the language quicker and more importantly to push those features to the user.
- Sun's attitude towards open-source. It seems to be a negative attitude until for a particular instance they are forced to embrace it. They embrace popular projects when it suits them and not the community as a whole.
- Lack of better mathematical support. Nothing massive, a Complex number class with accompanying literal and operator overloading would placate me.
- No operator overloading for Numbers. I do agree with not customising operator overloading, though I dislike the fact it is enforced.
- No compiler option to enforce the user of 'this.' for attributes and/or methods. I believe the compiler should allow for many of the enforced concepts to be optional.
- Double + Float extend Number and not Real [which would extend Number].
- People who put project documentation guides in their javadoc.
- Failure to add Maps or 'keyed properties' to the JavaBean spec, despite the enormous need for such.
- The new import style in JDK 1.5. It's something Microsoft would do.
- Unable to put static methods in interfaces.
- Cannot overload return types, though it would make my earlier method literal a bit harder to specifiy.
- Not having % or @ symbols as legal Java identifiers. So many other characters are, why not let us tease perl-ites.
- Sun's failure to follow their own coding standard in their code.
- The poor reuse ability of the tools.jar away from a command line.
- Lack of marketing about all the languages that run on the JVM, allowing the .Net marketing point to gain far too much anti-Java strength.