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

[Jeremy Petzold]

I would like to comment,

What ever decision is made about this, I would like to
say that we should not and can not exclude Java from
our platform, It should have just as much access to it
as we give C#, this will ensure lots of developers
that will use our system, and it will give us a rout
to exclude C# if the need ever arises (like M$ doing
some extremely Draconian tactic to destroy all
competition who use it, it could happen).

-Jeremy

--- Martin Coxall <address@hidden> wrote:
> > 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"
> 
> _______________________________________________
> Developers mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/developers


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/