Dot Net Will Kill Java
Dot Net Will Kill JavaWell, no, not really, but here's what one guy says...
Not only that but the scalability of ComPlus is debatable, and hey, don't forget DotNet only runs on MSFT platforms - oh I guess that is cross-platform: Win98, WinNT, WinME, Win2k, perhaps WinCE? Not.
DotNet has NOTHING to do with ComPlus. It is built on top of XML, SOAP, HTTP. It has no COM anything in it. The CommonLanguageRuntime is PORTABLE TO ANY PLATFORM and does NOT ONLY run on MSFT platforms.[For example, Ximian's MonoProject runs on Linux with x86, ARM, Sparc or PPC CPUs. Microsoft's Shared Source ROTOR (see SharedSourceCli) runs on FreeBSD. For more examples, see DotNetForLinux.] The ECMA standards will be open-source. Simplicity of Java but integration with any language (14 at this count) rather than you have 3 choices: Java, Java or Java. The world is NOT going to re-write millions of lines of legacy code in Java no matter what Sun's marketing machine says. DotNet does Cobol as well as 13 other languages.
"Java, Java or Java"? Please take a look at the OtherLanguagesForTheJavaVm. There are more than the three you're mentioning. -- ManuelSimoni
Hmm, XML, SOAP, and HTTP. That sounds like a slow combination to me. For most uses probably the ease of use is worth the slowdown, but not for me. Well, professionally its probably fast enough, but for what I do in my spare time I doubt that it will be fast enough.
Argh, FudFromBothSides?. I'm with BeatingTheAverages.
And what do you mean by OpenSource? Java isn't really open source, but there are now libre implementations of both the VMs and compilers, so we are subject to their future whims. However, I doubt that MSFT is actually going to release their source in a paletable license (meaning GPL, LGPL, or BSD).
Rather than continue what could be an off-topic discussion here, go see EcmaProcess.
How about JavaLanguageIsOpenSourceNot? and DotNetCanBeOpenSourceNot? while we're there?
"Can be ported" is not the same as portable. First, let's see a real implementation on something other than windows that - and this is important - does not depend on have a windows box somewhere to have full functionality. Second, if the CLR on a non-windows platform lacks anything that is available on windows (modulo restrictions for low-end devices like PDAs) then it's not really all that. Heck if I want to use DCOM from a non-windows box I can do that now with Java through jIntegra. It doesn't magically confer DCOM onto Linux, though. -- StevenNewton
This has nothing to do with DCOM. SOAP is the replacement for that. This has nothing to wih Windows. The CommonLanguageRuntime is a VM that hosts languages and makes services available to them. It doesn't need any Windows functionality. You will see a real implementation on other platforms when (ha!) they (heh!) finish the EcmaProcess.
I'm also looking forward to non-Windows implementations of DotNet, but unlike others here, I don't see it as a terribly big challenge. From the discussion, there are four core technologies that drive DotNet: SOAP (which implies XML), HTTP, and C#. SOAP, XML, and HTTP are certainly not Windows-specific. And while people fear C# will somehow be Microsoft-specific or Microsoft-centric, I'm less concerned with that because if C# is a useful language, it will be ported to other platforms.
I've not heard any indication from Microsoft that DotNet will be ported to any platform but Windows. COM is also an "open standard" but it has never been effectively ported to any other platform. Also, while portions of the CommonLanguageRuntime and the entire CsharpLanguage are being submitted to ECMA for standardization the library isn't. That almost certainly means non-portable applications. Finally, while the CommonLanguageRuntime can potentially support many different languages, it doesn't actually support any existing language in its original form (not even VB). That means that there are very few existing applications that can just be recompiled and run on DotNet. In all fairness the porting process should be fairly easy for most applications. I would expect the kinds of changes needed to be fairly trivial technically; like changing the names and expected sizes of some of the primitive data types you are using for instance. But the time and money needed to make those changes may not turn out to be so trivial in some cases. Don't get me wrong DotNet has lots of potential, but it's no Java. At least it isn't yet. -- PhilGoodwin
Yeah, DotNetWillDefinitelyNotKillJava?. However, if Microsoft breaks with tradition and actually creates a VM for all the major platforms (including stuff like PalmOS, not just Windows CE) then there might be a chance for C# to supersede Java. However, this has never happened any other time they've promised support for multiple platforms so I don't see why it would happen this time. Remember when MS called DCOM portable? However, how many people use DCOM over CORBA in a heterogenous computing environment - some, but not many. I'll take the wait and see approach before I proclaim JavaIsDead. -- RobertDiFalco
Clearly, the greatest benefit of DotNet is the MicrosoftIntermediateLanguage (or IL) which every VisualStudio language is compiled down to (Yes, this includes Smalltalk, C#, VB, C++, Python, Perl, Cobol, Eiffel, the list goes on). You can derive VB objects from C++ base classes or create Python collections of C# objects.
The JIT compiler can compile to native code during installation rather than runtime (No doggish VM! Yeah!). ASP+ web pages become compiled and cached rather than interpreted and stateless.
Process recycling will help developers work around those hard to solve problems where the server intermittently crashes when a number of random resources are all used at once (and can't be recreated for debugging).
Java may never die, but I doubt we'll ever see a Java based implementation top the charts at http://www.tpc.org. --MichaelLeach
"DotNet gives the simplicity of Java in many programming language."
Interesting. Does this mean "DotNet is going to simplify things by supporting lots of different languages." How can one have "the simplicity of Java" in say, C and C++? (I thought that a major part of the "simplicity of Java" came by throwing away the low-level and overcomplicated stuff from C++.) Could whoever made that claim explain exactly what "the simplicity of Java" is if it isn't all language specific. It's also going to be interesting to see how a common type system is going to work with Smalltalk and prototype-based languages.
I can't help but be reminded of JanSteinman's email signature "Java: the blinding speed of Smalltalk, and the elegant simplicity of C++". Sounds like DotNet is trying to be everything to everybody. -- RandyStafford
Is VB going to be supported on DotNet or is it going to be quietly dumped?
With DotNet, VB gains parity with VC++ and C#. It gets full free threading for COM components, inheritance, etc. Basically, all the languages that run on MicrosoftDotNet will be on a level playing field.
I may misunderstand what I've read, but it was my impression that .NET is essentially just a VirtualMachine and Runtime. I don't understand these comparisons of .NET to various languages. Seems like comparing an OS to an Application that runs on an OS. Maybe because C# and .NET were hyped at the same time, people tend to confuse them, but it is my understanding that C# could be implemented without .NET and that .NET can be used as a VM for many other languages than C# (Take the Eiffel implementation, for example). -- RobertDiFalco
That's right Robert. Languages are really a layer above what .NET is all about, a CommonLanguageRuntime. See MicrosoftDotNet for more details. -- DrewMarsh
Of course, if the VB and smalltalk experience is anything to go by .NET will not support any other languages unchanged. VB.NET has a different syntax and semantics to the old VB (see: penultimate paragraph here: http://www.devx.com/upload/free/features/vbpj/2000/11nov00/en0011/en0011.asp) and its the same for the smalltalk implementation. Perhaps we should say that .NET will support multiple new languages that look a bit like various old ones.
More about what's being called 'VB.NOT': http://www.mvps.org/vb/rants/dotnot.htm.
Could this be the death blow?
http://msdn.microsoft.com/visualj/jump/
From the FAQ:
Q: Does this mean Microsoft is supporting the Java platform?
Absolutely not. Microsoft is supporting Java as a programming language, and is helping developers migrate from the Java platform to the .NET platform. Customers interested in pursuing Sun's vision of Java will need to go elsewhere to find that support. -- DrewMarsh
Given that the vast majority of java developers (as far as I can tell) are indeed interested in pursuing Sun's vision of Java, and are already going elsewhere to find support for doing so... I don't see how this could have much of an effect on Java. Is there more on that link which speaks to this point? -- BrettNeumeier
I don't really think so either... I only posted that because it suited the topic and I thought people might find it interesting. I think those who have chosen Java as their language/platform of choice have done so because it suits their needs and I don't think it affects that type of developer in any way. -- DrewMarsh
JUMP isn't a death blow, it's just good business. There are lots of Microsoft-platform programmers that used J++ for important systems. Microsoft can't leave those people out high and dry - they need a migration path. Hopefully the new WinForms? API will be similar to J++'s WFC, which was actually quite pleasant to work with despite the keyword additions. Microsoft's innovation on Java in the past has benefitted one audience: Windows developers. They're continuing to follow that path with this approach.
I only used J++ for "100% pure" development and found it to be excellent for that. A very neat IDE and it turned out to be perfectly simple to add the Swing .jar file to my project. Thanks to the lawsuit, it goes to the ends of the earth to warn you if you're going to use something Windows-specific. And it runs so much faster (and in less memory) than all the IDEs written in Java, of course. The end results tended work pretty well in Netscape on Linux (aside from the occasional bug in the Netscape Java VM.) -- DanielEarwicker
I did too. It was awesome until Sun's whining made them stop it. It warned you to the point of nauseating you about using things Windows-specific. I and others inside MicroSoft would have been very happy using Java as a language for COM and Windows development but Sun had to whine. Now they eat the results.
The only concern I think is that Microsoft really wants to win back developers' hearts, and hasn't quite found a way yet. We'll have to see how well .NET does as a whole - my current feeling is that it will definitely keep Windows developers from migrating elsewhere, but won't attract a horde of people back to the mothership (those that veered away to Linux or Java). I work for a company that was a die-hard Microsoft shop before I joined, and it just happens that our clients and direction are (currently) drifting away from what Microsoft is aiming at with .NET, and more towards Sun & Oracle's vision. On the bright side diversity is good, on the bad side, industry fragmentation is becoming higher. -- StuCharlton
MicroSoft wants to have the hearts of minds of the individual developers. Two things have happened to erode MicroSoft's legendary grip on developers. One is that many people, for better or worse, adopted the Java language and platform as their choice. MicroSoft wants to win some of those people back. MicroSoft is not likely to have much effect with them. But there is a pool of Microsoft Visual J++ users left totally abandoned with what they saw as a really neat and preferred way to develop Windows programs. These people are likely to respond to this program.
From what I have read, the .NET runtime does not give you true multilingual interoperability. Many languages have to be modified to conform to the VM's type model. E.g. the VM does not support multiple implementation inheritance, covariant return types or contravariant argument types (sounds very similar to the JVM).
For example, multiple inheritance of implementation is a fundamental design technique in the Eiffel and C++ languages that is not supported by the VM. Eiffel has been modified to work on the VM, and I assume that C++ has had to be as well. Similarly, most statically typed OO languages (apart from Java) support covariant return types.
(If this is wrong, please correct the above).
-- NatPryce
Brad Merrill of the MicrosoftDotNet team wrote:
No, the smalltalk folks aren't modifying their language. What you should be clear with folks about is whether or not you want to support "cross language" multiple inheritance. And the behavior of that changes for each language, for example in Eiffel they can rename inherited methods. But that's a language characteristic, and not the runtime's behavior.
and (at http://www.eiffel.com/doc/comtech/white_paper.html):
[With regard to Eiffel, there are] a few interesting issues for its integration in the Microsoft .NET Framework. Maybe the most challenging is the support for multiple inheritance, since the common language runtime was designed to support single inheritance only. Because Eiffel# must only use the common language runtime, it has to follow the .NET object model and thus disallows multiple inheritance of effective or partially deferred classes. You may however multiple inherit pure-deferred classes in which case they are generated as interfaces. The partially deferred or effective parent class, if any, is the base type.
There are probably some things which are unlikely to be implementable in the context of .NET (I hesitate to say impossible), however, such things may require more work than they would need otherwise and it may not be justifiable. However, what .NET really does is reduce the cost of converting existing code bases to .NET. The cost is much lower than it would be if a brand new language were enforced. Some projects will have a lot more refactoring than others, but it will still be (hopefully) refactoring, not redevelopment.
If you always stay within the same language, you are able to fully implement that language's syntax and behavior. The decision on whether to do that, and how, depends on each implementor.
If you want to export components written in your language, then you need to apply the rules of CLS, in order that other languages may understand and interoperate.
The case that seems to confuse most people is multiple inheritance, which is, for now, a programming language construct, whose behavior when applied across differing languages' implementation of multiple inheritance, may differ. Between any 2 languages, and outside of the CLS rules, you could define exact behaviors and implementations.
Where does DotNet define things like enterprise servers (ala ComPlus, J22EE or CORBA)? This is where the real strength of Java lies, IMHO, and until DotNet includes a non-Windows-specific alternative, I can't see it being a Java killer. Interesting, yes. "JavaKiller?", no.
I also applaud Microsoft's decision to standardize the core components, but I'm hanging back to see how it plays out. For it to knock out Java in the enterprise space, they'll need a much bigger industry wide-alliance; the sort of alliance that Sun has spent the last few years building. -- RobertWatkins
It is in MicroSoft's best interests to make DotNet successful, and then tie it firmly to the Windows Platform. Their most effective strategy is "embrace and extend" - make sure that competing implementations are always catching up to the moving target. This is a tried and tested tactic (not just by MicroSoft), and there's no reason it should be different just because they helped write the original standard. MicroSoft has always done what's in MicroSoft's best interest because that's the company's job - to maximize its value.
Interesting SOAP quote from DaveWiner on ScriptingNews:
Andrew Layman, the top XML guy at Microsoft is clearly planting the seeds for Microsoft's disapproval of what we're doing with the BDG. They have been so resistant to it, so fearful of it, so fear-provoking of it. I don't know what their internal plan says about the future of SOAP, and how many "full" implementations there will be, but I suspect the number is 1, maybe 2 (gotta keep up the appearance of it being open).
DotNet looks like a very interesting platform. But I'm going to take a lot of convincing before I believe that its cross-platformness is anything but temporary spin. -- CharlesMiller
Ditto. My favorite C# quote is from a pro-C# article by Jesse Liberty. "C# is about letting go of precise control, and letting the framework help you focus on the big picture."
Makes me wonder where that "control" goes when I give it up...is that prickly feeling on the back of my neck a monopoly sneaking up on me?
-- EricRunquist
What I've learned thus far about the relevance of a cross-platform .NET: what good is the platform without all of the goodies? The majority of people interested in .NET are enterprise developers, I would imagine. Solaris/Linux/AIX/OS390 versions of the CLR and C# will not support ADO.NET, ASP.NET, Microsoft's XML libraries, ComPlus services & the DTC, clustering, etc. It would require other companies to create their own fragmented / competing implementations. What incentive do these companies have to compete with Microsoft? Especially when Java is effectively as sophisticated as .NET is?
Microsoft has a vested interest that .NET runs "less than stellar" on non-Windows platforms. Unless there's a mass migration away from UNIX and Mainframes (possible but somewhat unlikely), .NET is not going to take over the enterprise universe. -- StuCharlton
Good points. There are a few OpenSource implementations of some parts of .NET in the works - DotNetForLinux. -- EricRunquist
It is true that DotNet is immature, and it will be two or three years before everyone wants to use it. But the same was true of Java just a few years ago. As with Java, those who get in early on DotNet will suffer a lot of frustration for a while, but they will be ahead of the curve whenever it grows up and the market embraces it.
Like all things, both Java and DotNet will eventually die, but I don't think one will kill the other. They will both grow, morph, and adopt each other's best features. Then something else will come along.
-- KrisJohnson
What about where you have Java for a Dot Net platform?
Borland look like there going to make the next version of JBuilder Dot Net, Delphi 8 certainly will be. Microsoft are currently making a VisualJaySharpDotNet for the the dot net platform, before they make C++ fully Dot Net incidentally.
So should the question be, will Dot Net kill the Java Virtual Machine rather than will Dot Net kill Java?
-- SteveEyles
What DotNet requires is a proper UNIX implementation. Already, VB/VC++ combination is dominant in desktop systems. Only area Microsoft is lacking in is server side application (although they have good share in this arena, Java is dominant because of J2EE implementations). Once there is a viable alternative on UNIX (like Mono, DotGNU, etc), I think .NET will become more dominant over the time. The .NET technology is good, APIs are available, there is a good and integrated IDE, only requirement is multi-platform implementation. -- VhIndukumar
Dot Net will not kill Java; if Java dies, it will be because Java killed itself. I am not saying I expect to see Java to die, I am just saying that Dot Net will not influence Java much one way or the other.
In the best of worlds, Bill Gates and Scott MacNeally? would quit squabbling and agree to a common virtual machine for both Java and Dot Net. The end result would benefit both companies and save wasted effort. Unfortunately, that will not happen, so we will have to live in a world of both technologies and bit twiddle to bridge between them.
There are many very large businesses that will not agree to the MicrosoftCorporation EULA. J2EE is more comfortable for them as they feel there is less chance of getting shafted, regardless of any technical pros and cons.
Updates
On Transaction Management At end 2005 DotNet EnterpriseServices library is (still) used to generate ServicedComponents, within which ComPlus ComComponents? are invoked if you want transaction facilities. There is also a mechanism for ComComponents? to reference managed code via ComCallableWrapper (see ComInterOp). I am not aware of any commercial grade Java products that can access legacy ComComponents? (And outstanding WebServicesInteroperabilityConcerns will probably discourage people thinking of integration via the WebServices route). In future WindowsCommunicationFoundation may provide a different mechanism of implementing transactions.
On Distributed Objects
What kind of requirement scenarios dictate the construction of comlicated distributed object computing solutions? Could a company like Amazon not function well with a solution constructed differently? In a post DotCom era do we have much need for business solutions "requiring" distributed objects?" -- dl
A good argument for the JavaPlatform can be found at http://www.manageability.org/manageabilityWiki/WhyJavaIsBetterThanDotNet (BrokenLink)
EditText of this page
(last edited December 8, 2012)
or FindPage with title or text search