Re: Fwd: Re: [DotGNU]Microsoft & Mono

[Soeren Sandmann]

> ----------  Forwarded Message  ----------

[Are we discussing on or off the list?]



Kent Nguyen <address@hidden> writes:

> > The CIL/CRL is technically superior to Java.  Saying otherwise is just
> > MS-bashing.  Here are some points where CIL/CRL is technically better:
> >
> >         - Stack allocated types.  In Java, record types are always
> >           heap allocated
> 
> Stack allocated types are OS dependent.  You can use JNI to do it. 

No, they are not.  The spec says clearly how they should behave on the
CLR.  They are completely safe with respect to types and garbage
collection.

> >         - Unmanaged code.  In CIL/CRL it is possible to run unmanaged
> >           code.  This makes it possible to run C on the platform. (But
> >           not with garbage collection or typesafety).  JVM does not
> >           have this conecept.
> 
> What the heck is unmanaged code, you mean I can mix and match PHP, Python, 
> Bash, and C into a program.  This is one way to make your code look
> dirty.  

Unmanaged code is bytecode that is allowed to do nasty things, like
working with native pointers, fiddeling with the stack (both the VM
stack and the native one) and so on.  This means, aside from running C
code, that it is possible to write e.g., a device driver in C#.  It is
also possible to make system calls without using native C code.  This
simplifies the VM, the system classes and should improve effiency of
native calls because the VM doesn't have to generate C calls on the
fly - it can just use the VM stack (which on any reasonable VM
implementation is the same as the C stack).

A native method, called via JNI, can easily break the virtual machine
(it can just segfault) if it wants to, so unmanaged code is not any
more insecure than JNI.

IMHO, unmanaged code is quite a bit more elegant than JNI, because it
makes it eksplicit when something non-portable is going on.  It allows
something like JNI to be implemented within the platform, not in the
virtual machine.

> Java is clean.

It is not any cleaner than C#.  The languages are pretty similar.
IMHO, C# is better: it has structs, goto, foreach and has gotten rid
of Javas annoying only-one-public-class-per-file concept.  On the
other hand, C# lacks parametric genericity, which is on its way to
Java.  Microsoft has mumbled something about genericity in the next
version, though.

> >         - Managed pointers.  It is possible to have a pointer to a
> >           field of an object.  In java, the only pointers are object
> >           references.
> 
> JNI again.  This is one of thing that will make security a concern running 
> CRL.  

No, managed (typed) pointers are a part of the .NET platform.  They
are tracked by the garbage collector, and in general every bit as safe
as object references.  

Java doesn't have a similar concept. JNI is not even related to
managed pointers.

> >         - Native sized integers.  CRL/CIL has both integers of a fixed
> >           size and integers of native size.  Java only have integers
> >           of fixed size.
> 
> The beauty of cross platform is you need to abstract the idea from all the 
> platform.  If you want native size integers, you use JNI.

Some times you want 'just an integer - please give me the most
efficient one the host can support'.  In java, you are forced to say 'I
want an integer that is 32 bits long'.

Granted, this makes it possible to write managed code that is not
portable across architectures.

Søren