Advantages Of .NET Over Java

ansonyumo writes "ZDNet is carrying an article written by one John Carroll that outlines specific advantages of .NET over Java. It's written from the point of view of a Java advocate who has 'seen the light.' First of all, comparing .NET and Java isn't very fair; you have to compare .NET and J2EE. When you level the playing field, most of his arguments readily fall apart."

Comments

even if his arguments fall apart...

[rumpledstiltskin]

when you compare to the correct language structure, so what? What's important is PHB's will probably be reading articles like that, and will point to said articles in justifying going with a microsoft centric language (along with IEEE, ECMA standardization, etc.) The article simply underscores that a wide and varied skillset is what's going to keep a developer alive in today's environment. Sun's not exhibiting the best of business decisions lately, and if they want to stay afloat, they need to come up with someone to answer .Net effectively in popular media. Posting articles on slashdot saying "look at this! it's not accurate!" isn't a great way to promulgate usage of your favorite language either...

In Bizarro world..

[L. VeGas]

Not surprisingly, ZDJava has an article that praises Java over .NET

Re:In Bizarro world..

[Anonymous Villain]

.Net is just a knockoff of Java and Java is an attempt to improve C++. Is it any wonder that 6+ years later C++ is still standard for system programming? C is standard for many open source projects and after 6+ years no one has managed to find a replacement for C++. Platform independence is hogwash. Java could supplant C++ but instead Sun has loaded it down with a bloated Class library and poor native support and JIT bytecode. Sun forces you to program a certain way and criticizes any alternatives. Enums and Structs are considered bad by Java standards and overloading is bad for you and Delagates are bad and inner classes are better. In Java Speed doesn't matter or native support violates platform independence. Speed isn't a priority with Java. Sun force feeds people what they think is good for them. Java is just another way for Sun to sell servers instead of coming up with something useful. Java makes you write a bunch just to display a line. Consider the following: system.out.printline() or public static final int N; Very bloated and obtuse. whereas with c# you can say console.writeln() Java has very little native compiler or interface support for Java. D is way better than both and it is a possible successor to C++. Whereas Java and C# are really niche languages that fail to succeed where C++ left off and improve on Native compilation or systems programming D actually in a native programming language. Java doesn't differentiate the class library from the language which is a very bad thing. Java could be a smaller language but instead they load it with every library and function and make a very large bloated system. The enmity of OOP is class libraries that extend other classes and become a huge tangled tree of bloat. Plus if you change one class it can depracate many others that use it. Deprecation is a language feature of Java.

Re:In Bizarro world..

[soppyfrog]

Your post really demonstrates absolutely that you are completely ill informed and unable to prepare any sort of real argument against Java for C++. I am sick and tired of people crying "Java is to slow" as this viewpoint just personifies the inability of people like yourself to think no further ahead then tomorrow. Firstly, the concession must be made that Java GUIs, particularly those with a great deal going on are slow and simply can not compete with their natively compiled competitors. That said, Java for any other purpose is NOT slow; yes, it is slower then C++, but that does not make it slow. If speed is the only thing C++ can claim over Java then that will prove to be a big problem for simpletons like yourself in two years when machines have reached a point where this sacrifice of the speed difference between Java and C++ becomes negligible. Java is aiming for something larger then speed (something that it seems ill informed people such as yourself simply can not grasp), simplicity, and I'm not just talking simple to program with. The effort required to create a new thread in C++, or to open a socket connection is quite frankly, unacceptable. The fact that the same thing can be achieved in Java in 3 lines or less of code proves my point. Try and port an application from Windows to *nix or back the other way, go on, try. I'll take my Java application and deliver it before you can even begin to comprehend the amount of work you are in for. "Whereas Java and C# are really niche languages that fail to succeed where C++ left off and improve on Native compilation or systems programming" This would have to have been my favourite quote from your comments. Java is a niche? I have news for you, give the wide breadth of projects out there in the REAL world (some place you obviously do not live) systems programming is the niece. Java can not compete with C++ for systems programming, as JAVA WAS NOT DESIGNED FOR SYSTEMS PROGRAMMING!!!!! You say Java ships with bloated class libraries? Let's just ignore the fact that these *large* (not bloated) class libraries that ship with Java free developers for the hassle of organising numerous little third party libraries for their applications. Let's just ignore the fact it provides developers with a robust, COMMON platform on which to develop and target. The reason you perceive such tight coupling with the Java base class libraries and the language steams from the fact that Java is a platform, not just a language, and this is the one point that seems to elude the throngs of people such as yourself who believe themselves to posses more geek karma then anyone who could possibly even think of using a language where pointers are not allowed, and your simple minded opinions and utter gutter trash of arguments p*!# me off to no end. You state that System.out.println() is bloated, yet at the same time say that Console.WriteLine() is not. I am curious, apart from the 1 character (yes, that is correct, 1 character) difference in the two statements, what makes System.out.println() so bloated? In addition, System.out.printline() as you would have it is spelt incorrectly, and for you to make an amateur mistake such as this proves to me that you have no authority what so ever to comment on anything Java related at all. Further to that point, you have also provided incorrect casing for Console.WriteLine(), which suggests to me that your knowledge of the languages from which these two examples come is, at best, extremely sub par. "The enmity of OOP is class libraries that extend other classes and become a huge tangled tree of bloat" Firstly, enmity means ill-will or hatred, so are you trying to say the "hatred of class libraries the extend other classes and become a huge tangled tree of bloat"? I really hope you are, as that would prove you have a similar command of the English language as you have of what is occurring in the world around you. So classes extending other classes end in a "tangled tree of bloat"? I'm not sure if this highlights your inability to design a class hierarchy properly, or your ignorance of the fact that your champion of virtue, C++, is also an Object Oriented language. Horses for courses. C++ for times when runtime speed is of the essence, Java for times when a more robust, full featured PLATFORM is required.

Re:In Bizarro world..

[Anonymous Coward]

Speed does matter. The parrot virtual machine proves that. Speed is an important feature of the Parrot virtual machine for designing extensible languages such as Perl 6. Java is not optimized for speed and any time a language has limitations, It exists in a niche. Java's native call interface is very slow, whereas Parrot has been designed to be fast and extensible in C. Parrot uses a register virtual machine and has optimized bytecode instead of a stack virtual machine. What is Java extensible in? Java is only extensible in Java. You can't interface Java with C or C++. And you certainly can't mix or combine languages like you can in c#. The Java bytecode is very static and hasn't changed.

What makes a language a niche language?
Java doesn't have compiled native support. C and C++ could do everything Java or C# could. In fact Java is really a C++ wrapper. Java is not written in Java or its not low level enough to supplant C++ because Sun is blinded by the mantra of "Platform independence." You could say that open source C code can still be modified and recompiled that is 10 years old on different machines and different architectures. Whereas with Java you could run into Deprecation with Java 1.0 and incompatibilities in the JVM.

If Java is going to be the end all language then some provision should have been made for compiled native support. The fact that native support has not been implemented by Sun or even promoted says a lot about Java's limitations or the limitations of Java's designers. Java could be a De facto standard and successor to C and C++ but it is not.

Java is still a proprietary language. It is controlled by Sun. Sun is afraid of Jboss and Linux and open source. The standards organization is JCP and there is no open source implementation of Java. At least with C# there is an ECMA standard and an open source version of C# with Mono. There may even be an ISO standard for C#.

In programming brevity is always better than length.

Making system.out.println() is overly verbose.

It requires 3 words and two periods whereas C's printf() requires one function.

C# requires two references with console.writeln.

D is a possible successor to C++. It has nested functions and structs and unions and in/out parameters and ligthweight arrays and associative arrays. With Java everything is an object. Java objects can be very expensive and memory intensive.

Java class libraries extend other libraries and the Java library has hundreds of classes and 30 megabytes of code. Whereas Python has 2 or 3 megabytes of code and is written in C.

Deprecation is a feature of Java. Java invented Deprecation. If one class depends on a deprecated class then it has to be rewritten to use the new class. Old deprecated classes are kept for backward compatibility. Java has lots of dependencies. One class can extend another class or depend on another so changing one has a big effect. A class dependent on a deprecated class is itself deprecated.

Sun has been a very effective and efficient competitor in software. Apache is eating enterprise server for lunch (What 2 or 3% market share? Even IIS is doing better) and BEA and Websphere are both toasting Sun ONE. Linux is also encroaching on Solaris. The forgotten SunOS. Oh and where is NEWS??? There revenues were down 30%. IBM is gaining an edge on both Sun and HP.

Re:In Bizarro world..

[soppyfrog]

I never stated that speed doesn't matter, what I did say (and I will quote my own voice as it appears to be the only one of reason here) is that "when machines have reached a point where this sacrifice of the speed difference between Java and C++ becomes negligible". This is a point I will again state. For the vast majority (but not all) of circumstances, the speed gained by C++ is not necessary. However, when you consider that my C++ application written for windows my have large chunks of it rewritten if I desire to run it anywhere else; yet my same application written in Java required not a single line to be changed, it means that my Java application is FASTER to develop, therefore costing less, and that I speed less time in debugging (as I have one application to debug rather then virtually two), and therefore costs less again, I ask you, would you like to pay for my C++ one or my Java one?

The end of your last reply listed some things that Sun has to worry about (such as small market shares for its servers etc...) yet this still poses the question. WHAT DOES THIS HAVE TO DO WITH ANY OF YOUR ARGUMENT? In your initial post you said that Sun only invented Java because it wanted to sell more Sun stuff! This is where I draw the line, and I will return to this in conjunction with my next point. You also state that Sun is afraid of open source??!?!?! Yet Jakarta Tomcat, the REFERCENCE implementation of the Java Servlets and JSP standards was GIVEN AWAY TO APACHE BY SUN! I think you'll agree that for a company so afraid of open source that was a pretty silly move.

I will quote you directly here: "there is no open source implementation of Java". This proves the point I made in the previous post regarding you having no authority to comment an ANYTHING related to Java at all (given you continually prove your knowledge of it is, at the very best, equal to the man on the streets knowledge of the social lives some obscure species; possibly that of the aging systems programmer with no ability to think into the future). It's called Kaffe mate, and it ships with virtually every major linux distribution available. Which brings me to my next quote: "Sun is afraid of JBoss and Linux and open source", Ok, firstly, how is sun afraid of JBoss? JBoss is (and this quote comes directly from their sourceforge page) an "Open Source, standards-compliant, J2EE based application server implemented in 100% Pure Java". So it is an application server, just like the may others (Weblogic, Webshpere, Oracle 9i and the list goes on), so what makes JBoss so special that Sun is so scared of it then? Answer me that. ALSO, Sun is scared of Linux? So it releases Java, the mantra of which (and I will quote you again) is "Platform independence". Yes, that makes sense, Sun is scared so they release something you can run on any platform (and provide a JVM the world, free of charge, with a JVM for many platforms, LINUX INCLUDED).

Let's move on to your next un-enlightened quote shall we. "You can't interface Java with C or C++. And you certainly can't mix or combine languages like you can in c#." Just as with your statement about there being no open-source implementation of Java, here, you are again COMPLETELY WRONG. The Java Native Interface (JNI) allows Java code to communicate with code written in C/C++. On top of that, you could use other standards such as CORBA to achieve this should you feel the need. The ability to mix and combine languages as you state is a feature of C# is indeed not a feature of C#, but is a feature of the .NET platform. Compilers exist to compile Java code to IL (which C# is compiled to), and Microsoft themselves have even released J#, giving people the ability to write code for the .NET platform using Java syntax. While we are on the topic of .NET and C# (which you seem to tout as being fine, where Java is the devils right hand man), what is it that makes the Java base class library (which provides developers with a stable, consistent platform to use, one

Re:In Bizarro world..

[Anonymous Coward]

The Java native interface was never designed for speed. It is much slower interfacing external languages such as C or C++. With Python or Perl you can utilize C to extend the Language directly or embed code in the interpreter.

If the Java virtual machine were written in C or C++ it would be extendable. Extendable languages such as Ruby, Python, and Perl can implement new functions or modify the core vm or extend the language with native C or C++. This is much more open than the Java or C# native interface to C and C++.

With Java and C# your limited to an native interface that Sun or Microsoft gives you. With Python you can create a C library and interface it directly with Python or compile it into the language. Open source software is extendable whereas with any proprietary software has limits to extensibility. Java is much more proprietary than C# and there is no ISO standard. Sun ultimately decides what goes into the Java standard which is good in many but has some limitations.

Java is much more controlled than C# and the JCP is just a sidestep to the standards process. Microsoft also released an open source version of C#. Second, there is no ISO or ECMA version of Java. C# has an open source version called Mono and even if it doesn't implement all of .Net it provides some open source framework which is a lot better than none at all. Mono is an improvement over trying to implement an open source version of Java which is next to impossible. (It would be difficult to implement an open source Java because the library is honking huge and there is no reference standard for Java.)

You can do anything in Python that you can in Java. You can also do more besides because you can extend Python with the native C code and change it to suit your needs. You can also change the source code and scramble the language. You are free to modify Python or Perl as much as you wish. Parrot is another example of a extensible virtual machine.

Another site that criticizes Java is this:

http://www.jwz.org/doc/java.html

http://c2.com/cgi/wiki?JavaCriticisms

If Sun were so unafraid of JBoss they would allow it to be certified.

Java doesn't allow operator overloading which is a limitation in math. number = z.add(number.multiply(BigInteger.valueOf(1007))).p ow(12);

Separating Java the language from Java the library is also important. You can make a language small and distinguish the language from the library. In Java supporting a humongous library becomes a monolith and a support burden. If you want to change APIs to APIs to APIs you have to change and deprecate the old APIs and maintain a huge library of old code as well as new code. When people learn Java they aren't learning Java the language, they are learning Java the library.

C and C++ are smaller core languages in that you can differentiate the libraries because they are more self contained. C# more strongly differentiates the language from the library. C# is much more close to C or C++ and you can create a version of C# easier than a version of Java because Java is so tied with it's library. With Java your really learning a huge humongous multimegabyte library and not Java the language. Also Java 1.0 is vastly different from 1.4 and jumping from JVM 1.0 to 1.4 requires you to relearn updated classes.

How is Java not a small language? It has hundreds of classes and 10s of megabytes of code. C# also has lots of classes but C# is more distinct from its library. If you look at Python the libraries are written in Python or C and the core is much much smaller and in many ways much more efficiently designed than Java.

Re:In Bizarro world..

[soppyfrog]

I know not why this debate is still raging on. Not once but twice now have I presented you with logic and fact, and not once but twice now have you replied with the same, illogical, ill-informed opinion. I grow tired, but for some reason I feel compelled to reply.

"The Java native interface was never designed for speed. It is much slower interfacing external languages such as C or C++" I never said it was designed for speed. Of course it is slower then linking to it directly, however linking to it directly costs us platform independence, thus violating one of the major points of using Java (apart from the superior set of class libraries guaranteed to be available wherever the JVM is, a huge step over C/C++).

"If the Java virtual machine were written in C or C++ it would be extendable" you do not extend the Java Virtual Machine; it is the common ground you target. The fact that you state this signals to everyone that you do not fully understand the concepts and philosophies behind Java. Again, extending the JVM in custom ways would mean that these extensions would need to be applied to every JVM that is to run your program. Even then, it could only be run on the platform that you had provided a custom extension for. This is not the way of Java. The JVM is your target, you know what it is and what it provides, this is what frees developers from having to bloat their own applications with a library (of their own re-invented wheels) of helper bits and pieces to support their application. It also provides a common set of components that are tested and debugged (removing the need for the developer to do so, into the bargain, removing the cost).

"It would be difficult to implement an open source Java because the library is honking huge and there is no reference standard for Java." Java the language is a set of specifications, and there are open source implementations. In case you missed it in my last post http://www.kaffe.org is one that is shipped with virtually ever major linux distribution. You don't use Java and extend the JVM, doing so ruins much of what Java stands for. Sun gives you the JVM for virtually any platform you can possibly do any proper development for, and it does so for free. If you wish to extends the capabilities of the base classes, you can, you just extend them. I would like to see one good reason why you would want to extend the JVM.

"You can do anything in Python that you can in Java. You can also do more besides because you can extend Python with the native C code and change it to suit your needs" No, no you can't. I would like to see you write me a complex GUI that I can run on my Windows, Linux, Solaris and Mac all with the same code. Please try to refrain from attempting to pass of completely false statements of opinion as fact; it does not help your creditability. Please give me a real situation where you would want to do what you say, and at the same time show how you could not achieve this in Java.

"Another site that criticizes Java is this: http://www.jwz.org/doc/java.html"

I will quote directly from the above URL:

"I think Java is the best language going today"

"Java is far, far more pleasant to work with than C or C++ or Perl or Tcl/Tk or even Emacs-Lisp. When I first started using Java, it felt like an old friend: like finally I was back using a real object system, before the blights of C (the PDP-11 assembler that thinks it's a language) and C++ (the PDP-11 assembler that thinks it's an object system) took over the world."


Moving on; "Separating Java the language from Java the library is also important" Yes, this is true to an extent, however then you consider how pointless this is. Everywhere Java is, so is the base class library, it is there to be used, why would one ignore it?

"If you want to change APIs to APIs to APIs you have to change and deprecate the old APIs and maintain a huge library of old code as well as new code." As you will recall from my previous post, deprecation is a signal to

universal? is mono complete?

[gl4ss]

"Of course, .Net is still a mostly Windows party, while Java offers the chance to work on a large number of platforms. As I've noted, however, Mono offers a complete implementation of the .Net Framework for Linux, and there are companies already who promote their .Net product's support for non-Microsoft systems."

is mono really comparable to the microsoft windows .net implementation? as in everything that goes around the shisbang too?

mostly the article just goes on through javas features and glorifying their counterparts in the .net..

i know java isn't _totally_ universal itself either (i'm not aware of implementation for my other computer running beos.)

Re:universal? is mono complete?

[rmull]

Mono is not complete. It is not even yet comparable to the "Shared Source" version, which is less complete than the windows verison.

Though I've had limited experience with .NET, and only then with C# on BSD, it's pretty obvious that a lot of the standard library was designed around COM and Windows in general. Many parts of the standard library are crippled to the least-common denominator of the .NET platform: visual basic. What does this mean? No interoperability with unsigned data types, for one.

Incidentally, the article's claims that there are no equivalences to ".class" files in .NET is completely false. They have these things called "netmodules" which are just that, as far as I can tell. There is very little documentation on the subject.

To finish ranting, any claims that .NET is an "open" platform are for the most part just false.

Re:universal? is mono complete?

[Glock27]

is mono really comparable to the microsoft windows .net implementation?

Not even close at this point, AFAIK.

Mono also has the threat of MS patent enforcement hanging over it. Use it at your own risk.

Java is far more cross-platform, and performs roughly as well on the same hardware (server stuff). The client side is also getting better with improved Swing (on Mac for instance) and SWT for even better "native look and feel".

Download Eclipse at www.eclipse.org to see a first-class modern Java application.

Re:universal? is mono complete?

[BenTels0]

(i'm not aware of implementation for my other computer running beos.) I know of two tentative ones: the BeKaffe project (attempting to port Kaffe to to BeOS) at http://bekaffe.sourceforge.net/ and the Guavac project at http://www.bebits.com/app/1195. The first is having development problems (that is, capacity problems with respect to people) and the second is at the 1.1-level, unfortunately. But you can check them out, I suppose. Of course, I wouldn't expect too much in future any more. BeOS seems to have gone the way of the dodo, so...

Re:universal? is mono complete?

[Anonymous Coward]

Your knowledge on .NET is at best - shit.

as MS pushes .NET

[Anonymous Coward]

will the eventualy release office and other big apps in the .net framework and then maybe they can be run in Linux with the .net framework ports

Lets break this down...

[Dr. Bent]

So, according to this guy, the advantages are:

1. XML property files
   
2. Better reflection support
   
3. No individual class files, only improved class bundles called "Assemblies" (this is a good thing)?!?
   
4. ".Net Remoting" - basically RMI with support for any .NET language
   

First off, I have to give him some credit. This is the first time I've ever seen a specific breakdown of exactly what .NET is good at that Java isn't. And he's right, these things are pretty cool (except maybe for #3).

But would I trade J2EE for this? Not on your life. All of this stuff can be done in one way or another with Java, and Java is still way more mature in most respects. I mean, I'm assuming that since he chose to highlight these features, they're probably the most significant, and if this is the best that .NET has to offer over Java, the choice is clear for me.

If I was going to develop a new Windows app, I'd be doing it in .NET, no question. But when it comes to cross-platform or enterprise level development, .NET is not ready for prime time.

Re:Lets break this down...

[kzeddy]

for point #3 java has jar files which is a simpler version of an assembly. so bundling itself is not the real attraction.
What is really cool about assemblies is that you can dynamically generate them using classes exposed in the core framework.
i just wrote a sophisticated Database layer making my database object oriented. it took me 2 weeks and works perfectly.

Re:Lets break this down...

[Anonymous Coward]

"But when it comes to cross-platform or enterprise level development, .NET is not ready for prime time."

Cross-platform... sure you're right.

enterprise level... I wonder if Java is ready for prime time. One of our departments has to restart their Websphere environment 4 times a day to keep it running. We haven't seen those problems with our .Net deployments.

Re:Lets break this down...

[pyrrho]

what was sophisticated about it?

Re:Lets break this down...

[bwt]

I don't find #1 persuasive. If you want XML in Java, you use XML tools. Properties aren't XML, they are properties. They SHOULD be simple as in my.properties.property2="bingo" . If you want XML, just use XML. Java has the best XML tools of any language there is.

#2 is OK, but if you can find the methods, you can find anything, so what is the advantage?

#3 is just odd. Java has jar, war, ejb-jar, etc... archives and also has classes by their lonesome. .Net has only archives. How is this better?

#4 is a joke. RMI is cake if you can rely on the OS being the same. The hard part is cross-platform, not cross-language RMI. This is still a problem which java solves well and in multiple ways by relying on open standards (surprise) which explains why it is the dominant language for enterprise computing and middleware. I want a language that I can write code for and be assured that I can deploy that code in a client app on Windows or Mac or Linux, in a web server running windows or linux, and on a data tier box running Unix or Linux. .Net doesn't meet this requirement and basically isn't usefull to me.

Re:Lets break this down...

[MobyDisk]

I don't think you read the article.

#1: You referred to property get/sets, but that isn't what the author was talking about. He was talking about external configuration files, environment configuration files, an serialization.

#2: The author explicitly lists what information, beyond the methods, you can get from .NET. To briefly reiterate, he listed meta-information about methods which is necessary to make it truly useful. Knowing a method name and parameters isn't the whole deal.

#3: You ask "how is this better?" which is exactly what page 3 of the article describers. The author explicitly lists advantages of archives over JAR files. He points out that it isn't a magnanimous difference, but he certainly answers your question.

#4: You've obviously never done cross-language RMI. One of the running Jokes about Java is that Java is great at communicating with other languages: so long as the other langauge is Java. Microsoft has taken cross-language support to a new level - which is one of the things that really attracts VB, Java, and C++ developers to .NET.

Re:Lets break this down...

[The Cydonian]

You referred to property get/sets, but that isn't what the author was talking about. He was talking about external configuration files, environment configuration files, an serialization.

Pardon me if I'm wrong, but doesn't the Torque project do this? Same for Maverick, if I may point out.

Re:Lets break this down...

[scotartt]

"enterprise level... I wonder if Java is ready for prime time. One of our departments has to restart their Websphere environment 4 times a day to keep it running. We haven't seen those problems with our .Net deployments. "

Websphere runs more enterprise critical application installations than .Net even dreams about. If you have to restart websphere 4 times a day then obviously you have done something wrong.

And you know what? It only highlights the J2EE advantage. Don't like Websphere? Try Weblogic. Ohh Weblogic is too expensive? Install Sun One off your Solaris disks. Don't want the all-Sun lock-in? Download the free alternative JBoss. Can't figure JBoss out? Try and look at the Oracle 9i app server. Don't own any Oracle licences? Go and buy Macromedia JRun.

Now what hardware shall we deploy it on ... hmmm ... choice.

And so on. Your app should run on all of those, unless your app is so poorly designed it won't run on any. But that's *your* problem and converting to .Net won't make your app any less poorly architected.

Re:Lets break this down...

[aminorex]

#1 Java also has XML serialization.

#2 You can also introspect bytecode. Admittedly,
it is not as well-developed as .NET in this respect,
but there are no inherent limits.

#3 I could not care less about, so no comment.

#4 For cross-language, use CORBA. Java makes it
trivial.

Re:Lets break this down...

[LizardKing]

You've obviously never done cross-language RMI. One of the running Jokes about Java is that Java is great at communicating with other languages: so long as the other langauge is Java.

A running joke that I've not encountered in six years of professional Java programming. CORBA make cross platform, language independent programming a breeze. My current employers hand crafted database (written in C and running on various Unix flavours), communicates very elegantly with a Java frontend via CORBA. For embedded systems too small to run Java, it's the same IDL files but a C based frontend using curses.

Microsoft has taken cross-language support to a new level ...

Really? Could my company do what I described above with .NET? Of course not, as we wouldn't be able to interface with our database. Our one attempt to get it running on Redmonds poor excuse for a server OS made us realise that we'd need considerably more powerful hardware, and more redundancy to cope with Windows little "foibles". So .NET's cross-language, but only if want to put up with Windows.

Chris

Re:Lets break this down...

[bwt]

#1 There are probably 15000 Java projects in existence today that use XML heavily for all the things you listed.

#2 If you know the method names and parameters, you know enough to get whatever information the class designer thinks you need to have to use the class. I have never once been in a situation where I needed more. This is a "so what" improvement.

#3 The two supposed advantages ("unique identities" and "reflection") seem harmful to me. It's like the language designers forgot everything about OO programming. I do want my code to NOT be tightly coupled to its packaging for the same reason I don't want my controller layer tightly couple to the presentation layer. In fact, I want YOUR code to not be tightly coupled to its packaging (at least if you want me to use it). This basically guarantees that .NET code can never be cross-platform.

#4 You obviously didn't read my point carefully. Nobody cares about cross-language interoperability, the important issue is cross-platform interoperability. It doesn't matter at all if the other platform's language has to run in a JVM: just do it. But since you mention it, the JVM supports a lot more languages than .net does.

Re:Lets break this down...

[ProfKyne]

So, according to this guy, the advantages are: 1. XML property files

Guess the guy doesn't know about java.util.prefs.Preferences.

Re:Lets break this down...

[OmniVector]

If I was going to develop a new Windows app, I'd be doing it in .NET, no question. But when it comes to cross-platform or enterprise level development, .NET is not ready for prime time.

why go that far? That's why we have SWT from IBM. Think AWT, but not crap. It's native windows/gtk2/cocoa/motif, and it's cross platform. It's by far the best windowing toolkit i've seen. If you haven't seen it before, download eclipse to see what i mean.

Re:Lets break this down...

[Anonymous Coward]

1 XML is not a universal solution for all problems. I have written several Java apps and one uses XML. I see no real advantage for .net here.

#4 Yes I have and it is a major pain.

What I am hoping for from .net is for Microsoft to have a frame work uses STANDARD cstrings! And that does not have 30 differn't types of pointers. Frankly MFC is an total nightmare.

Re:Lets break this down...

[Anonymous Coward]

.NET is not cross-language.

you cannot use C++ or VB.

you can use VB.net (or VB7) and managed C++.

managed C++ is an abomination that no programmer should ever, ever under any circumstances whatsoever use. use C#.

VB7 is totally different to old VB. if you're gonna have to learn a new language, learn c#. .net corss-language thing is so totally a lie. it's only x-language if all the languages you'll be using a slight syntactic variants of c#.

Re:Lets break this down...

[Anonymous Coward]

So, according to this guy, the advantages are: XML property files

XML is infinitely more flexible than property files, and that makes it a better standard configuration technology than property files. Lists of values are easier to represent in XML, the range of parsing technologies is larger, and the format is familiar to anyone accustomed to HTML.

And total overkill for most situations. Would you want to try modifying XML with vi?

Re:Lets break this down...

[BenTels0]

What is really cool about assemblies is that you can dynamically generate them using classes exposed in the core framework. That's nice, but not exactly a great advantage over Java per se. After all, JDK version 1.2 and up also provide ways of dynamically handling JARs (including creation).

Re:Lets break this down...

[Anonymous Coward]

I wouldn't want to try modifying ANYTHING with vi ... but that's a jihad of a different colour. :)

The real question is..

[floydman]

Will system designers go after M$'s stuff after what M$'s attitude and history in the past 10-15 years been. I mean M$ proved that it does not seek best performance, is not after user's intrest, does not care for for service. It cares for the greens. In the past few years they did a lot of stuff that made it clear now that they were putting us in a box that can stick us to use there products only(with no respect to its quality)

so the real question is are you willing to go through this again?

/*Why is there a penguin on my desktop?!*/

Re:The real question is..

[Slarty]

Yes, of course they will. You read Slashdot, so while you may not necessarily USE competing systems (Java or open source OS's), you're undoubtedly aware of them, and that Microsoft doesn't always make the best software or decisions.

I work for a company that works solely on Windows software, and I can tell you, our system designers don't have the benefit of such knowledge. They are totally buying in to the .NET hype, and not without reason... .NET may not be the savior of the software world, but it IS a heckuva lot better than the old method of MFC or Win32 development. By far.

Our designers are not stupid; they just seem incapable of thinking outside the Windows world. You don't know what "mindshare" means until you've seen this in action... Microsoft products have a total lock on their way of thinking. They just won't consider any alternatives, they use Microsoft stuff, and they LIKE it. A friend and I are gradually introducing open source stuff (an internal web app I wrote uses PHP and MySQL as opposed to ASP/SQL Server... and I had to fight for it!) but mostly, Microsoft is ALL THERE IS to them. That's why .NET will succeed, at least partially. You don't notice any problems with performance or security or service if you've never used an alternative (and be honest, many of the alternatives aren't that hot either).

Unrelated rant... after all these years, why do people still think it's cool to refer to Microsoft as M$? I'm not defending Microsoft software or business practices, but come on. That's just childish. It's not like you're going to gain any real karma or respect by doing that, and it's not like you can't find enough to be mad at Microsoft about without resorting to petty name calling. It's not even original anymore.

Re:The real question is..

[Slowping]

after all these years, why do people still think it's cool to refer to Microsoft as M$?

<tongue-in-cheek>
Because MS stands for Multiple Sclerosis.
</tongue-in-cheek>

Re:The real question is..

[MeanMF]

Our designers are not stupid; they just seem incapable of thinking outside the Windows world. You don't know what "mindshare" means until you've seen this in action... Microsoft products have a total lock on their way of thinking. They just won't consider any alternatives, they use Microsoft stuff, and they LIKE it. A friend and I are gradually introducing open source stuff (an internal web app I wrote uses PHP and MySQL as opposed to ASP/SQL Server... and I had to fight for it!) but mostly, Microsoft is ALL THERE IS to them.

I'm the lead architect at a shop that also uses mostly Microsoft tools for internal development. Our development staff would not be considered to be great programmers, but they do have an excellent background in the industry we work in. VB is the perfect tool for this type of programmer (even VB.Net has a ways to go). I understand that you're talking about the designers in your company, but here's the reason I'm bringing this up. I have had to deal with consultants and one new hire in the past couple of years who have recommended bringing in or converting to open source software, and one who even went over my head to try to sell the idea to upper management (spectacularly unsuccessfully - he didn't make it past his probationary period, and it wasn't my decision). It may seem to them like I am brainwashed by Microsoft or that I am being closed-minded by asking them to write VB or ASP code that runs against SQL server - which is what they were hired to do in the first place - but in fact we are currently using the best tools for our particular environment. I don't know if this is the case in your organization, but it may not be Microsoft's "brain lock" abilities - it may just be that the designers have heard it all before and just aren't really interested in rehashing the same old debates. In our case if we completely eliminated all of the licensing costs for Microsoft development tools and SQL Server, I doubt that anybody would even notice the change in our IS budget. The money spent is well worth it to us.

Re:The real question is..

[adbudha kusu]

Slarty, I know exactly where you are coming from. And this mind-share is only going to get worse. Microsoft is going after the CS curriculum itself. In a few years I wonder if J2EE will be a dirty word! Check out this article( Robbing The Cradle )to see what I mean. peace out.

Re:The real question is..

[Anonymous Coward]

"M$" has become a habit... a tradition.. like celebrating xmas or stuff you always do.. don't try to change conservative M$ haters...

Re:The real question is..

[Eric Savage]

A voice of reason from the dark/other side. I'd like to build on your point.

As a programmer/developer you will, or at least should, go through a larval stage of trying every new language and taking pride in the breadth of your knowledge. This is extremely healthy for a long and happy career. However at a certain point you might want to start pulling the strings and move up to principal/architect, whatever it's called at your company. If you think you're going to get there by knowing a bunch of languages, you're fooling yourself no matter how smart you are. There is just WAY too much going on in each community to be able to keep up with every language at a super expert level.

Personally, I can professionally code VB, C, Perl, MUMPS. Though I have never worked with them I'm sure I could get a handle on the newer breeds like Python in a week or two. I consider all that my foundation to being a top Java programmer.

I basically came to a point in my career where I said to myself "Eric, there are too many paths from here on for you to keep running a little ways down each one, make a damn decision". This was before I had much Java experience by the way. My response to myself was, "OK, this Java thing looks good, I'll try that and if it doesn't work out I'm going to MSFT stuff". Well, Java worked out for me, and my career has flourished as a result of my decision. I still consider myself a hacker and I don't consider myself a Sun groupie at all. If I'd picked MSFT I don't see that it would be much better or worse, and I'd probably be excited about .NET.

Hackers as an archetype pride themselves on flexibility. If all the Java jobs went away tomorrow, am I out of luck? No, but I wouldn't be surprised if I slipped a few rungs when I jumped to another ladder, and since Java ISN'T going away tomorrow, or probably anytime in the next 5 years, I have actually increased not only the security, but the quality of my job by being a valuable resource to whoever is employing me and my skills.

Moral of my story as analogy: It's like dating. You spend a while finding out what you want. Eventually you find it, or find something you're reasonably sure is it. Stick with it for a while. Things going good? Stick with it for a long while. There is alot of truth to the statement "If you want to get rich, stay married", and it doesn't just apply to romantic relationships.

Re:The real question is..

[MeanMF]

It's like dating. You spend a while finding out what you want. Eventually you find it, or find something you're reasonably sure is it. Stick with it for a while. Things going good? Stick with it for a long while.

That's a great analogy, and I think you can extend it to organizations as well as individuals. For most companies, and I'm talking about companies not in the software business, it doesn't make sense to constantly change platforms to keep up with the latest trends. Even if a new platform is technically better or cheaper it can make very good financial sense to stay with what the company knows.

Re:The real question is..

[HBI]

Even if you used Delphi you would be better off than VB...not an OSS thing but a general usability and code speed, reliability, quality dev environment thing.

SQL Server is a load of crap as well. I cannot imagine justifying it on any basis but you didn't know any better. It has some clustering capabilities that the freebies don't have, but other than that it's not worth much.

Incidentally, did you apply the Slammer patch? (otherwise known as SQL Server 2K SP3?)

Re:The real question is..

[MeanMF]

Even if you used Delphi you would be better off than VB...not an OSS thing but a general usability and code speed, reliability, quality dev environment thing.

Not all decisions are made on which technology is better. There are other factors such as the availability of programmers, third party tools, and technical support. VB beats Delphi hands-down in all three cases. Usability, speed, and reliability are more than adequate with VB to make them non-issues for us.

SQL Server is a load of crap as well.

As far as SQL Server goes, we rely heavily on stored procedures so the availability of freebies is moot for the time being. We also use an accounting package and an HR package that need either SQL Server or Oracle to run, so even if we moved our internal applications to another platform we'd still need to support SQL Server. We used to use Sybase, but switched to MS after v7.0 came out. It was a relatively easy migration, and we were able to reduce our support and maintenance costs significantly.

Incidentally, did you apply the Slammer patch?

I applied the Slammer patch to our SQL servers over the weekend before the worm hit the 'net in full force. I missed one installation of MSDE which did end up getting infected and causing some slowness on our network. I can't say the same for our parent company, however. Their network was effectively down for almost 24 hours while they cleaned up. I ended up putting a firewall between us and the parent company as a result...

Re:The real question is..

[HBI]

I suppose given the choice of Oracle or MSSQL I would probably take the latter. I have SQL servers running here so I can't fault you much really, sorry for making you feel bad.

Glad you patched - that vulnerability is rotten. I know a lot of dev servers didn't get it though.

In regards Delphi - I use it personally but getting others to do so is rough. I suggest that 3rd party tools for VB are hacks to get it up to snuff, and contribute to significant instability. Also, Delphi will use OCX, etc. Still, I know what you mean about VB coders.

You were gracious, great job.

Re:The real question is..

[wormbin]

As far as SQL Server goes, we rely heavily on stored procedures so the availability of freebies is moot for the time being.

Just an FYI: PostgreSQL has stored procedures with many available languages.

Re:The real question is..

[Anonymous Coward]

IOW, you have a bunch of hacks who came from VB and essentially only know how to program in one language, so going to something other than MS would make you hire real programmers instead of VB kiddies...

Re:The real question is..

[soppyfrog]

Horses for courses. I have a friend currently programming something in VB5, and while I loathe VB in all its forms, I do support the fact that for his given program, he can accomplish his goals far quicker and easier in VB, for his course, VB is the horse.

.NET over Java? You have to be kidding me.

[zulux]

I don't do a lick of Java or .NET programming - but I can tell you that .NET is usless for real work, on real computers.

It's only available for x86 computers that run Windows.

No mainframe support.
No cluster support.
No Solaris,Unix,*BSD,OS/2, Win95, Mac 9, Mac X, AIX, IRIX support.
No Aplha, SPARC, PowerPC, Motoroal 68xxx suport.

So sure, .NET may trounce Java if you want to make a Recipe-Card manager for Grandma - but if you have any heavy lifing infolved, forget it.

* parts of the .NET language support facilities do run on other computers (C# looks like a good versoin of C for people who can't handle pointers) - but Microsoft keeps the .NET libraries close to their hearts.

Re:.NET over Java? You have to be kidding me.

[borgboy]

Microsoft released the source to an implementation that compiles and runs on Windows, FreeBSD and MacOS 10.2.

Mono is a clean-room implementation that runs natively on x86 Linux and interpreted on PPC, S390 and StrongARM.

I realize you don't do a lick of Java or .Net programming, but, just like the press, that doesn't excuse you from checking the facts first.

Re:.NET over Java? You have to be kidding me.

[zulux]

Mono [go-mono.org] is a clean-room implementation that runs natively on x86 Linux and interpreted on PPC, S390 and StrongARM.

Mono is not .NET - it will not have Microsoft's .NET libraries.

99.99% of all .NET applications won't run on Mono.

Some C# programs can run on .NET and Mono - but not any appplication that uses the Microsoft .NET libraries (99.99% of them)

Microsoft released [microsoft.com] the source to an implementation that compiles and runs on Windows, FreeBSD and MacOS 10.2.

As per Microsoft license for this release, you can't do any comercial work with it. You can't modify it and distribute for comercial use.

It's useless.

Microsoft has horrible support for it's languages - they left their Pascal, Fortran, VB users without any support. FoxPRO will probably be next.

I woulden't bet my future on .NET - not even Microsoft is releasing the next version of MS Office on .NET.

Re:.NET over Java? You have to be kidding me.

[borgboy]

Portability never follows if you code to platform features. Ask WebSphere developers about that.
In any case, to be considered a compliant implementation, it need only meet the standard set out by ECMA for the CLI. Sun could do worse than to submit Java(tm) to a standards body for ratification.

Re:.NET over Java? You have to be kidding me.

[Anonymous Coward]

FoxPRO will probably be next.

I HOPE so! I spent years trying to convince a small company that FoxPro was dead. They STILL swear it is the best language out there. Drove me NUTS. And when MS kept releasing new versions, even without any new features, they kept saying how it was making a comeback. My goodness it will be a relief when they finally throw out that monstrosity. Last I saw, the company was probing students at my university for people who new FoxPro. They couldn't believe it wasn't being taught. Sheesh!

Re:.NET over Java? You have to be kidding me.

[sheldon]

Have you considered looking into a different career?

You might want to keep your options open if you're going to bet against successful technologies.

Re:.NET over Java? You have to be kidding me.

[awitod]

So sure, .NET may trounce Java if you want to make a Recipe-Card manager for Grandma - but if you have any heavy lifing infolved, forget it.

Heavy lifting eh? You might want to take a quick little trip over to the Transaction Processing Performance Council. Take a look around! Windows and .Net are kicking in the other vendors' teeth in both clustered and unclustered modes in terms of performance and cost/transaction.

Now if I could just get someone to give me a Superdome to play with....

Re:.NET over Java? You have to be kidding me.

[Anonymous Coward]

You might want to take a quick little trip over to the Transaction Processing Performance Council [tcp.org]. Take a look around! Windows and .Net are kicking in the other vendors' teeth in both clustered and unclustered modes in terms of performance and cost/transaction.

Ok, I don't believe some one actually had the balls to say it, but have you even bothered to look at the full disclosures? Have you read the fine details to understand the differences? In many of the cases, the numbers are the result of doubling the RAM and using gigabit ethernet instead of 100mb ethernet. Not only that, does SQL Server support real-time data replication reliably? Does SQL Server have shared memory architecture? Can SQL Server handle several hundred billion entries and index them reliably nightly? Sql Server 5, 6, and 7 all had problems indexing a couple millions entries. This isn't something I heard 3rd hand. This is having do deal with it daily and having to ask the DBA to manually run the indexes again, so the website would work.

Re:.NET over Java? You have to be kidding me.

[Anonymous Coward]

Your attitude/ideas might be technically correct, however its the same thing that *NIX and mainframe goofs and companies have said about PCs since the PC first came out. PCs are just "toy" computers and you can't get any real work done on them. However, MS has left all the *NIX vendors in the dust. MS is what dominates the computing world.

MS's whole .NET infrastructure is actually really nice. If .NET had been an OSS/FS project or had come from a *NIX vendor, everyone here would be praising it. I'm arguing technical merits not political ones. One nice thing about .NET is that you can write a program in any .NET supported language and it all can use the same platform. MS finally created a compiler with the same design as GCC. It has a front-end and back-end.

Re:.NET over Java? You have to be kidding me.

[Anonymous Coward]

So what if SQL Server can't handle Billions of entries. If it can handle at least a million entries then good. If you really need DB's that huge sure, go to Sun/IBM/Oracle. However, MS has never really had their foot in that door nor really tried to. On the server end, MS has always cattered to the 75% of DB users. The people running small to large DB's, not extremely large. MS knows SQL Server couldn't handle the kinds of loads that American Express needs, and I bet they don't try to push it. Just like on the Desktop, MS (at first) didn't try catering to the Workstation users just the Business and home users. Hell, except for that brief Xenix and UNIX stint, they never really tried for the server market at all. Everyone here has this "well it can't handle processing something mainframes and/or clusters need so its crap" attitude, which is just fine. MS doesn't give a rats ass. MS first enters a market they know they can compete and dominate in. Meanwhile, they start planning how to enter new markets so that once that new technology is ready, they can go with it. At first, everyone probably scoffed at a MS operating system running an embedded device, and now its fairly common -- especially on the PDA side. Everyone laughed (and still does laugh) at MS entering the server market. MS pretty much dominates the company server market (excluding web servers). That's the problem with everyone of MS's competitors including the OSS/FS crowd, everyone really underestimates them. Sure they call them "evil" and "their software is just crap" and "only IT managers want it not us", but I don't see one OSS/FS project that can really match it. That's our problem, OSS/FS projects are just that -- projects, not products. Most projects have about 75-90% completion but not that remaining part that really polishes it up. While its cute to run VI/Emacs/... to edit config files and say "oh what power I have over my system", but really its bad. There is not one reason that a GUI tool can not replace editing a config file in probably 99% of all circumstances and even that remaining 1% could probably be worked around. Bad GUI tools are like any piece of software.

Well anyway, that's my rant.

Re:.NET over Java? You have to be kidding me.

[Anonymous Coward]

However, MS has never really had their foot in that door nor really tried to.

I don't think this statement is true. If microsoft didn't care, then why in the world are they pushing .NET and trying to push into enterprise applications? I won't bother listing all the interviews Gates and Ballmer have given stating that fact. I agree most applications don't need to support billions of entries, let alone 1 million. I was simply pointing out the TCPC scores thrown around by microsoft are distorted or have way too much PR spin. SQL Server is fine for numerous applications. I just have a problem when stupid CTO's believe microsoft PR and believe it really is equal to Oracle or Sybase.

Re:.NET over Java? You have to be kidding me.

[spongman]

Mono is not .NET - it will not have Microsoft's .NET libraries.

This is not entirely correct.

While it is not ximian's goal to produce a fully .NET-compatible runtime, there is definitely work being done as part of the mono project to support almost all of the non-EMA managed .NET runtime libraries, including ADO.NET, ASP.NET, WebForms, WinForms, Remoting, XML, SOAP, WebServices, EnterpriseServces, etc...

Re:.NET over Java? You have to be kidding me.

[Anonymous Coward]

Pay no mind to Piers Haken, he makes rudimentary things that he plays around with. He isn't a real player in the Mono project, just a .NET groupie with all his talent revealing code conveniently under NDA.

He is a liar, and a fraud - and a cursory inspection of his posts here and on Google will show an interesting history of ineptitude and saying things that are flat out incorrect.

Windows and Itanium take a Back seat to AIX and Power4, by a factor of 2
A combination of its P-series server which uses 32 Power 4++ processors running AIX and DB2, has knocked spots off HP's Itanium 2 Superdome using Windows Server 2003, and only using half the processors.

The firm said that TPC-C benchmarks showed that its machine delivered 680,613.12 transactions a minute at a cost of $11.13/tpmC, and that's knocked the Superdome off its number one perch.

The firm said HP had taken 18 months to catch up to its performance using its Power chips, and that lead only lasted a few weeks.

It took a further dig at HP and Intel. Adalio Sanchez, general manager of the Eserver division, said: "We don't just assemble boxes with third party components"

IBM eServer pSeries 690 Turbo 7040-681
680,613 - 11.13 US $ -11/08/03 - IBM DB2 UDB 8.1 - IBM AIX 5L V5.2 - BEA Tuxedo 8.0 -
05/09/03

J2EE response

[wickedhobo]

A lot of this is basically a load of crap. Plenty of people use XML for configuration issues. I personally still use text for most of my config files, just because it requires simpler and easier code.

And all of the default configuration files in J2EE ARE xml. web.xml,ejb-jar.xml, whatever.

Also, what's so great about having your "system wide " xml parser? In my world, you specifically don't create environment variables for your XML jar's because that makes it a common resource and creates conflicts. What if you want to use a different parser and both parsers have a class called XMLParser? How does MS deal with knowledge of which is which. J2EE servers (for the most part) simply provide application level resources (WEB-INF/lib and WEB-INF/classes) and server-level resources (app-server/lib).

Next: Metadata: XDoclet provides this ability and a lot of people use it. More importantly, it's not tied. You can use your own system.

Next: I honestly don't know enough about assemblies, but it does look like there are some cool things in there. I have to admit, CLASSPATH for Java can be clunky. However, JAR/EAR/WAR is pretty good stuff, and does most of what people need.

Next: The remoting issue is a non-starter. The protocol is really up to the vendor, and some vendors provide proprietary, somy RMI/JRMP, some strict RMI-IIOP. SOAP also changes some of this (no advatages to either side).

So blah, for the most part.

No they don't

[The Bungi]

First of all, comparing .NET and Java isn't very fair; you have to compare .NET and J2EE. When you level the playing field, most of his arguments readily fall apart."

.NET is not a specification for a distributed application server, J2EE is. The advantages or disadvantages quoted in the article in regards to .NET exist whether you're building a simple console application, a desktop forms-based client, a simple web app or a massively distributed, multi-tier one.

I don't necessarily agree with the article itself in some points, but I can't see how the comparison is "unfair" because it's not being made to J2EE but the Java 'platform' (Sun's words, not mine) itself. C# vs. Java would be a completely different thing, but that would be based on the features of the language and the runtime library. J2EE is just an extension of that.

Pet Store Performance/Cost comparisons

[__aaanwh8370]

For more info, check this Register article:
http://www.theregister.co.uk/content/4/2 7833.html

Its got some good benchmarks of real-world, optimized J2EE vs. .NET implementations of a Pet Store web store.

Very informative (though obviously, benchmarks should be taken with a grain of salt).

Re:Pet Store Performance/Cost comparisons

[toddhunter]

These comparisons were shown to be complete lies from the middleware company. If you want to know more search the web or see the furore at the middleware site itself

Re:Pet Store Performance/Cost comparisons

[watzinaneihm]

Would this artcle which is linked from the register article be what you were looking for?
Claims C# guys cheat.

Re:Pet Store Performance/Cost comparisons

[pmz]

For more info, check this Register article...

Right at the end of your precious Register article is a link to another article that shows The Middleware Company to be the liars that they are.

The J2EE vs. .NET benchmarks referenced above are a scam.

.NET *is* better -- but so what?

[fm6]

The meaningful comparisons I've seen come out in .NET's favor. The .NET VM is rather more robust. The libraries are more carefully thought out. (Can anyone consider AWT without nausea?) And C# is much more expressive than Java, without falling into the feature pit of C++.

Still, I think .NET is going to be a disaster. Microsoft is trying to make it do too many things at once. To them, it's not just a new enterprise software platform. It's a fix for all the shortcomings of the NT API. It introduces all the new programming features they never tire of dreaming up. And it does all this while retaining support for legacy languages, such as C++. AND .NET is supposed to maintain an easy migration path for Java programmers -- one that will make it impossible for them not to switch.

It just won't fly. They're trying to do too much, and they're making the same mistakes they made with NT and Win16. And even if they went at it right, .NET could never hope to make more than modest inroads into the Java marketplace. Too much investment in an established technology. (Microsoft ought to know better, given the way they've benefited from that same principle.) The best they can really hope for is to find a niche where .NET excels, such as Web Services. This would parallel the career of other technologies (Cobol, PL/1, SQL, and of course Java itself) that were supposed to take over the world, and ended up just finding their own place in it.

Re:.NET *is* better -- but so what?

[pyrrho]

"feature pit of C++"

That's no pit. That's fauna and flora. As a multiparadigmed language, you are not expected to need or want every "feature".

But has the OOP purity of the 80's, in the spirit of which both these technologies are designed, really proven itself... ever?

personally, I believe in pragmatic OOP... i.e., the kind in C++.

"To many options are bad" == "please think for me, choice hurts my brain".

End of Reflexive C++-defense.

(where is the C++ Troll when you need her?)

Re:.NET *is* better -- but so what?

[wickedhobo]

I think you need to back youself up a bit more...

Why is the VM more robust?
Why is it more expressive? If you're going to refer to variable/properties access that's bs. What happens when you want to synchronize access to the variable hmmm?

Re:.NET *is* better -- but so what?

[LizardKing]

Can anyone consider AWT without nausea?

That's like saying "can anyone consider Xlib programming without nausea" and then implying that therefore all X Window programming is a nightmare. AWT hasn't been the preferred GUI API since the days of JDK 1.1. Look up a book on Swing some time, and discover how easy GUI programming can be.

Chris

Re:.NET *is* better -- but so what?

[Anonymous Coward]

For one thing, the bytecode is superior. The .NET byte code had the benefit of hindsight; and was designed from ground up to be JITed. In Java bytecode, the individual computational byte codes have fields for their types; which is redundant information if you are running under a JIT because the types hare already been specified when the slots have been allocated. They are only needed when running under an interpreter. .NET bytecode does not have this redundancy.

One might then argue that .NET is then inferior because it is hard to write an interpretive VM rather than a JIT VM, but who cares really? .NET bytecode also has support for features like pass by reference, options for arithmetic exceptions (i.e. - should an exception be thrown on an overflow). These make it much easier to support a wider variety of languages than Java bytecode.

Someone wrote a pascal compiler for both .NET and Java bytecode. For the most part, the performance was similar except for one benchmark where .NET was faster than Java by an order of magnitude. The reason was that this benchmark had a pass-by-reference function call in the main loop. .NET supports this language construct natively, but Java doesnt. Therefore, the pascal compiler had to emit some ugly tricks to simulate this technique.

Re:.NET *is* better -- but so what?

[fm6]

Well, OK, the AWT thing was a cheap shot. Still, you have to admit that Sun cut a lot of corners in early versions of the JDK, and that this still haunts Java developent Even serious Java programmers have many issues with the libraries.

But that's all beside the point. Which is that Java is too well-entrenched to be displaced by .NET. The same Java programmers who complain about its shortcomings are very reluctant to switch over. Not the mention management, which will not easily abandon its huge investment in Java technology.

Re:.NET *is* better -- but so what?

[LizardKing]

Well, OK, the AWT thing was a cheap shot. Still, you have to admit that Sun cut a lot of corners in early versions of the JDK

Very true, some of the original classes were a bit inconsistent in their naming of accessors and AWT was fundamentally flawed thanks to the way it propagates events. The "standard" SDK could do with slimming down, as noted by a recent internal report from Sun, so it would be nice if 1.5 did away with the redundant, deprecated or downright useless stuff ... while still adding enums :-)

Chris

Re:.NET *is* better -- but so what?

[Anonymous Coward]

Yes, but then the question becomes "can anyone consider Swing without nausea?" --- and the answer remains "no".

Re:.NET *is* better -- but so what?

[Anonymous Coward]

That's like saying "can anyone consider Xlib programming without nausea" and then implying that therefore all X Window programming is a nightmare.

I hate to say it so bluntly, but...

C#/.Net vs. Java/Java

[GCP]

I've used Java longer than the reviewer -- since it was an alpha. I still use it and am an official participant in the JCP. I plan to continue using Java, probably for years to come.

That being said, I find the C# language to be significantly better designed than the Java language. Things like delegates are a great improvement over interfaces. When Anders Hejlsberg was still at Borland, he tried to persuade Sun to use them in Java instead of the interface approach and they just blew him off. "Syntactic sugar" they called it, and then they went ahead and implemented their own syntactic vinegar. I'll take the sugar, thank you.

Using "properties" in an OO language is a natural.

a.b.c++ calls a set() method instead of directly accessing a member var named c. (The c property may not even be backed by a variable. It may be calculated on demand.) In Java, to use OO methods instead of exposing private variables, you would do something like

a.getB().setC(a.getB().getC()+1);

although usually it would be broken into several simpler steps with temp variables for ease of reading.

C# makes it a breeze to create visual interfaces to object properties without losing the encapsulation of the implementation of those properties.

There are so many other improvements in C# relative to Java that it really annoys me to hear the political refrain "C# is just a knock off of Java". It's such a superior "knockoff" that, for the first time in years, Sun has gotten back in the mode of making language improvements (all of which make it more like the "knockoff") instead of their knee-jerk "you're not language designers so, trust us, you don't need that" reaction of the past.

The Java class libraries are far more complete than those of .Net, though .Net's have the benefit of learning from Java's mistakes. (A nice, consistent way of converting between fundamental data types, well-designed containers, etc.)

I now find myself in the position of using C# when I can (mostly for personal utilities) and Java when I must (for professional production). Since I strongly prefer to use Linux servers and strongly prefer to avoid the MS license ball-and-chain, I anticipate having to continue using Java for years.

While doing so, though, I will continue rooting for Mono and working thru the JCP to try to steer the Java language to embrace and extend what I consider the significant advantages C# (and to some extent the .Net classes) have over Java. All the anti-MS bigots don't make that easy, though.

Re:C#/.Net vs. Java/Java

[pyrrho]

From what I've seen, Java itself was a knock-off of VB. VB done "right" according to Sun thinking (supposedly, though I guess some not in the Java group don't think that the JVM, for example, really is developed the "Sun way").

For MS to take ideas from Java to the next level is really just reaquiring access to this virtualized machine world where you protect the programmer as if... as if... they were but a user! (little joke there, very little).

Although I'm no bigot... I say this all as someone that has grown tired and distrustful of Microsoft. Since I have ten years of Windows development experience, I think I gave them a shot... so I blame them not me for my distrust.

Re:C#/.Net vs. Java/Java

[pyrrho]

overratted.... yeah. right. suuuure it was.

Now, this, this is overrated (I'm gonna use the Your-A-Special-Poster bonus this time... get ready for some FreedomGiving on your ass!)

um, on second thought, anonymous! you'll never figure out who I am...

Oh wait, it's obvious who I am. You villian.

By the way, could we get a little island for the MSychophants and the JavaFaithful to inhabit... or a spaceship with two more to follow for the rest of us. Please? Please?

Re:C#/.Net vs. Java/Java

[mike_sucks]

Do you often talk to yourself? It sounds like you're having a really, really good conversation.

Re:C#/.Net vs. Java/Java

[Matt2000]

I'm interested to read your comments GCP as I'm a longtime Java programmer as well. When I read the C# spec I found that the vast majority of the language additions over Java were the classic Microsoft shortcuts that cloud a language and reduce clarity. This is of course with the one great exception of delegates, which I am totally in favour of.

It seems there is a danger as we get more experienced with programming to want to get fancy with our syntax and so on, but I think Java neatly constrains this desire and guides us to write clearer programs. This is why projects in Java are so successful at producing reusable open source components, and using those components as building blocks.

This is all involves personal preference of course. However, when I download a library for a program I'm working on I know there'll be an lower bound on how bad or obfuscated the code will be, most of the additions to C# lower that bound significantly.

Re:C#/.Net vs. Java/Java

[pyrrho]

It's important to be on speaking terms with yourself.

Re:C#/.Net vs. Java/Java

[mike_sucks]

That's what I keep on telling myself.

Re:C#/.Net vs. Java/Java

[GCP]

I don't agree, but as you said, language features are a matter of personal preference.

You agree with delegates for wrapping a single method with a name of your choice instead of implementing a full set of method stubs the Java way.

For properties, I find a.b.c = foo to be much cleaner and easier to read than the Java way of
a.getB().setC(foo). I wouldn't call that "getting fancy with syntax".

The Java way of handling enums (static member vars) was really clunky. C# just has clean, simple enums. After years of telling us that the clunky way was good enough, Sun saw enums in C# and now Java 1.5 will have enums.

Cycling thru a container in Java with an "Enumerator" (which isn't enumeration at all) is really ugly. In C#, all containers implement an interface that ties in to the "foreach" keyword, making the code for applying something to each element in a container clean and clear.

Compare this sort of approach in Java:

Enumeration iter = collection.getIteration();
while (iter.hasMoreValues()) {
Object item = iter.next(); ...body of loop...
}

to C#'s:

foreach (object o in collection)...

And then there's conversion between types. Java has a different approach between every two types. C# mostly just uses the same technique for all conversions.

Or how about this in C#:

int i=3;
string str = i.ToString();

I don't find that to be confusing relative to any approach you take in Java to do the same thing.

I don't have time to write an essay full of examples (and the collections one above was just shooting from the hip, so it may be off a bit).

A lot of programmers are pretty cavalier about readability as a language feature. Not me. I agree with you. I just find these features of C# to be more readable than their Java equivalents, not less.

Re:C#/.Net vs. Java/Java

[JimMcCusker]

Don't use enumerators, use Iterators. (This goes along with using the Collections framework instead of those hacks Vector, and Hashtable)

for (Iterator i=collection.iterator(); i.hasNext();) {
ObjectType o = (ObjectType)i.next(); ...
}

This has te added benefit of being much more flexible, such as using more than one next() call per iteration, or backing up in the iteration (iterators have reverse iteration too).

Re:C#/.Net vs. Java/Java

[pyrrho]

you know... that was clearly flamebait! Not a troll. Uneducated vermin.

Would somebody please tell me what they are thinking.

See, now this one is a troll.

Good lord. Am I losing karma... or spending it?

Re:C#/.Net vs. Java/Java

[fupeg]

It is absolutely true that C# has advantages over Java. It's the classic "learning from the other guy's mistakes." It's also classic MS strategy. But C# has a large number of disadvantages over Java.

I have been a Java programmer since 98. Last year I took a job at an MS shop, working in C# (damn Silicon Valley economy!) I loved C# at first. One of my favorite things was the aforementioned delegates. But instead of them being another tool for programmers to use, C# often forces you to use them when there are other, more elegant solutions. The classic example of this is a thread pool. C#'s Thread object is sealed and has no public constructor. Creating a thread requires a delegate, which in return requires its parent object to already be instantiated or for the method to be static. So what if you want to maintain a pool of allocated threads, each waiting to be dispatched as requests come in? It can be done, but you gotta use reflection. This is trivial to do in Java. C# does provide a ThreadPool class, which is a direct link to the thread pool created by Windows for your application. It requires a delegate to a static method, and you have to surrender any control on when to dispatch.

The other biggest C# problem was how it allowed unsafe code. This seems great at first. We were using an embedded version of MySQL. It was so simple to import objects from the MySQL DLLs. But these DLLs could easily bomb and trash the CLR. If that happened, you had one option -- reboot.

Actually that brings up a bigger problem with C#: Exception handling. Or should I say its lack thereof. It's a huge flaw (IMHO) of the language to not force exceptions to be caught or any information to be revealed about them. Of course it makes programming easier, but it does so by essentially encouraging poorly written code.

Another seemingly cool feature of C# was its "unconnected" database APIs (System.Data.) These gave database structures for holding data that was probably pulled from a database that there is now no connection to. These seemed great, but we quickly found their limitations. You could have a Dataset (collection of tables) and once the amount of data reached a certain size, everything slowed to a crawl. Didn't matter how much memory the computer had, how fast its CPU was, or if it had multiple processors. The sysem-killing-size-limit was the same on my 1.7GHz/256 MB laptop as it was on a dual processor, 2.4GHz/4 GB Xenon server.

Speaking of databases, make sure you never have to changes RDBMS if you have an app running C#. The APIs for SQL Server are different than for any other database.

Serializers are very cool with C#. But there are some big surprising bugs. C# gives you three serializers: binary, XML, and SOAP. The surprising thing here is that while binary and SOAP will work for any object, XML will not. So even though SOAP is a type of XML, an object that can be serialized to SOAP might not be serializable to XML in C#.

Garbage collection is also dubious in C#. Non-referenced, first generation objects could not be reliably expected to be garbage collected by the CLR. At first we though that the CLR was just not doing any GC'ing, but we could be running out of memory like crazy and this was still the case. A lot of code had to be re-written because of this

These were all things I noticed about the language and its implementation. I was constatnly having to reboot my computer when programming in C#. We had to recommend to our customers that they back up / reboot on a regular basis. We had a close relationship with MS, and they advised us that many of our ailments would be solved by .NET 2003 and especially in the 64-bit versions of some other code.

Re:C#/.Net vs. Java/Java

[Anonymous Coward]

Good post on the short comings of .NET implementation. I would also add that .NET threading is fundamentally different than POSIX threads. The issues I have with .NET threading is that now instead of calling the methods directly like Java, you know have to either make a delegate signature for each method or have one generic method which takes a message and then call its methods.

out of touch

[Anonymous Coward]

this may not be the most relevant thing in the world but...

I used to collect comic books (or, I read a heck of a lot of them and refused to throw them away, depending on how you look at it). That's impossible, you're saying. Programmers are serious people who don't have time for comic books, science fiction, role-playing games, and strange fascinations with a certain "Weird Al" Yankovic's cinematic magnum opus. But, surprising as it might seem, I did.

Wow. i'm thinking that this guy is just a bit out of touch with the programming community. i know we're not all geeks who collect comic books and what not, but to suggest that it would be strange for a programmer to like comic books... i'd like to think he's being sarcastic here, but it sure doesn't seem like it from the context.

-1 Sig Comment

[pyrrho]

Stupidity may be self-curing, unfortunately, it reproduces prior to the cure.

Syntactic sugar

[Alomex]

Not long after the Cobol disaster (too many syntactic niceties), the programming language community swung the other way and since the 1970s has opposed most niceties in a language as "syntactic sugar". Sure enough, the C code:

x = y + z;

is nothing but the syntactic sugared version of

LDA Y
ADD Z
MV X

SO?? Isn't the C version far superior nonetheless?

Re:Syntactic sugar

[Anonymous Coward]

Your example is not a case of syntatic sugar.

Re:Syntactic sugar

[fm6]

I think you're really distorting the SS debate and the role of Cobol and C in that debate.

The big mistake with Cobol is not that its syntax is too complex. Most early languages had that problem. But in Cobol's case, they made the silly assumption that a language with a superficial resemblance to ordinary English is somehow easier to learn. Thus in Cobol you can write:

DIVIDE TOTAL BY NUMBER GIVING PRO-RATA REMAINDER RESIDUE.

The problem is that Cobol is not a subset of English, it just looks like one. Cobol uses ordinary human constructs, but doesn't save the human from having to learn any abstractions.

Detractors of C are fond of calling it "high level assembly language". I think that mostly comes from the use in C of pointers, which seem much too similar to machine language memory pointers. Now it's true that C pointers are not as sophisticated or foolproof as object references (Java and most other OOP languages), but they're still more than memory values. Consider,

BIGDUDEDATASTRUCTURE d[DSIZE];
for (i := 0; i < DSIZE; i++) chompchompchomp(d[i]);

If you translate that to assembly, you'll see a difference that's a lot more than syntactic sugar.

The basic issue between C++ and Java is not SS, but general complexity. So Java leaves out default parameters, operator overloads, and multiple inheritance, some other stuff.

Re:Syntactic sugar

[Alomex]

Huh? I'm not saying that the only difference between C and assembly is syntactic sugar. Far from it.

What I was pointing out that is that judicious amounts of syntactic sugar are extremely convenient to programmers, and hence simply being SS is not enough to dismiss a language feature. Yet this is routinely done in the programming language community, as illustrated by the real life example in the first message (not mine) of this thread.

Re:Syntactic sugar

[fm6]

The original message didn't characterize anything as syntactic sugar. It only said that C#-style delegates never got into Java because JavaSoft thought they were "syntactic sugar". And it sounds like this version of history comes from Anders Hejlsberg, the inventor of delegates. Given the long standing feud betwee Hejlsberg and JavaSoft both when he was at Borland and later at Microsoft, I doubt if the argument was as simple as that.

Re:Syntactic sugar

[trouser]

float x = 3.14159;
float y = 1.0/2.0 * x;

Value of y = 1.570795

Re:Syntactic sugar

[Anonymous Coward]

Your posting sounds definitely Clintonian. It didn't use syntactic sugar except that it did.

Re:Syntactic sugar

[Alomex]

I've been around long enough in the programming language community, and have heard the "syntactic sugar" red-herring so often that I'm inclined to believe Hejlsberg's side of things in this case.

Re:Syntactic sugar

[pmz]

Sheesh, lets at least use a "real" computer:

save %sp, -0x70, %sp
mov 0x1, %o1
st %o1, [%fp - 0xc]
mov 0x2, %o0
st %o0, [%fp - 0x10]
add %o1, %o0, %o0
st %o0, [%fp - 0x8]
st %o0, [%fp - 0x4]
or %o0, %g0, %i0
ret
restore

Re:Syntactic sugar

[fm6]

Actually, it turns out you're completely right. Did some browsing and found a bunch of JavaSoft documents where they attack delegates as "syntactic sugar". But as you yourself point out, this is just a red herring. There's more to delegates than syntax! So this isn't an argument about syntactic sugar. Sun's spin artists are just trying to cast it as one.

Re:Syntactic sugar

[Alomex]

Told you! I ain't an old wolf for nothing....

Only do it once! again.

[WasterDave]

Fabulous.

"In contrast, XML permeates every corner of .Net."

Last year all configuration was being held in Active Directory. The year before that all configuration was being held in the registry (I can't remember the name of the IIS specific registry thing to rant about it). The year before that we were all supposed to be using .ini files and on each occasion the Microsoft developer wankfest assured us that "THIS IS IT!!!".

What is wrong with the world? It's almost like there's a constant torrent of naive Microsoft fanboys dropping into the workforce under the impression they're software engineers.

Dave

Re:Only do it once! again.

[Tablizer]

Last year all configuration was being held in Active Directory. The year before that all configuration was being held in the registry (I can't remember the name of the IIS specific registry thing to rant about it). The year before that we were all supposed to be using .ini files and on each occasion the Microsoft developer wankfest assured us that "THIS IS IT!!!".

I bet the Next Great MS OS will use INI files again, but simply call it something completely different, like "angle-bracket-free XML" or something.

Re:Only do it once! again.

[ray-auch]

Actually the previous one already did, quote:

Windows 2000 also introduces a significant change in the overall role of the registry. It's no longer the preferred place to store an application's configuration data. Storing large chunks of data in the registry can take up a lot of room, especially on shared computers. Applications now must use special system folders to save user settings, application data, and temporary files.

from MS article from 1999 here.

Not that MS giving up on it seems to have stopped people saying that Linux needs a registry for application configuration data.

Application configuration files on Windows are now supposed to be (real, not angle-bracket-free) XML, just google for "application configuration files" - not hard to find really.

Re:Only do it once! again.

[Lips]

I refer to them as WizardBoys.

IIS Thing

[MrBlack]

The IIS "registry-like-thing-that-is-not-the-registry" is the IIS Metabase. Most people who know about it do so because it has become corrupt on them. COM+ has a similar "registry-like-thing-that-is-not-the-registry" called the COM+ catalog.

Re:IIS Thing

[WasterDave]

Yeah, that was it. I never had it corrupt on me, but I did have to write a com component that used it for something once. It struck me as actually being far more sensible than the registry - supporting inheritance, for instance, and being a damn slight faster.

I managed to avoid the com+ thing entirely, and similarly fancy my chances of avoiding .net. If I have to code for windows these days I try to avoid going further than the API - down to the metal baby, yeah!

Dave

Re:IIS Thing

[sheldon]

I've been working with IIS now for about 6 years and I've never seen the Metabase become corrupted. I imagine it could happen if your machine crashed while updating the metabase, but how common is that?

No, the main reason people are familiar with the Metabase is that's where the IIS configuration settings are located and it's far easier to write a script to modify them in the metabase than to use the UI. Especially when you're doing this to hundreds of web servers.

Re:IIS Thing

[Anonymous Coward]

I thought the COM+ thing was layered on top of the Registry in an opaque fashion?

The main reason people don't like .NET

[Joe the Lesser]

It's owned/created by Microsoft.
It's new and costs money/time/pain to switch, for hard to see benefits.

(Justified in my opinion.)

Re:The main reason people don't like .NET

[primus_sucks]

It's owned/created by Microsoft.

Exactly. Once mono is more complete and I'm convinced MS won't try to kill it, then I'll take a look at .Net.

Re:The main reason people don't like .NET

[primus_sucks]

instead of moaning about how long it is taking to get mono up and running, you should be helping.

I would love to work on an awesome project like mono if I had the time. Right now I have a full-time job, I've been hacking on my own project for 2+ years, and I'm working on another little side project. Beleive me, it's not like I sit on the couch every night wondering when the mono-team will get their asses in gear:)

Re:The main reason people don't like .NET

[TheLink]

Won't MS just kill mono off or make it irrelevant?

My guess is most people doing it the .Net way will do it the MS way and sooner or later it won't run on mono.

So why spend years on something like this?

It's even worse than being one of the many backstabbed partners of microsoft.

Samba does have a similar risk, but since network file serving is a more constrained arena - where backward compatibility still plays a big part, I'd say their chances are still good. But if people keep happily "upgrading" to the next version of Windows, who knows what will happen 2-3 versions later esp with the TCPA and DRM stuff.

Viva syntactic sugar!

[GCP]

I understand the aversion the Java designers felt for "syntactic sugar". They equated it with the spiral of Perl into syntactic chaos.

I understand it, but don't accept it. I think that the best programming language is the one that makes you tell the computer the fewest number of things to get it to do exactly what you want it to do.

I think the Java designers were way too conservative about syntax and way too conservative about incorporating popular, proven features from other languages. They should have had smarter enums than C++, not no enums. Smarter function pointers than C++ (delegates, for example) instead of no way to pass a single function as an argument, etc.

And more syntactic sugar of the sort you see in Python and Ruby.

Java is a very solid, valuable production platform as it is, but I think Java would be a better *language* if it were a little more like Python and less like a simplified C++.

Of course, I could say the same about C#, which obviously didn't want to venture too far from the familiar features of Java, C++, and VB. My understanding, though, is that the designers of the underlying .Net runtime made a lot more effort to include features in the bytecode system that will enable languages to use generics, multiple dispatch, multiple inheritance, tail calls, and others, which could support more interesting languages (or new C# features) in the future than may be practical with the JVM. (I'm not an expert on that last point, so consider it a *rumor*).

Re:Viva syntactic sugar!

[Anonymous Coward]

Java is nothing but a modest clean up of C++ which underwent a massive Sun marketing campaign.

SUN Internal memo: The Java Problem

[schouwl]

Hi,

Even Sun admits that Java has a problem using to many resources for small tasks.
I don't know if that is better than .NET ;)

The Java Problem
Author: Julian S. Taylor
Reviewed by: Steve Talley, Mark Carlson, Henry Knapp, Willy (Waikwan) Hui, Eugene Krivopaltsev, Peter Madany, Michael Boucher

Executive Summary

While the Java language provides many advantages over C and C++, its implementation on Solaris presents barriers to the delivery of reliable applications. These barriers prevent general acceptance of Java for production software within Sun. A review of the problem indicates that these issues are not inherent to Java but instead represent implementation oversights and inconsistencies common to projects which do not communicate effectively with partners and users.

Within Sun, the institutional mechanism for promoting this sort of communication between partners is the System Architecture Council codified in the Software Development Framework (SDF). We propose that the process of releasing our Java implementation will benefit from conformance with the SDF.

Introduction

This document details the difficulties that keep our Solaris Java implementation from being practical for the development of common software applications. It represents a consensus of several senior engineers within Sun Microsystems. We believe that our Java implementation is inappropriate for a large number of categories of software application. We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation.
We all agree that the Java language offers many advantages over the alternatives. We would generally prefer to deploy our applications in Java but the implementation provided for Solaris is inadequate to the task of producing supportable and reliable products.
Our experience in filing bugs against Java has been to see them rapidly closed as "will not fix". 22% of accepted non-duplicate bugs against base Java are closed in this way as opposed to 7% for C++. Key examples include:

4246106 Large virtual memory consumption of JVM
4374713 Anonymous inner classes have incompatible serialization
4380663 Multiple bottlenecks in the JVM
4407856 RMI secure transport provider doesn't timeout SSL sessions
4460368 For jdk1.4, JTable.setCellSelectionEnabled() does not work
4460382 For Jdk1.4, the table editors for JTable do not work.
4433962 JDK1.3 HotSpot JVM crashes Sun Management Center Console
4463644 Calculation of JTable's height is different for jdk1.2 and jdk1.4
4475676 [under jdk1.3.1, new JFrame launch causes jumping]

In personal conversations with Java engineers and managers, it appears that Solaris is not a priority and the resource issues are not viewed as serious. Attempts to discuss this have not been productive and the message we hear routinely from Java engineering is that new features are key and improvements to the foundation are secondary. This is mentioned only to make it clear that other avenues for change have been explored but without success. Here we seek to briefly present the problem and recommend a solution.

Defining the Java Problem

These are the problems we have observed which we believe indicate the need for an improved implementation and a modified approach.

1. The support model seems flawed
Since Java is not a self-contained binary, every Java program depends fundamentally upon the installed Java Runtime Environment (JRE). If that JRE is broken, correction and relief is required. This sort of relief needs to happen in a timely manner and needs to fix only the problem without the likelihood of introducing additional bugs. Java Software does not provide such relief.
Java packages are released (re-released) every four or five months, introducing bug fixes and new features and new bugs with each release. These releases are upgrading packages which remove all trace

C pointers ARE machine language memory pointers

[Anonymous Coward]

C of pointers, which seem much too similar to machine language memory pointers.

They are.

inaccurate statement

[Anonymous Coward]

There are workarounds, of course. You can do as I did and write a custom Java classloader that isolates a third-party product from the libraries loaded by the parent Web application. That, however, is a non-standard solution, and a standard solution included as part of the base runtime would be a vast improvement. .Net offers such a solution in its ability to run multiple versions of an assembly simultaneously within the same AppDomain.

One statement in the article stands out as inaccurate or misleading. You can run multiple versions of an assembly, but not if you want to dynamically load and unload assemblies. If you want to load/unload assemblies, you have to use a different appDomain for each assembly. This way you can unload an assembly by killing the appDomain. The problem the author describes is well documented and part of many Java specs. Specifically the servlet specs explicitly require each webapp have it's own class loader for that reason. I would argue having multiple versions of an assembly or jar file within the same app domain or classloader is not a clean solution. It is better to isolate versions in individual domains.

This way, you completely avoid the issue of collision and provide cleaner separation. But that's my own bias. there are still tons of stuff .NET is missing, here's a few JMX, JMC, JMS, Tag framework, java triggers, eclipse style plugin framework, timeshare threading (POSIX) and strong monitoring at the VM level for threads.

Advantages of Java Over .NET

[OmniVector]

It's already ported to a slew of platforms so you're never locked into one operating system (Windows). It's proven, and reliable, and has a huge backing already. Anything that can be done in .NET can already be done in Java (Web Services, Programs, Applets).

Other aspects - productivity, mobile & cost

[Anonymous Coward]

NET is offered as a productivity enhancement. I think everyone agrees the "unstructured" .NET code isn't a fair comparison against the "example" J2EE code in the petshop/store shootout. However, I'd certainly like to see some consideration of the productivity and learning curve involved in each case. One of the nice things about .NET is the development toolkit comes in one box. With open source / J2EE, one has to do a fair amount of evaluating before assembling a usable toolkit.

The second issue is targeting different types of mobile devices. MS has done some good work with abstracting and supporting many different devices. I haven't had time to personally compare the J2EE efforts.

Third is cost. There's just no denying that for small and medium sized applications, open source / J2EE is much cheaper. All one has to do is look for entry web hosting with say 400 MB space and an SQL database. A .NET environment will run you $75+ per month versus an open source environment at $20/month. I have to assume that difference remains as one scales higher.

C#.NET vs Java

[Tim12s]

C#.NET advantages come
1) from taking everything good in java
2) adding cleaner COM+ integration and windows integration.

Thats it.

Now Java 1.5 will fix alot of issues i have with java and it removes one of the reasons (1) for moving to C#.NET.
(2) is going to be difficult for java to level. Having said that, (2) is the reason why .NET will last forever in general application development. App development with ATL, Win32, x,y,z is a nightmare in some respects. .Net will do for windows what Java has done for computing.

I apologise for the formatting of the last comment

[soppyfrog]

This is the first time I have posted at slash dot and I made the mistake of posting as HTML without including any
's I apologise if this makes my response difficult to read.