Posted Apr 8, 2005 9:28 UTC (Fri) by Xman
In reply to: A shame
Parent article: GCJ - past, present, and future
Just to review the faults you cited:
- Most OO languages have their methods virtual by default, as it aids in reuse. While there is a performance penalty normally associated with virtual functions in C++, modern JVM's are very good at optimizing this to the point where they often inline virtual function calls. Frankly, I find it annoying how often I have to specify "virtual" in C++. Really, it's a style issue, not a design flaw.
- compulsory exception specifications. Well, they did better than their predicessors in this regard, but I'd agree this proved in time to still not be a good design. The thinking at the time (and it was by no means restricted to the folks designing Java) was that exception specifications were a good thing, but just hadn't been done right yet.
- 16-bit characters. They did start out this way, back when everyone thought all Unicode characters could be represented with 16-bit characters (and they weren't the only ones to make this mistake... for example Windows NT and C++'s STL). They now do 32-bit characters and strings are encoded internally in UTF-16. When writing to streams and such you'll find your locale determines the default encoding (so for example things will often get encoded in UTF-8). This is the same scheme used by Unicode libraries for other languages such as the C++ ICU library. It's really hard to run in to endian problems with the internal encoding of strings because that isn't visible. It's really hard to run in to endian problems with integers in Java, because Sun ensures a consistent byte order. They have their bases covered here.
- not being able to mimic built-in types. This was done deliberately, and frankly has a lot to do with Java's commercial success. Talk to Smalltalk component vendors to get an idea as to why this can be a good thing.
- They actually did break a lot of C's worst syntax rules and clarified a number of C's ambiguities. That said, they started out originally wanting to be as much like C/C++ as possible while still achieving their design goals, and arguably this was to their advantage.
- Java has generics now, so you can actually avoid pervasive casting. They avoided putting generics in at first because they weren't 100% sure how to do it right, and they figured doing it even slightly wrong would make generics more of a hinderance than a help (I think they ended up being a little wrong on this, but it was a pretty rational decision as they had no way of knowing how successful Java's initial design would be). Even if you don't use generics and do lots of casting, you get runtime errors if you screw up your types, rather than C's tendancy to ignorantly blunder on.
- Try profiling Java code sometime and see how much time is spent doing memory management. I've found on average Java programs spend less time managing memory than most C/C++ programs. Ironically, a lot of the performance problems I see in Java programs are caused by trying too hard to avoid allocating memory on the mistaken premise that the performance costs of doing so are as severe as they are in the C/C++ world. There are times when managed memory is a pain, and ever since JDK 1.4 there have been options available to avoid it. There are still cases where Java makes it hard to do what you really should be doing with memory, but they are well past the 90/10 rule.
In summary, I think you lack context when interpreting Java's design. This leads you to see nonsensical design decisions driven by proprietary head-knocking when in fact there are quite rational reasons behind their decisions. Java wasn't designed as a weapon for Sun to use against Microsoft (and looking at the design "faults" you've cited, I'm at a loss to see how they serve to make Java a weapon): that's how it was marketed. The original design was done well before the marketing strategy was even put in place (in fact the marketing strategy changed a few times as I recall), and originally was targetted at networked embedded devices (back before Microsoft had a presence there).
Sure, Java isn't perfect. No language is. Despite this programmers manage to find a lot of them useful, and Java is no exception in this regard.
to post comments)