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

[Kent Nguyen]

I'll take this offline with you.

--kent

On Monday 16 July 2001 17:02, Soeren Sandmann wrote:
> > ----------  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
> _______________________________________________
> Developers mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/developers