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

[Kent Nguyen]

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

This is what is so great about Java.  Everything is reference by object.  For 
instance primitive type should be Char object rather than char.  If you use 
char in your program in an OOP class, I think you will get points deducted.  

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

What is "infix operator overloading"?

>
> 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)

Java OOP design is very good.  The problem here I think is how the JVM 
interprets the code.

>
> 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.)

What is "generic support"?

>
> 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.

We aren't using java for AWT.

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

"weak references"?

>
> 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.

The JVM pretty much handles the dereferencing when it is no longer needed.  
However there's an object that you can use to do dereferencing yourself.

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

Now that's beautiful, you test reference equality.  Coming from a perl 
standpoint, you might not understand.

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

Everything should be an object in Java.  That's the beauty of OOP design.

>
> The Java Native Interface is clumsy and slow.

The only time you need JNI is if you really need native stuffs.  But you can 
write an OS out of Java.  It is the beauty of the language that counts.

>
> 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.

You can compile Java to native binary.  gcj does it.  http://gcc.gnu.org/java/

>
> 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.

Your arguments seem to come from a "Perl" or "C" background.  But if you step 
back and think everything in OOP, you will realize how wonderful Java as a 
language is.  It's like writing poem in French rather than English. :)

--kent