Java and .NET (no Flames Pls)

[Tarundeep Singh Kalra]

Hi ,

I am genuinely intrested in having the performance comparsion of Java and
..NET platforms.

To make an analogy they both are same.

Now, i have questions :- what is best for what.

According to my understanding:-

-Java is best fit for server side solution ( if you dont have Microsoft
Server Solutions).( Traditionally this is the case as most of us have
Linux,Unix or Solaris).

- C++(MFC,Win32 etc) is best for desktop clients (perfromance oriented).

I rememberduring the start of my career i had made one Java Swings
Application that we had to discard and redo in MFC- becuase of perfromance
issue and huge Java Runtime requirements.


Now that Java and .NET both need runtime - so what should i choose for
desktop application that could be two tier , multitier or anything that is
interactimg with kernel mode also.

Genuine inputs needed- Thanks in Advance.

Again , i do not want any flames from java supporters or c++ supporters.
Even i feel that Java is best for backend and C++ is best for fontend.

Regards
Tarun



--
Regards
Tarundeep Singh Kalra

www_dot_tarunsadhana_dot_com.

tarun_at_removeAT_tarunsadhana_dot_com.remove_dots

 

[Jon Skeet [C# MVP]]

I am genuinely intrested in having the performance comparsion of Java and
.NET platforms.

To make an analogy they both are same.

Now, i have questions :- what is best for what.

According to my understanding:-

-Java is best fit for server side solution ( if you dont have Microsoft
Server Solutions).( Traditionally this is the case as most of us have
Linux,Unix or Solaris).

Not sure what the "most of us" refers to - it's very difficult to
really pin down what most developers will be coding towards. There are
things like Mono if you want to write .NET code and run it on other
platforms. I don't know what their performance is like though.

For server-side Windows work, either .NET or Java is fine.

- C++(MFC,Win32 etc) is best for desktop clients (perfromance oriented).

That's only true if you absolutely need all that performance though.
I'd rather have an app which worked well and had all the features I
needed (because the developers were more productive) than one which did
almost nothing, but did it very fast.

I rememberduring the start of my career i had made one Java Swings
Application that we had to discard and redo in MFC- becuase of perfromance
issue and huge Java Runtime requirements.

Java performance issues have decreased significantly, and keep doing
so. I believe startup (a traditional Java bugbear) is much faster in
Java 5, although I haven't tried it myself.

Also bear in mind that computers have become *much* faster since Java
was first launched... an entry-level desktop has far more processing
power than most users will really need.

Now that Java and .NET both need runtime - so what should i choose for
desktop application that could be two tier , multitier or anything that is
interactimg with kernel mode also.

Whether or not the runtime is a significant factor depends almost
entirely on your target market, in my view. Bear in mind that the .NET
runtime is bigger than the Java one, but is available on Windows
Update, so is already on many computers which might not really "need"
it.

 

[Morten Wennevik]

Hi ,

I am genuinely intrested in having the performance comparsion of Java and
.NET platforms.

To make an analogy they both are same.

Now, i have questions :- what is best for what.

Well, if you do programs for windows platforms, .Net. It benefits from being tightly integrated with the underlying system. For cross platforms you probably need java, although you could do some .Net with Mono.

According to my understanding:-

-Java is best fit for server side solution ( if you dont have Microsoft
Server Solutions).( Traditionally this is the case as most of us have
Linux,Unix or Solaris).

Well, there isn't really an option to run .Net on anything but Microsoft systems.

- C++(MFC,Win32 etc) is best for desktop clients (perfromance oriented).

Not really, you get quite the performance out of <any>.Net, but GDI+ isn't hardware accelerated.
You can use C++ with .Net, and you can do managed DirectX with .Net with a performance loss of about 3%.

http://www.vertigosoftware.com/Quake2.htm

I rememberduring the start of my career i had made one Java Swings
Application that we had to discard and redo in MFC- becuase of perfromance
issue and huge Java Runtime requirements.


Now that Java and .NET both need runtime - so what should i choose for
desktop application that could be two tier , multitier or anything that is
interactimg with kernel mode also.

I'd say it depends on your target platforms. Both java and .net is designed for any number of tiers, although .Net benefits from being designed for windows platforms. In C# you also have the opportunity to do unmanaged (unsafe) code for integration with unmanaged components or simply performance issues.

Genuine inputs needed- Thanks in Advance.

Again , i do not want any flames from java supporters or c++ supporters.
Even i feel that Java is best for backend and C++ is best for fontend.

Regards
Tarun

You might want to check out this comparison. It's not a performance comparison, but interesting nonetheless.

http://www.25hoursaday.com/CsharpVsJava.html

 

[Tommy Carlier]

For both server-side and client-side: if you're using Windows, .NET is
better. If you're not using Windows, Java is better.

..NET is optimized for Windows. Even for a rich client-side GUI
program, .NET is very good. Java/Swing is very slow for GUI, .NET has
fast GUI functionality. The big advantage of .NET (and Java) over
C++/MFC: much easier to maintain, nicer to program in.

 

[Guest]

In test apps, C# is currently beating Java in most areas. Blah! Blah! Blah!

Realistically, even though C# is performing better, it is not as realistic a
solution in all arenas. You have to examine more than pure performance to
make a proper decision.

If you are BSD, UNIX, Linux based, there are open source implementations of
the Framework, like the Mono project, so .NET is not out, if it makes sense
to you. Java is more ingrained, however.

What .NET offers for me, over Java, beyond all of the FUD thrown out in perf
comparisons, etc., is Visual Studio .NET, which is a great IDE. I have worked
with Java IDEs and I feel they pale in comparison. I have not touched Java in
a little over a year, so there may be a new version of JBuilder that really
rocks. I am working on what I know from the past. NOTE: I am not saying
choose a platform because it has cool tools.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Jon Skeet [C# MVP]]

What .NET offers for me, over Java, beyond all of the FUD thrown out in perf
comparisons, etc., is Visual Studio .NET, which is a great IDE. I have worked
with Java IDEs and I feel they pale in comparison. I have not touched Java in
a little over a year, so there may be a new version of JBuilder that really
rocks. I am working on what I know from the past. NOTE: I am not saying
choose a platform because it has cool tools.

I found the exact opposite when I started with .NET. I missed (and
still miss) some of the wonderful features of Eclipse. It's nice to
know that Microsoft will have refactoring in VS.NET 2005 - only a few
years after Java developers started thinking of it as pretty much a
required feature for a decent IDE.

We'll see whether VS.NET 2005 gets up to Eclipse's standard in other
areas, of course, but I'm skeptical.

If you love designers, VS.NET may be the bee's knees - I prefer
actually writing code most of the time, and on that front, Eclipse is
in the lead IMO.

 

[Daniel O'Connell [C# MVP]]

I found the exact opposite when I started with .NET. I missed (and
still miss) some of the wonderful features of Eclipse. It's nice to
know that Microsoft will have refactoring in VS.NET 2005 - only a few
years after Java developers started thinking of it as pretty much a
required feature for a decent IDE.

We'll see whether VS.NET 2005 gets up to Eclipse's standard in other
areas, of course, but I'm skeptical.

If you love designers, VS.NET may be the bee's knees - I prefer
actually writing code most of the time, and on that front, Eclipse is
in the lead IMO.

Interestingly, I've noticed that people who come from a java background tend
to like Eclipse and Eclipse style ides, but people who have been using
visual studio for a long period of time tend to regard eclipse as lacking in
alot of ways.

I don't think its features, I think its more just subtle behavior. When I
use eclipse it just doesnt seem like...typing is the same as it is in visual
studio.
Odd, to say the least.

 

[Jon Skeet [C# MVP]]

Interestingly, I've noticed that people who come from a java background tend
to like Eclipse and Eclipse style ides, but people who have been using
visual studio for a long period of time tend to regard eclipse as lacking in
alot of ways.

I don't think its features, I think its more just subtle behavior. When I
use eclipse it just doesnt seem like...typing is the same as it is in visual
studio.
Odd, to say the least.

I wonder how many of them have used Eclipse for long enough to get used
to it. It took me a while to get used to VS.NET, and I like it more
than I did to start with. I still miss incremental compilation,
intellisense that can display more than one overload at a time,
compile-on-save, the Eclipse project system, refactoring, contextual
diffs, organise imports, a decent source-safe plug-in (ironically!)...

 

[C# Learner]

It's nice to
know that Microsoft will have refactoring in VS.NET 2005 - only a few
years after Java developers started thinking of it as pretty much a
required feature for a decent IDE.

On the subject of refactoring, I was watching a presentation of the next
major release of Delphi today, which, too, contains IDE support for
refactoring.

http://info.borland.com/media/shockwave/delphi2005/diamondbacksneakpeek.swf

Just wanted to mention this for any current/past Delphi users here.

Note that the product supports Delphi for Win32, Delphi for .NET and _C#_
for .NET.

 

[Cowboy \(Gregory A. Beamer\)]

I stand corrected on the refactoring, but I had it with some third party
tools at the job I had before working for the state. Overall, I still had
problems with Java IDEs in other areas.

Visual Studio gets much better in 2.0. I would like to see them put a real
slick WYSIWYG editor and even better XML support, but it is a great leap
from Visual Studio .NET 2003, which is already a great IDE overall.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside the box!
*************************************************

 

[Daniel O'Connell [C# MVP]]

I wonder how many of them have used Eclipse for long enough to get used
to it. It took me a while to get used to VS.NET, and I like it more
than I did to start with. I still miss incremental compilation,
intellisense that can display more than one overload at a time,
compile-on-save, the Eclipse project system, refactoring, contextual
diffs, organise imports, a decent source-safe plug-in (ironically!)...

Well, incremental compilation never mattered much to me, for whatever reason
most of the mistakes I make are truely egregious, like

Console.WrtieLine("Whatever"):

Which the parser picks up, or ones which aren't really compliation errors.
Still, I can see the benifits.

As for the source-safe plugin, I imagine the ecplise plugin is better than
VSS itself, . I'm rather fond of Vault myself.

As for refactoring, I never really considered it useful until whidbey. When
I was learning java using eclipse, for whatever reason I didn't think it was
very useful. I've been shown Iwas wrong since, but for some reason it
seemed to be pointless at the time.

 

[Jon Skeet [C# MVP]]

Well, incremental compilation never mattered much to me, for whatever reason
most of the mistakes I make are truely egregious, like

Console.WrtieLine("Whatever"):

Which the parser picks up, or ones which aren't really compliation errors.
Still, I can see the benifits.

Note that I don't mean "as you type" error detection - I mean actual
compilation. In Eclipse, by default it compiles the code every time you
hit save. If VS.NET did that, it would be a pain in the neck because it
would recompile a whole load of stuff which hadn't changed

As for the source-safe plugin, I imagine the ecplise plugin is better than
VSS itself, . I'm rather fond of Vault myself.

Unfortunately I'm stuck using VSS at work...

As for refactoring, I never really considered it useful until whidbey. When
I was learning java using eclipse, for whatever reason I didn't think it was
very useful. I've been shown Iwas wrong since, but for some reason it
seemed to be pointless at the time.

I haven't had a careful look at what the support is like in Whidbey. My
guess is it won't be as extensive as Eclipse due to timescales, but
that probably doesn't matter - there aren't *many* refactorings I use
in Eclipse anyway. It's just that they're incredibly handy when I do
use them!

 

[Daniel O'Connell [C# MVP]]

Note that I don't mean "as you type" error detection - I mean actual
compilation. In Eclipse, by default it compiles the code every time you
hit save. If VS.NET did that, it would be a pain in the neck because it
would recompile a whole load of stuff which hadn't changed

Ahh, I see what you mean. While C# is very quick at compilation, constant
compilation could be a problem.

For some reason, I thought you were talking about background compilation
like VB has. Incremental compilation is an interesting concept, it requires
compiler support as well though, wouldn't it?

its something I may look into if I ever get the compiler idea off the
ground.

Unfortunately I'm stuck using VSS at work...

The independent route has its advantages, a few anyway.

I haven't had a careful look at what the support is like in Whidbey. My
guess is it won't be as extensive as Eclipse due to timescales, but
that probably doesn't matter - there aren't *many* refactorings I use
in Eclipse anyway. It's just that they're incredibly handy when I do
use them!

Whidbey's refactorings are pretty limited, I think there is only 6 or 7
options. However, I don't even use all of them. I use rename and extract
method quite a lot, the encapsulate field is useful at times, but it doesn't
seem to allow specifying get\set granularity, so I end up editing the
results anyway.

I find things like Extract Interface are pretty rarely useful since I tend
to design interfaces and then base concrete classes off of them. And
extracting an interface frm an existing interface isn't terribly difficult,
just copy and paste and a little typing.

 

[Jon Skeet [C# MVP]]

Ahh, I see what you mean. While C# is very quick at compilation, constant
compilation could be a problem.

Or indeed compilation when projects get very large.

For some reason, I thought you were talking about background compilation
like VB has. Incremental compilation is an interesting concept, it requires
compiler support as well though, wouldn't it?

Yes - Eclipse has its own Java compiler.

its something I may look into if I ever get the compiler idea off the
ground.

I think .NET would have a harder time fitting into incremental
compilation, partly because of the output format. Because every
compiled class in Java is just output as a single .class file, it lends
itself to only recompiling bits. Even if you have a different file for
each class in .NET, all the classes still need to be combined into an
assembly file at some stage.

The independent route has its advantages, a few anyway.



Whidbey's refactorings are pretty limited, I think there is only 6 or 7
options. However, I don't even use all of them. I use rename and extract
method quite a lot, the encapsulate field is useful at times, but it doesn't
seem to allow specifying get\set granularity, so I end up editing the
results anyway.

Rename is definitely the most important one, IMO. Of course, Eclipse
links renaming a class with renaming the source file, because that's
the standard Java way of doing things. While I know it's not as
standardised in C#, I wish there were an *option* to keep the two in
step...

 

[Daniel O'Connell [C# MVP]]

Or indeed compilation when projects get very large.

Yes, I could see that. I don't think I've had a project beyond maybe 20k
lines compiling at any given moment, and the C# compiler goes through that
really quite quickly. Infact the compiler seems to be very quick, just when
used through the IDE it seems to be a mite slower, almost as if the IDE
takes a long period of time between begining compiation of each project.

Yes - Eclipse has its own Java compiler.




I think .NET would have a harder time fitting into incremental
compilation, partly because of the output format. Because every
compiled class in Java is just output as a single .class file, it lends
itself to only recompiling bits. Even if you have a different file for
each class in .NET, all the classes still need to be combined into an
assembly file at some stage.

They certainly would need to be combined, but I don't think the PE file
generation is the longest part of the compilation process. Circumventing the
parsing and atleast portions of the compliation phase may be rewarding.
My current thoughts on the issue is to cache the resultant IL and metadata
into some form of intermidiate database, then when you perform a compilation
just compile the new code and generate the assembly file itself. Granted,
you probably couldn't use reflection emit for this purpose, but the .NET
runtime metadata format and IL itself isn't anything complicated enough for
that to deter me.

I wont say it would be as easy as java or C++(with its obj files), but I do
think its entirely doable. If I ever write this compiler, I do intend to
*not* use reflection.emit for a number of other reasons anyway, so why not
take a shot at it?

Its also possible that the compiler could generate modifiable assemblies.
Consider an assembly which reserves, during development time compilation,
not release compilation, extra metadata slots, etc. Now, when code changes
if the compiler loaded that assembly and simply replaced and added to the
existing metadata as approriate, it may be possible to achieve incremental
compilation within one file.

That is only a theory at the moment, however.

Rename is definitely the most important one, IMO. Of course, Eclipse
links renaming a class with renaming the source file, because that's
the standard Java way of doing things. While I know it's not as
standardised in C#, I wish there were an *option* to keep the two in
step...

I thought I heard of plans to do that with whidbey, atleast for forms, but
as best I can tell that never materialized. It was probably someone's
feature wish that I mistook. I do wish renaming a file would rename the
class(and vice versa), maybe even an option to enforce the one class per
file standard, even though its not nessecerily an option I follow at all
times.

Perhaps the IDE and the compiler need to support a langauge structure tool
more so than forcing any restrictions on files. If one could simply define a
set of rules and transformations to be applied before compilation alot of
these issues could probably be solved.

 

[Saras Asnani]

I feel VS.NET is much easier to develop in. Language wise I consider
C#/Java 90% same. Also, it depends on the kind of applications. To
make it more general say n-tier or i feel the market should move more
towards Web Services (I like to call it NET-Services...
internal/external net services).

I think hands down that C# windows or .Net windows app are much faster
than Java windows app (designed and coded similarly, that is not
optimially coded... keep it simple code....)

Also I really like what MS has done with ADO.NET both ver 1.1 and
ver2.0.

On the application server/business server side I think .Net and Java
execute almost at the same speed. Of course if you are using a DBMS
this will depend on JDBC and OLE/SQLClient for each (I belive JDBC is
faster in this case...not sure...its been a while). The great
advantage that Java has on the app server side is it has vendors with
huge base both apps and developers.... such as BEA, IBM WebShpere,
TIBCO - ASP, Oracle App Server, and all the open source stuff aimed at
anything except MS.

The other advantage that Java, Linux, Unix, MAINFRAME, ORACLE, maybe
even MySQL has over .NET and MS is SECURITY. SECURITY SUCKS IN MS.

If MS can be made secure and I am sure it can (surrounding your
external networks with linux boxes etc...)

When it comes to making web-services / net-services i think either way
should be fine but when it comes to development...I would pick MS.NET.
VS.Net and VS 2005 is a great tool, C# is as easy as Java sometimes a
bit better.

on the open source side if the linux installation was easier on the
desktop for other not so tech developers and if there was an
equavilent tool, i would pick linux/xtool? Just because Linux itself
is so much faster (I like Suse and the old Slackware for Mutliple Sym
Proc)

Anyone still doing assembly?

enough for now....

-Saras Asnani.

 

[Mike Newton]

I believe the "most of us" refers to the fact that Windows only holds
about 21 % of the web server market. (According to netcraft) I would
consider that 79% qualifies as "most."

He wasn't referring to Java being used by most of us, he was referring
to the platform.

I've experimented with mono, it's got decent performance. The mono
version of SharpDevelop (MonoDevelop) starts up quickly, and is rather
snappy.

Mike

 

[Mike Newton]

Note that I don't mean "as you type" error detection - I mean actual
compilation. In Eclipse, by default it compiles the code every time you
hit save. If VS.NET did that, it would be a pain in the neck because it
would recompile a whole load of stuff which hadn't changed

That's not exactly true. You can set projects to be compiled
incrementally, and csc will only compile those tidbits that have been
changed.

Granted, this isn't the default, but it *does* exist. Check out a
rather large library like iTextSharp, which is set to incremental build.
The first compile is long, but subsequent compiles are very fast (and
I have made a few minor tweaks).

 

[Jon Skeet [C# MVP]]

I believe the "most of us" refers to the fact that Windows only holds
about 21 % of the web server market. (According to netcraft) I would
consider that 79% qualifies as "most."

But that doesn't necessarily mean that 79% of web servers that serve
dynamic content run on boxes other than Windows, or that 79% of dynamic
content is created for non-Windows boxes, etc. Web server stats are
notoriously tricky - do you go by URL or IP address, for instance? A
single host which server several different DNS names might count as one
box or several, depending on which

He wasn't referring to Java being used by most of us, he was referring
to the platform.

I still don't think it's as cut and dried as you imply though.

I've experimented with mono, it's got decent performance. The mono
version of SharpDevelop (MonoDevelop) starts up quickly, and is rather
snappy.

I think it's the performance of the libraries which are used in ASP.NET
and web services which is likely to be more important. I'm not trying
to suggest that Mono *doesn't* perform well - just that the speed of
MonoDevelop isn't a good indication as to how good it is for server
side applications.

 

[Jon Skeet [C# MVP]]

That's not exactly true. You can set projects to be compiled
incrementally, and csc will only compile those tidbits that have been
changed.

Granted, this isn't the default, but it *does* exist. Check out a
rather large library like iTextSharp, which is set to incremental build.
The first compile is long, but subsequent compiles are very fast (and
I have made a few minor tweaks).

Now that's interesting - where's the option for that? I can't find it
in VS.NET 2003.

(I assume it recompiles dependent files, etc - just recompiling the
files which have changed isn't enough.)