Difference between Java-Bytecode and IL

[Andy Schmitt]

Hi everybody,

I'm a Java-developer and I tried to compare Java-Bytecode
and IL-Bytecode. There are a lot of differences between those
two bytecodes.

Main difference: IL has a so-called "generic stack".
But does IL have any advantages compared to Java-Bytecode?
Why did Microsoft choose a "generic stack"?

JVM-Bytecode is compiled and optimized to native code with
JITTING/Hotspot. It seems that Java performs even slightly
better then IL.

http://osnews.com/story.php?news_id=5602

IL-Bytecode is here:
http://dotnet.di.unipi.it/EcmaSpec/PartitionIII/cont1.html

Java-Bytecode is here:
http://java.sun.com/docs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html

There is a lot of support for unsigned datatypes in IL. But are unsigned
types really important for general software development? You can convert
a long to an unsigned integer in Java too and I never needed unsigned
types for calculations or something like that.

If you want to have very fast access to native data in Java you can
use NIO. It does the same like unsafe code in .NET.

I clearly don't understand why Microsoft took a different approach
when designing IL-Bytecode. Is it for supporting other program-languages?
If yes: which program-languages? Dynamic languages like Smalltalk or Lisp?

Thanks
Andy

[Jay B. Harlow [MVP - Outlook]]

Andy,
I find "The Common Language Infrastructure Annotated Standard" by James S.
Miller from Addison Wesley does a good job of explaining IL. The
"non-annotated" version is available in the "Tool Developers Guide" when you
install the .NET SDK (\Program Files\Microsoft Visual Studio .NET
2003\SDK\v1.1\Tool Developers Guide for VS.NET 2003).

> I clearly don't understand why Microsoft took a different approach
> when designing IL-Bytecode.

I'm sure they took a "different approach" to avoid a lawsuit. ;-)

> If yes: which program-languages? Dynamic languages like Smalltalk or Lisp?

There are many different languages that can run on the CLR, so I'm not sure
what your question is here.

For a partial list of supported languages see:
http://www.gotdotnet.com/team/lang/ (I say partial as I know RPG is
supported also http://www.asna.com/, and I so not see it listed).

Hope this helps
Jay

"Andy Schmitt" <novali...@no.org> wrote in message
news:uk1j0n92...@TK2MSFTNGP11.phx.gbl...

[Michael Giagnocavo [MVP]]

IL was designed for multiple languages and to be as flexible as possible, as
well as easy-to-implement for compiler writers. Java byte code was designed
just for Java, without any thought to other issues.

IL bytecode allows you to do pretty much whatever you want. You can
manipulate memory directly. IL has much better support for interop than
Java bytecode.

Google for java bytecode IL comparison and you should find a number of
comparisons. Avoid eWeek and other fake news sources, and look for
whitepapers that provide straight comparisons.

-mike
MVP

"Andy Schmitt" <novali...@no.org> wrote in message
news:uk1j0n92...@TK2MSFTNGP11.phx.gbl...

[Sankar Nemani]

> > There is a lot of support for unsigned datatypes in IL. But are unsigned
> > types really important for general software development? You can convert
> > a long to an unsigned integer in Java too and I never needed unsigned
> > types for calculations or something like that.

A compiler writer can choose to not use such unsigned types. So supporting
these in IL shouldn't matter if a higher level language does not want to use
them I guess like J#.
Does that make sense?

"Michael Giagnocavo [MVP]" <mggU...@Atrevido.net> wrote in message
news:uf6b6GF3...@tk2msftngp13.phx.gbl...

[Andy Schmitt]

"Michael Giagnocavo [MVP]" <mggU...@Atrevido.net> schrieb im Newsbeitrag
news:uf6b6GF3...@tk2msftngp13.phx.gbl...

> IL was designed for multiple languages and to be as flexible as possible,
as
> well as easy-to-implement for compiler writers. Java byte code was
designed
> just for Java, without any thought to other issues.

Thanks to all.

Hi Michael,

some days ago I have installed JBasic- that's QBasic for the JVM ;-)

And there are Groovy and Nice - very fine OOP-languages designed
to run on top of the JVM. Both languages have closures and many
other handy things.

I have searched the Microsoft-newsgroups for other languages
like Eiffel, Haskell, Smalltalk etc. I didn't find many postings.
Apparently 99% of all .NET-users are using C# or VB.NET.
VB.NET imho is C# with a slightly different synthax.

My question to the CLR-development-team would be:

"is MSIL designed to support dynamic languages like Smalltalk or Lisp?"
Does MSIL or CLR a better job when running Smalltalk, Lisp or maybe
Python then the JVM does? I didn't find "good answers" to that question.

Andy

[Andy Schmitt]

"Jay B. Harlow [MVP - Outlook]" <Jay_Har...@msn.com> schrieb im
Newsbeitrag news:#jbRuS#2DHA...@TK2MSFTNGP10.phx.gbl...

> > If yes: which program-languages? Dynamic languages like Smalltalk or
Lisp?
> There are many different languages that can run on the CLR, so I'm not
sure
> what your question is here.

Thanks.
Just had a look on some of the projects and I am not enthusiasmated.
Haskell i.e. is a "side-by-side"-implementation and not a true integrated
language.
Same for ActiveState.

The gotdot-website wasn't update since last summer.
The Smalltalk-implementation has nothing to do with Smalltalk ;-)
That's kind of very strange pseudo-Smalltalk-dialect.

And the most important question: does anybody use these languages?
There are an incredible amount of all kind of languages implemented on
top of the JVM but it seems that nobody really uses all those languages.

But thanks for your reply nevertheless
Andy

[Frank Lesser [LSW]]

"Andy Schmitt" <novali...@no.org> wrote in message

news:uVrXlbN3...@TK2MSFTNGP10.phx.gbl...

Hi,

.NET is suited well for traditional languages ( languages with an
edit-compile-run development cycle ) and not for Languages like Smalltalk
where everything is an object and a change take immediate effect.

So concepts of the Virtual-Machine for Java or .NET and Smalltalk differ
much. IMHO it is not possible to integrate Smalltalk full into .NET. Full
means without loosing significant features of the Language.The same holds
also for Smalltalk-Implementations on top of the JVM.

So far there is Smalltalk# ( A Smalltalk to MSIL compiler ) and S# ( S# is
not released under .NET yet and will be the deepest integrated Smalltalk )
Our Smalltalk ( LSWVST - a full Windows-Integrated implementation ) has a
2-way .NET integration ( development integration .NET is regarded as a
Library - runtime integration Smalltalk is transated to MSIL )

Smalltalk's biggest advantage is the integrated development environment -
the debugger which allows full incremental development - edit & continue was
implemented in the debugger from the very beginning ( Smalltalk-80 or even
in Smalltalk-72 ! ).

The object-mutation feature is IMHO impossible to realize with .NET or with
JVM

In Smalltalk you can add classes, methods and fields ( = instance variables,
class variables and class instance variables ) with immediate effect and you
can add methods to any class including Object , Collection classes and such
classes as Behavior, Class and MetaClass. Furthermore you can move a class
to a different superclass **without** loosing Objects.

If you add / delete instance-variables existing Objects will be lazily
mutated in almost zero-time.
This is IMHO the biggest advantage of Smalltalk. There are also a lot of
shortcuts in existing implementations - mainly the bad OS integration. Only
Dolphin Smalltalk and Smaltalk MT are really OS - integrated implementations
which can be used for serious Windows GUI development.

In .NET you cannot do such things - you need to recompile the Assembly to
which the edited item belongs, so for one little change you loose all your
state and you must rerun the application.

Also .NET and JVM differ much in the concept of OS-Integration, where Java
uses emulated Widgets or native Widgets with restrictions .NET uses full
native Widgets.

Frank Lesser, www.lesser-software.com

[Andy Schmitt]

"Frank Lesser [LSW]" <Frank-...@lesser-software.com> schrieb im
Newsbeitrag news:eD4BIWP3...@TK2MSFTNGP12.phx.gbl...

> In .NET you cannot do such things - you need to recompile the Assembly to
> which the edited item belongs, so for one little change you loose all your
> state and you must rerun the application.
>
> Also .NET and JVM differ much in the concept of OS-Integration, where Java
> uses emulated Widgets or native Widgets with restrictions .NET uses full
> native Widgets.
>
> Frank Lesser, www.lesser-software.com

Thanks Frank for your very interesting post.
I don't understand what you mean with "full native widgets".
SWT for Java, developed by OTI/IBM for the Eclipse-IDE
uses full native widgets too and some emulated widgets because
native widget-toolkits sometimes lack some important features.
There are lot of problems with native widgets too. Nothing is perfect.
Neither Swing neither SWT or Winforms.

Just another off-topic-question, Frank.
Your company has developed an obfuscator for NET-assemblies.
Would it be very difficult to write a MSIL-reflection-package in Java?
I mean a Java-package similar to the Java-reflection-library which
reads classes, methods, constructors, fields etc. from a NET-assembly?

----------
Something like that:

import net.sf.clrreflect.Assembly;
import net.sf.clrreflect.Class;
import net.sf.clrreflect.Method;

Assembly assembly = new Assembly("c:/windows/System.dll");
Class[] classes = assembly.getClasses();
System.out.println(classes);
....
Class class = Class.forName("c:/myassembly.dll","com.foocompany.Foo");
Method[] methods = class.getMethods();
System.out.println(methods);
---------

Andy

[Jon Skeet [C# MVP]]

Andy Schmitt <novali...@no.org> wrote:
> Would it be very difficult to write a MSIL-reflection-package in Java?
> I mean a Java-package similar to the Java-reflection-library which
> reads classes, methods, constructors, fields etc. from a NET-assembly?

You certainly could do - the file format is reasonably well documented.
I think I'd avoid using a type named "Class" however :)

--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Frank Lesser [LSW]]

"Andy Schmitt" <novali...@no.org> wrote in message

news:OxJm5tj3...@TK2MSFTNGP11.phx.gbl...

>
> "Frank Lesser [LSW]" <Frank-...@lesser-software.com> schrieb im
> Newsbeitrag news:eD4BIWP3...@TK2MSFTNGP12.phx.gbl...
>
> > In .NET you cannot do such things - you need to recompile the Assembly
to
> > which the edited item belongs, so for one little change you loose all
your
> > state and you must rerun the application.
> >
> > Also .NET and JVM differ much in the concept of OS-Integration, where
Java
> > uses emulated Widgets or native Widgets with restrictions .NET uses full
> > native Widgets.
> >
> > Frank Lesser, www.lesser-software.com
>
> Thanks Frank for your very interesting post.
> I don't understand what you mean with "full native widgets".
> SWT for Java, developed by OTI/IBM for the Eclipse-IDE
> uses full native widgets too and some emulated widgets because
> native widget-toolkits sometimes lack some important features.
> There are lot of problems with native widgets too. Nothing is perfect.
> Neither Swing neither SWT or Winforms.
>

Andy,

with restricted/full native widgets I mean that a JVM must be desgned to be
called back by the OS recursively to support full natie widgets.
for example **before** a CreateWindowEx call returns several WM_XX messages
should be handled.
IMHO the Java VM's are not designed to do that. Every Foreign-Call can cause
multiple Callbacks into the JVM - so you will need a "Stack of JVM's"
to handle OS Messages properly - of course you can avoid the situations by
not responding to WM_XX messages and let the OS do default message
processing.
In the case of WM_CREATE where within the WM_CREATE of the Overlapped Main
Window the creation of child windows should be handled for example one
creates
all Children with 0 extent and position them afterwards. As you see the
whole design of the GUI framework changes significatly. IMHO if you do not
have RCB feature the GUI framework will be a workaround framework where in
the worst case a lot of things must be duplicated or will be handled
intrinically different than it should be..

The situation gets even more complicated in the case of debugging Recursive
callbacked code with a debugger which is written on top of the same VM.

I am not really aware of the JVM Recursive callback feature but I believe
Recursive Callback is not possible in JVM.
For this reasons a lot of Languages which requires VM uses some glue layer
( IBM VisualAge Smalltalk uses a Motif Layer ) or emulated widgets (
VisualWorks )
Our Smalltalk VM is designed to handle recursive-callback and the debugging
case.

> Just another off-topic-question, Frank.
> Your company has developed an obfuscator for NET-assemblies.
> Would it be very difficult to write a MSIL-reflection-package in Java?
> I mean a Java-package similar to the Java-reflection-library which
> reads classes, methods, constructors, fields etc. from a NET-assembly?
>
> ----------
> Something like that:
>
> import net.sf.clrreflect.Assembly;
> import net.sf.clrreflect.Class;
> import net.sf.clrreflect.Method;
>
> Assembly assembly = new Assembly("c:/windows/System.dll");
> Class[] classes = assembly.getClasses();
> System.out.println(classes);
> ....
> Class class = Class.forName("c:/myassembly.dll","com.foocompany.Foo");
> Method[] methods = class.getMethods();
> System.out.println(methods);
> ---------
>
> Andy
>
>

This would be possible - we do that in our LSW DotNet-Lab which is written
in Smalltalk. But it is a lot of work to read everything on a binary level -
our Smalltalk Assembly Read/Writer consists of a few hundred classes It
gives us a lot of advantages:
We can load/unload Assemblies without the known restrictions. We have more
reflection features ( e.g. all possible Cross-References ) and we can load
more than one version of an assemblies at one time.

Frank