Difference between .NET and Java

[Guest]

Java is multi-platform

Java *is* a platform.

 

[Chris Smith]

I've seen diagrams that show .NET being compiled to byte code prior to MSIL,
since I don't have this reference handy I'll just assume it was incorrect,
however my understanding of the JIT process used by .NET is quite a bit
different than the Java2 approach, see:
http://www.gamespp.com/csharp/usingNETJITCompiling.html

It's quite unfortunate that such a thing exists on the web, but it
merely proves the adage that you can't trust everything you read or
hear. The article describes .NET JIT compilers just fine, without even
realizing that Java's JIT compilers work in *exactly* the same way.
Replace every .NET JIT statement with an equivalent Java one (i.e.,
replace references to MSIL with bytecode), and you get a bunch of true
statements.

The last paragraph of that article is wrong; no other way to put it.
It's not debatably wrong, and it's not a matter of interpretation, and
it's not merely misleading; it's pure unadulterated wrong! Java JIT
compilers take bytecode as INPUT and produce native machine code as
OUTPUT, in the same way that .NET JIT compilers do.

What is different is that .NET offers the potential to precompile a .NET
application to native code, whereas no well-known Java environment
provides that same option. This might have some impact on startup time,
but will have no appreciable impact on runtime speed once the program
has been running for any amount of time. The article you cite mentions
the same thing.

I'd argue the usefulness of code refactoring, but that is subjective..
IBM's current IDE product fall a bit short on delivering VS.NET style
"intellisense" functionality and code generation, but the context sensitive
help is another huge beneift that comes to mind. Not to mention the ease of
managing solutions, maybe it's just my lack of experience with other IDEs,
perhaps they should be more intuitive.

This comes down strongly to a matter of not only preference for
interface details, but also whether you develop code according to the
model that Microsoft has chosen to implement in Visual Studio. I've
never worked with VS.NET, but I have worked for years with prior
versions of Visual Studio. I consider code generation to be its
greatest weakness. The environment decides for you how you are going to
structure your code, and if that's not appropriate for your project then
too bad. (Part of this is also a complaint about class libraries that
assume you will be generating your code with VS, and therefore require
vast amounts of boilerplate code to set up a framework for the app.)

It's probably along a similar vein that I consider simple refactoring
support critical (at least renaming with references, and extracting and
inlining methods and fields; the rest are more rarely used).

I can say that having used Visual Studio 6 for about 2 years, and
Eclipse for about 2 years, I would gladly toss out Visual Studio for
Eclipse any day of the week. Perhaps VS.NET is a better product in
these regards; I'd love to be enlightened.

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Roedy Green]

What is different is that .NET offers the potential to precompile a .NET
application to native code, whereas no well-known Java environment
provides that same option.

Maybe you don't know them, but I use one of them every day.

See http://mindprod.com/jgloss/nativecompiler.html

 

[Tor Iver Wilhelmsen]

What is different is that .NET offers the potential to precompile a .NET
application to native code, whereas no well-known Java environment
provides that same option.

IIRC, Microsoft even discourages the use of that precompiler
(ngen.exe).

Another difference is that Java has its source compiler in the SDK
only, while Microsoft ships the C# compiler with the runtime (.Net
Framework), leaving code signing etc. in the SDK.

 

[Roedy Green]

Another difference is that Java has its source compiler in the SDK
only, while Microsoft ships the C# compiler with the runtime (.Net
Framework), leaving code signing etc. in the SDK.

I get the feeling that is about to change. Then you will be able to
write apps such a spreadsheets that you generate as Java source,
compile and run on the fly.

 

[Tor Iver Wilhelmsen]

I get the feeling that is about to change. Then you will be able to
write apps such a spreadsheets that you generate as Java source,
compile and run on the fly.

More likely is that the JRE is supplied with a class synthesizer to
produce the bytecode directly, though at a higher abstraction level.
Generating java source as intermediate code is one of the factors that
mage JSP such a mess (one small JSP for me, one GIANT _jsp_init() for
the world) compared to ASP.Net's Codebehind concept.

 

[Roedy Green]

More likely is that the JRE is supplied with a class synthesizer to
produce the bytecode directly, though at a higher abstraction level.

You can do that already. See http://mindprod.com/jgloss/jasm.html

Eventually we will have both, with sun standard apis.

 

[Steve Horsley]

Architecture wise the .NET byte codes gets transformed into a intermediate
language and cached as native code before execution. All most Java2
programming is J2ME specific, but I don't think the Java2 VM Sun provides
for Windows does, one of our Java2 programmers told me that IBM has a
Just-In-Time VM for Win32 that does do this, but it's commerical software
and cost $$$ to license. The result of this is that .NET apps run faster
than Java2 apps on Windows with the default Java2 VM provided by Sun.

I'm not clear what this means, but it gives the impression that java
doesn't use a JIT and is therefore slower than .NET. The truth is that java
abandoned JIT for mixed-mode some years ago in order to improve performance,
and is therefore faster than .NET which is required by the ECMA standard to
continue to use JIT only.

Also, I believe that the IBM VM (which like the Sun VM, uses mixed mode)
is also free to download and use.

Steve

 

[Roedy Green]

The truth is that java
abandoned JIT for mixed-mode some years ago in order to improve performance,
and is therefore faster than .NET which is required by the ECMA standard to
continue to use JIT only.

Java did no such thing. Sun changed THEIR JVM. There are lots of JVMs
out there, and they work in a diverse number of ways.


see http://mindprod.com/jgloss/compiler.html

People keep extrapolating from one implementation of Java onto Java
the language for all time. We need to be careful in vocabulary to
combat that.

Rumours of inherent flaws in Java the language are eagerly seized on
and spread by MS lackeys.

 

[Steve Horsley]

Java did no such thing. Sun changed THEIR JVM. There are lots of JVMs
out there, and they work in a diverse number of ways.


see http://mindprod.com/jgloss/compiler.html

People keep extrapolating from one implementation of Java onto Java
the language for all time. We need to be careful in vocabulary to
combat that.

Rumours of inherent flaws in Java the language are eagerly seized on
and spread by MS lackeys.

Quite true. I do tend to equate the Sun JVM with java. But since both Sun
and IBM have changed to mixed mode execution, I still feel quite justified
in generalising this to "java".

Steve

 

[Roedy Green]

Quite true. I do tend to equate the Sun JVM with java. But since both Sun
and IBM have changed to mixed mode execution, I still feel quite justified
in generalising this to "java".

But it leaves out the embedded stuff which is now become the tail
wagging the Java dog. It also leaves out static compilation, the thing
the anti-Java people keep claiming does not exist.

The beauty of Java is that there are many JVMs and the code runs on
all of them.

 

[ritusaraf16]

what are the differences between java & .net? what are the advantages of .net over java?