Re: [DotGNU]Re: Support Java for .GNU

[Martin Coxall]

> I like to hear the technical shortcomings of Java.

Well, okay, but I think you're missing the point. Java does have technical 
shortcomings, but it is its heinous legal shortcomings that make it an 
unacceptable choice for dotGNU.

So, bearing in mind that the Legal shortcomings are really the reason I would 
hate to see dotGNU adopt it, here are the some technical reasons why I feel 
the Java platform is lacking.

Java only supports heap-allocated reference types. There is no way to support 
pass-by-value concrete types in Java.

Java does not support even elementary well-behaved infix operator 
overloading. For readable numerics or mathematical coding this is essential.

Java's numerics support is terrible. (Infinities and NaN's are not properly 
handled, Java refuses access to hardware features supported by 95% of 
processors, 'Loose' numerics libraries)

Generics support is not designed into the bytecode specification. Java's 
"erasure" proposal amount to little more than removing the generic types at 
compile time. (The Mono CLR can have generics support at the IL language 
level, as first-class types, and C# will have generics in its next release.)

Java does not support type-safe enums, boxing and unboxing of primitive value 
types (who likes writing int one = new Integer(oneString).intValue() ?), and 
concise object array literals for variable-length function prototypes or out 
parameters.

Java's AWT is minimal in scope and almost useless. Swing is slooooow, doesn't 
emulate the look and feel of any GNU/Linux desktop, and doesn't follow theme 
rules specified by the user, because it's all done using drawing primitives.

The Garbage Collector can be fooled into causing memory leaks, due to the way 
weak references are handled in the Java Language Specification.

Object finalisation is erratic, and Java provides no clean way (e.g. C++ 
destructors, C# using(:IDispose) ) of ensuring that scarce resources are 
freed up when an object loses scope.

Strings have + overloaded at the LANGUAGE level, yet == does not test string 
equality, it tests *reference* equality.

Arrays behave like objects at some points, yet not at others.

The Java Native Interface is clumsy and slow.

Java bytecodes are designed to be interpreted. This means that you may never 
get optimal JIT performance, as you will with a language designed to be 
JITted, e.g. Mono's CLR Intermediate Language.

I'll stop there, I think. I believe I have adequately demonstrated that Java 
has many technical flaws as well as its veritable cavalcade of legal 
obstacles.

---
Martin
---

"Where laughing and smiling are not allowed"