http://weblogs.asp.net/jprismon/posts/9824.aspx raised a couple of valid points that need more than the superficial
comments I posted yesterday.
Microsoft has completly committed to .NET. Longhorn's new features are all managed code.
I've done a bit of research about this, and I'm not convinced it is true. While all the new features in
Longhorn (eg the file system, Active Directory enhancements etc) will undoubtably expose managed code interfaces
I doubt they will themsleves be written in .NET. I know the new version of IIS has some of the code moved into the Windows kernel
(I think the correct terminology is “it runs in ring 0″?), and code that performance optimised is unlikely to be managed.
Note that you wouldn't do it in Java, either, so this isn't a particular weakness of .NET
Microsoft's most profitable Business Aplications are being ported as we speak. BizTalk, Office,
and the OS all have managed serviced components now, and the next version of SQL will have
extremly rich CLR support.
This is true, and is a big deal. Increasingly I suspect we'll see Office's .NET interfaces used from other applications,
kind of like people use to automate Excel & Word from COM. This time it will be easier, and Office will be designed for
doing the kind of batch-procssing & workflow which people want. In the Java world OpenOffice exposes some Java interfaces.
I can't comment on how good they are. However, many databases (Oracle, DB2, Sybase ASE & ASA for example) all have
extremely rich Java support. This is pretty mature and looks good in comparison to SQL Server's .NET support.
Interoperability rocks in .NET. Not just platform (mono is doing a great job) but also interop based on the WS-I stack
I don't really understand what is being said here. Interoperability with what? I do a lot of fairly hairy integration work
in my day job and I can speak from experience when I say that 7 Bit ASCII works really well in both .NET & Java, but
anything else seems to have edge cases that have issues (Mostly in the crappy proprietary libraries we need to use). SOAP
over HTTP is usually okay from both .NET & Java. Over all, I don't see this as a particular win either way. From the
integration point of view J2EE has the JCA spec which is quite nice – unfortunalty you need to rely on your vendor to
suply a JCA complient connector, though.
Java is at best a niche platform. When was the last time you saw any non server/specialized software written in Java?
Of the top ten software software packages (Windows, Office, SAP, PeopleSoft, Oracle, SQL, Quicken,
Quickbooks, TaxCut, Microsoft Money) how many of them are actually written in java? 0/10. Microsoft
owns 90% of the CPU market. Microsoft has decided to slip .NET until Longhorn, but it is out there in the
hands of extremly productive developers.
This is a fair point (although SAP, PeopleSoft & Oracle all have significant Java components). How many are written
in .NET, though? (0/10) I'll conceed that Office & SQL Server will have significant .NET components in the next release,
but that will really only match what is in Oracle, SAP & PeopleSoft right now.
Reflection, Inspection, Attributes and Events. Simpler in .NET, more powerful in .NET.
Yes to Reflection, Inspection & Attributes. I'd also add the dynamic code generator thing .NET has (whatever that is
called), and delegates. JDK1.5 will close this gap somewhat, though, and most of these features can be emulated in Java
right now. I don't know why you'd say .NET events are better.
ASP.net is a solid step up from ASP. Seperate of presentation and business logic is much more solid,
the rendering pipeline is more powerfull, and the security features rock.
Yes, ASP.net is a lot better than ASP. The Java servlet spec compares very well with it, though,
and there are a lot more third party Java tools than for .NET.
Sun fails the Dogfood test. Number of critical applications in Solaris that are or are being ported to Java?
None, ask Sun why that is (not scalable, not fast). How much of Windows is being ported?
The whole Shabang (see Longhorn). I will be happy to re-examine Java seriously for ongoing work when
Sun's rm6 utilities (including the command lines) are written in Java.
True. MS is always pretty good at dogfooding their stuff (except for Visual Source Safe!! What's up with that!!!).
However, I think it is an exaggeration to say MS is writing all of Longhorn in .NET.
Not only that, Sun is now lifting features from .NET, clearly there is some new and cool features here to get
the ever slow sun to actually change their precious language.
I don't think either platform can afford to get into the “you copied this from us” game (cough.. C#… cough…).
Compact Framework. Share code between WinCE devices and your platform. Tie them together via Webservices
with a single click of the mouse.
Java has .NET beaten here. Java is on millions of phones and PDAs right now, and has thousands of applications in use.
Rich clients. Have the interoperability and accessability of the web without stateless programming
enviornment and pretty graphics.
Java has Webstart. However, I'd agree that .NET is a better rich client platform.
Integration. Don't want to rewrite all of your companies security? Use Domains and Roles.
Don't want to implement your own message Queue? Already There. How about Transactions, JIT ACtivation,
automagic threading? Done.
I really don't understand this one. Java is very, very strong in all these areas, with thousands of deployed
Overall, I'd say on these points it's not a clear win to either platform. The important point is that both
platforms are strong in some areas, and to say that isn't true is just FUD. .NET is a very, very good platform
and you'd be silly to write it off.