SD Online has an excellent article comparing J2EE and .NET. The article examines the evolution of J2EE and .NET. It also compares J2EE & .NET support for: components, fat clients, data sources, directory services, and XML. It also examines the philosophical differences between J2EE and .NET. Overall, this is article well worth reading.
Read Article Here
News Source: application-servers.com
Article writer seemed to favor Microsoft more than J2EE. The article also focused heavily on XML and its role in each framework. Net isn't even out yet, so right off that bat J2EE is more mature. Although they may have built on older technologies.
Next, the language learning curve issue is one Microsoft is pushing heavily. If java is one language, and Net is many, who will have the learning curve. Current VB programmers are going to be in shock with VB.net if it is truely OO. It real scary to give a VB programmer the ability to really use Polymorphism and Composition. I can see the performance now. From C++ to C# is the same learning curve as C++ to Java. Even if you can add extensions to COBOL, there is still a learning curve.
ADO over XML? I can see some benefits, but when it comes down to it, the real data will still reside on some type of relational database. Who needs the overhead of going from a native database language through a parser. I'm sure MS-SQL server will have an optimal way but what about Oracle, Sybase, DB2...
.NET vs. J2EE comparison looks pretty pointless to me. J2EE shall finally standardize full XML support and full SOAP support as part of their App Server platform certification and .NET like approach is there.
Who cares which language (VB, C#, C++ or Java) you use to build your apps. As long as they can speak to other that's all that counts. In the end if they do not speak to each other any technology (however good and easy to use is at the moment) would ultimatelly die. That applies to J2EE (I prefer that one) and .NET and Oracle, and many others. Let's get to the ground boys and girls! Interoperability is all I want and the I would choose my development environment depending on the available skills, culture etc. But I want them to speak to each other!
I think an important criteria for software vendors who write tools on either of the platforms is how easy / compatible are newer versions of the platform with older versions.. I've been developing code on both MS and java platforms, and it's scary that with every upgrade of the OS/ platform on MS, existing code has to be *ported* to the new platform.. a recompile is not good enough. You end up with different trees for each type of platform, and a new set of DLLs everytime don't help at all.
On Java you can deploy with a 'personal' runtime, without changing the complete system's settings. The concept of deprecation is good so that vendors can upgrade over time (if we ignore the EJB APIs for the moment).
I don't know how much of .NET integration is for real and how much is marketing hype. e.g. Exchange 2000 is out in the market for more than 6 months .. how can it be .NET server, while the platform itself is in beta now?
Then, the usage of XML all over seems good in concept but I'm not sure how practical it is.. you typically don't want to parse and recreate and transform XML at every layer, since (i would imagine) all layers use different DTDs to communicate...
In regards to polymorphism and composition in the VB world. VB6 had both the ability to create a class(object) inside a class, hence composition. Also the ability to throw a object(late bound) to a method and at runtime call the proper objects method based on class type, hence polymorphism.
VB6 does not have true inheritance, as composition and interface inheritance is all you can do. If we are going to post, lets get the facts straight.
Besides most VB developers will be moving to C# for many reasons!!!
One other note. I give microsoft the edge with marketing. Most customers are not technical and Windows did bring the non techies into the computer world. J2EE is definitely appealing to the techi-side. For all intensive purposes, one might prove why one framework is better than the other. But most of the time, the decision comes from the higher ups who don't have this knowledge and M$ targets these folks well. Novell clearly was a superior network however where are they now(in that space anyway)? J2EE is a combination among vendors who among themselves fight over the standard while M$ is one. I personally am a big fan of J2EE, however I have a family and will swing with the market if needed. According to M$, my learning curve should be swift.
Everybody shall follow their gut feelings...do not blame you for that! However in the end they shall all comply at the XML and SOAP level. In that case it is going to be just a matter of choice. And the player that does not comply - get out! J2EE folks get to your senses - I would realy hate the idea that such nice technology dies for the reason of not being compliant.
On one side we have pretty mature J2EE (almost 2 years old), which is nothing but a set of specs build on top of Java language/platform and on the other side we have .NOT that's been marketed for almost a year and is not out yet. Choosing a winner makes no sense to me!
When .NOT proves itself (which won't happen over nite) and other platforms (especially Linux) are not (going to be) used, only then will I consider learning it. By then "we" may have Visual C#, or Visual C##, or C@ ... or who knows what will sound catchy by then.
One last thing: just like "too much love can kill you" - same way: "too much of XML can kill you too!"
I refuse to read the "shallow" storries of smart "analysts" who are very often nothing but paid "forture tellers".
One more time - standard for interoperability is what we need. No more language/architecture wars like this one. We need web components that really can finally work together so that we can pick and choose ones that we like based on our needs and their specs (something like Web Service Description Language or WSDL)and have plug and play development as much as we can.
Unfortunatelly we are still not there - not because of the low level of software development knowledge, but because vendors refuse to standardize. They are all the same in the end - they like monopoly and control. That's the main business driver of modern capitalism.
Future is all about paying fees for web component usage - that is where Bill Gates is right. Underlined technology - do we care?, as long as it is stable and can propagate security and transaction contexts between cooperating web containers?
It's too simple a picture to state that it's just because companies want monopoly control. Certainly some companies want that, but most companies aren't any where near of reaching that goal, so one would think that their day-to-day operations, strategies, and tactics aren't aligned towards this end.
There's many paradoxical and divergent interests in a large company.
Furthermore, I suggest you look into academia for a case of "disagreeability". Technical people are just as bad as business people for stubbornly rejecting standards. Part of this is acceptable -- standards eliminate one avenue of innovation, so you'd better get the standard A) 90% correct and B) after there's been considerable experimentation with implementation.
EJB, despite being developed in a vacuum, was definitely influenced by experimentation & experience with COBOL transaction systems of the past and the CORBA servers that they sought to speed up. Ditto for COM+.
.NET is developing as an evolution of the virtual machines of the past -- COBOL, Smalltalk, Pascal, Java, etc. They are venturing into somewhat uncharted territory by offering a "language model" instead of a language as the basis for the VM. And this VM isn't even standard yet. And how well it integrates transactions/queuing/etc with COM+ is still an unknown.
So we've got a ways still for .NET to become a standard & to mature. COM+ already has maturity, more-so than EJB, so the real goal is to get a stable integration between .NET and the existing COM+ framework. J2EE has a leg up on already being a standard, and having a certain level of end-to-end maturity, though we still have a way to go -- most servers' internals aren't very mature at all (quite naive, I'd say).
Anyway, I think that .NET sounds good, but Microsoft and Windows don't sound good at all. If you have to get married to a company and an OS to enjoy of a wonderful? technology, then the spirit of Java is dead. The success of Java is not the programming language, is the universe of technology around it.
When I started with Java, I thought that C++ was better as programming language. I went deeper into the java world, and I realized that there was such a huge amount of information, tools, frameworks... and I changed to java.
The guys from Microsoft must change their minds in order to create something really open. If they do with .NET as they did with IE (free browser to sell Windows OS), may be they can beat the Java Universe.
Basically, my comments relate to the final paragraph of the article where it concentrates on the choice between the two options:<br>
The decision comes down to whether you are a small company or not. If you are a large company, then multi-paltform integration is a constant fact of life. Mergers, aquisitions, changes in technology partners ALL mean that you have to INTEGRATE - and this is continuous process, never a once-off.<br>
Microsoft's view of integration is a very vertical view - all of their products usually integrate very well (when they work ;-) ) but integration to anything else is usually a one way affair (Active Directory Server is a prime example!).<br>
However, if you are a small organisation, this need for integration can be managed in "The Microsoft Way" (ie integrate by changing everything to microsoft).<br>
The trouble is that even in this scenario, integration is still an issue as you have to integrate BETWEEN versions of the microsoft platform. For example, SQL2000 only runs on Win2000 - so if you want to use SQL2000, then you have to change OS as well - then this knock-on effect of integration problems means that the only solution is to do a complete *****2000 migration! No organisation can afford to do this every 2-3 years!<br>
At the end of the day, Microsoft will earn a good market share simply because they are microsoft and they have the money to buy themselves a share. Some developers feel warm, cuddly and safe with M$ because they dont have to concern themselves with having to choose products to suite their problem - in the M$ world, there is usually a 1:1 relationship between a technology and a M$ Product!<br>
Q: Need XML B2B? Answer: Biztalk2000.<br>
Q: Need a database? Answer: SQL2000.<br>
The question of whether the product FITS their NEEDS doesnt enter - there is no choice anyway.<br>
However, if you are a serious developer - ie you are trying to match a technology with a business problem AND you are trying to buy yourself a large percentage of the solution rather than develop it all yourself, then you look around to see what vendor offers you the best match. That is when choice becomes very important - it limits the amount of work your (generally not-so-experienced - or indeed not very good) developers need to do and therefore limits the amount that they can get wrong<br>
No matter what any of the paid fortune tellers say, in my opinion there is no way that either platform will "Dominate" convincingly.
SQL Server 2000 runs on NT4 Server as well as Windows 2000.
There are also editions that will run on Windows 9x desktops. No Linux support as yet.
At least get your facts straight when attacking the evil empire.
You are quite correct. SQL2000 is, according to M$ anyway, supported on NT4 Server SP5. All that I have heard thus far is that it is not be recommended. (Dont forget, M$ say that their OS upgrades (95->NT->2000) work too.) You might have 1st hand experience with SQL2000 on NT4, in which case I will happily concede that I am wrong.
However, the point I was trying to illustrate was that tightly coupled systems are difficult to maintain and extend - this I maintain to be true. Microsoft argue that their database is performant because it is "integrated with the OS and takes full advantage of the OS...". This tight coupling with the OS, does restrict your options when you want to upgrade one or the other as there are bound to be problems.