A Response to: Java Succumbing to .NET in my Organization

by Steve Anglin

In response to Neil Chaudhuri on TheServerSide.com: "I would love to hear your thoughts on this topic. How can I convince my management not to abandon Java?" Well, here are my thoughts.



37 Comments

Trevor
2006-06-01 12:40:18
IntelliJ is open source?
steve
2006-06-01 14:20:27
I mentioned the open source IntelliJ. But I think Eclipse is a more complete Java IDE/general framework solution as it can handle both Sun and open source standards like Spring and JBoss.
Manuel Montoro
2006-06-02 00:23:20
Where can I download IntelliJ source so I can mess with it?
Steve
2006-06-02 07:25:20
http://www.jetbrains.com/idea/
http://www.intellij.org/twiki/bin/view/Main/WebHome
Suhail
2006-06-02 07:44:49
"While it may seem fragmented"


Fragmented is such a negative word, might as well say broken. Is so much to say its evolving through adaptation. Java gets it that the there are all sorts of problems and there is no one way to solve any of them at the outset. Diversity and Choice are not bad things. More than anything, its a landscape that requires you to know what you want.


"Are they viable? What does this mean for Java?"
Yes they are and Java will respond as it has been learning to prefection by allowing the community, either the open source community or the JCP to incorporate the best ideas into Java itself. Thereby introducing more choice and more diversity. Which is a good thing no?

matt
2006-06-02 08:57:55
IntelliJ is NOT open source. It has never been, and probably never will be. It costs a few hundred dollars for a license (well worth it though if you can afford it). It has an open extension API which does not make it open source. It only means that anyone can write extensions for it without having to pay for an SDK.


What is open source is many of the plugins which are available for it, but not IntelliJ itself.

Steve
2006-06-02 09:18:07
I thought at least the IntelliJ base product is open source as are the plug-ins. I'll have to look into this.


This may explain why it's seemingly losing steam in the market relative to Eclipse and especially NetBeans, of late.

am
2006-06-02 18:10:42

VisualStudio.Net is a commercial product. We should compare apples with apples. Meaning we should compare what products such as IBM Websphere Development Studio (based on Eclipse) or Oracles or Sun's IDE+platform combos have to offer. JBoss is an open source company that also provides these services at a lower cost (probably).


All these companies also offer courses that can get your team up to speed quickly and will give you the platform you need to get the job done. Microsoft is another vendor.


If you want to compare Java to C# then compare it to Mono. .Net is a platform supported by a company.. a fair comparison would be its commercial counterpart in the Java world.

M. David Peterson
2006-06-02 18:56:58
"It's really Open Source Java vs. Shared/Closed Source .NET. That's it - plain and simple"


How's that plain and simple?


Speaking of framework implementations:


---
.NET (the Common Language Infrastructure) has been standardized by the ECMA


Java has not.
---


---
.NET (CLI) has closed source (although there is a tool developed by an MS employee that will let you peer into the source all you want, and plug-ins that will let you output the source into a large base of supported languages), open source (Mono) and shared source (Rotor)


Java has the Classpath project which has never been supported by Sun in ANY way. MS on the other hand has worked with dozens of non-MS folks to develop the ECMA backed CLI and C# language.
---


If you are not speaking directly to the framework, and instead to the community based projects... Well then you've got some serious homework to do. The OSS .NET community is HUGE! Mono, of course, sits at the top of that stack. And, as mentioned, its a HUGE stack... and growing.


Get used to it... .NET OSS is growing... Java OSS is shrinking. .NET is growing. Java is shrinking (in usage.) My guess is that a lot of this has to do with the approach MS took that, up until just recently, Java has shunned (speaking in terms of standardization (which Sun still doesn't support any sort of initiative) and OSS (until recently its been a "hmmm... well... we'll get around to it at some point."


I will agree with the point that Java is what it is today BECAUSE of the OSS communities. But thats a compliment to the OSS communities, not Sun.

Steve
2006-06-03 12:57:57
I'm discussing in practical terms. That's all we really care about. Right now and for some time to come, open source Java alternatives like Eclipse, JBoss, and Spring are very much viable, practical used solutions. Open source .NET still has a ways to go, imo.


As far as comparing Visual Studio in .NET to only commercial products in Java, why? It's .NET that needs open source alternatives to Visual Studio (although there is a free Visual Studio Express available (still not open source)).


Again, .NET has a ways to go, imo. Now, I realize the interest in Mono (although seemingly waning of late) and growth in the number of open source .NET projects out there. But in practical terms, these are still quite nascent, and not practical.


But there are some good things happening: IronRuby, IronPython, Spring .NET, NHibernate, etc. But in practical terms, open source .NET is not ready for prime time, at least not yet.


But I would like to hear from those on open source .NET now...

Steve
2006-06-03 13:03:31
Actually, I meant to say...


But I would like to hear from those who use or are involved in open source .NET now...

M. David Peterson
2006-06-03 15:53:03
Steve > see: http://sharpdevelop.com/OpenSource/SD/Default.aspx
M. David Peterson
2006-06-03 15:58:13
I've been working on OpenSource .NET projects for 2 1/1 years... Started with Saxon.NET which was later absorbed into Saxonica by Dr. Kay of which I still work with in various areas of reasearch (see: http://www.saxonica.com/documentation/index/historical.html for a historical overview and > http://dev.extensibleforge.net/wiki/GlobalClip for links to some of the current work I am doing as it relates to both Saxon on .NET as well as > http://dev.extensibleforge.net/ < for a few more links to open source .NET development projects in general.
M. David Peterson
2006-06-03 15:59:52
See also: http://www.castleproject.org/index.php/MonoRail
M. David Peterson
2006-06-03 16:00:23
as well as: http://www.codeplex.com/Default.aspx
M. David Peterson
2006-06-03 16:01:15
And while we're @ it > http://dotnetpowered.com/languages.aspx < many of which are open source.
Steve
2006-06-03 18:05:30
Good stuff, David. BTW, what your your thoughts on J2EE/Java EE and .NET interoperability, especially beyond Web services?


Do you think that open source such as Spring and Spring .NET, Hibernate and NHibernate, etc. will innovate here first with viable practical ways to interop?


I think open source will innovate first before Sun and MS. What do you think?

Steve
2006-06-03 18:09:11
Apologies to M. David Peterson if I addressed you improperly in my previous comment(s). Cheers.
M. David Peterson
2006-06-03 19:56:18
>> Apologies to M. David Peterson if I addressed you improperly in my previous comment(s). Cheers. <<


I'm just happy when people are calling me names that fit within my own namespace :D (M., David, Peterson, Mark, any variation there of :D)


As far as interop goes, hands down... IKVM.NET (http://weblog.ikvm.net) > It provides as much Java support as the Classpath project provides, but compiles this into a .NET assembly. If your Java app will run via Classpath, it will run via IKVM.NET more often than not.


There are some minor exceptions... you can view the latest JAPI comparisons via > http://www.frijters.net/ikvm-japi-status.html <


Mono derives its Java support directly from IKVM.NET, and Saxon.NET (now Saxon on .NET since Dr. Kay brought it officially into the Saxonica family last February) has been running via IKVM.NET for almost two years now.

M. David Peterson
2006-06-03 20:00:29
Quick note: Steve, I forget O'Reilly has this set to only accept one link per comment, otherwise it holds it for approval. I took out one of the links so please just delete the one in the holding queue.


>> Apologies to M. David Peterson if I addressed you improperly in my previous comment(s). Cheers. <<


I'm just happy when people are calling me names that fit within my own namespace :D (M., David, Peterson, Mark, any variation there of :D)


As far as interop goes, hands down... IKVM.NET (http://weblog.ikvm.net) > It provides as much Java support as the Classpath project provides, but compiles this into a .NET assembly. If your Java app will run via Classpath, it will run via IKVM.NET more often than not.


There are some minor exceptions... you can view the latest JAPI comparisons via the "Japitools Status" link to the right on the above link.


Mono derives its Java support directly from IKVM.NET, and Saxon.NET (now Saxon on .NET since Dr. Kay brought it officially into the Saxonica family last February) has been running via IKVM.NET for almost two years now.

M. David Peterson
2006-06-03 20:03:43
>> I think open source will innovate first before Sun and MS. What do you think? <<


We can take more risks than they can, so by default I think you are correct. Thats not always the case (e.g. LINQ) but in more cases than not I believe you are spot on in your viewpoint.

Arnie
2006-06-05 12:18:52
Well, the problem with Java is the development speed. I you can find a way to code faster that in .NET then you have it. That is the most important argument.
Steve
2006-06-05 14:36:38
You can code as fast in Java using productive frameworks such as Spring, etc.


And there are more and more lightweight solutions in Java, which makes Java faster to code, faster to run, and more...


Can you be more specific?

M. David Peterson
2006-06-06 21:06:11
I would argue less in regards to whether or not you can code faster in Java or C# -- regardless of the framework -- and more about the fact that with .NET your chose of languages is just that... your choice.


With a list of supported languages (linked to in one of my comments from above) thats already quite extensive, and growing at a consistant pace, the reason .NET is a more pleasurable experience is that you can pick and choose from a variety of tools, each of which have their advantage for one reason or another for whatever the task at hand might be.


And with projects such as IronPython (currently in Beta 7 of the 1.0 release > http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython < (the goal has been stated to keep the beta numbers in the single digits... they release about every three weeks or so)) an expanding set of dynamic languages are being added to the mix that simply make programming on .NET WAY TO ENJOYABLE for our own health :)

M. David Peterson
2006-06-06 21:06:52
chose = choice
Simon Hibbs
2006-06-07 04:11:35
Steve:


>As far as comparing Visual Studio in .NET to only commercial
>products in Java, why? It's .NET that needs open source
>alternatives to Visual Studio (although there is a free Visual
>Studio Express available (still not open source)).


SharpDevelop: http://www.icsharpcode.net/OpenSource/SD/Default.aspx


Graphical IDE for C# and VB.NET with syntax highlighting, code completion and drag-n-drop GUI builder, integrated NUnit support and tons more. Automatic Visual Studio project conversion too!

Charlie Collins
2006-06-07 05:12:41
Good points about particular frameworks but I think a lot of people are losing sight of what the TSS article and discussion really was about. The main point of the article was that Java has "too many frameworks" (as the author here addresses with particular suggestions).


This "issue" with Java is better addressed by responding, no it doesn't have too many frameworks, thats silly.


First off "too many" is impossible. There are complex problems in development and many people solving them in various ways is not a BAD thing. The nature of collaboration and open source results in lots of different ways to do things and this nature is not by itself bad, quite the contrary (no Java is not open source, but I lump it in here because the nature of the license and availability makes it often used in many GPL/LGPL style products, such as many of the frameworks mentioned). This notion is just as dumb as when people say there are too many Linux distros or too many SMTP servers, etc. All those "choices" are someone elses way of dealing with a problem that they felt was not being addressed by existing solutions and for one reason or another did not belong as simply a contribution to an existing entity.


Secondly the SAME PROBLEM exists now (or at least certainly will when it becomes popular enough) with .Net. .Net has the CLI stuff and you can run it with Mono (and other implementations), .Net has Hibernate and Ant and so on "clones". These are just good frameworks and patterns for solving problems, they are not necessarily specific to Java.


Lastly having to be aware of the various frameworks and implementations available to you (and for that matter the server platforms and programming languages themselves and so on) and make an informed intelligent choice about which to use - or to not use any at all (ode to Geddy Lee, sorry) - is a part of sound development. Just saying "aaahhhh I give up too many choices" and then *choosing* .Net is not responsible development (and this is no dig at .Net itself, its just the old "choose the right tool for the job", saying its .Net because it has fewer choices is just plain false and not a valid reason to choose .Net - though other *actual* reasons certainly may lead to that choice).


The entire premise that "Java has too many" . . . is just silly at every angle.

Steve
2006-06-07 07:24:42
Yes, I was responding to Neil's TSS piece. I was helping him and his organization narrow down/consolidate the many framework options out there.


Maybe for them, there are too many. But I agree, it's always better to have choices. But for organizations/companies, they sometimes want a much more consolidated set of choices, I think.

M. David Peterson
2006-06-07 07:54:13
Charlie, well said!


Steve, I agree with both you and Charlie on this. Choices are not bad things... Lack of choices is. :)

M. David Peterson
2006-06-07 08:04:58
One extended comment: To those who have a tendency to respond "yeah, but how do I decide which is the right one to use and why?" I would respond,


Don't let this question get the best of you. Find something that feels right for the job, that makes sense to you and/or your developers working on a particular project, and then move forward with that decision. While there may be a few "oh, I wish we would have done this with this tool, or that in this other particular way" at a later date, that's all part of the software development process. As time goes on you will find ways to make your code base better so don't worry too much about making the "right" choice according to some other person(s) and their feelings as to which choice is better and why. Just choose what makes the most sense to you and be happy knowing that whether its .NET or Java, or both (which is where I see a lot of projects moving towards... it doesn't have to be one or the other.), you have two solid, well proven frameworks and runtime engines from a variety of sources that will ensure your code will run on every significant platform out there.


That's what I think is most important to all of this... The underlying platforms help make it REALLY HARD to make a bad choice and really easy to "fix" things later if you do.

Steve
2006-06-07 12:03:08
We're starting to see enterprise LAMP stacks from Zend and others? And Ruby on Rails with Mongrel makes for a nice solution already as well, at least in the Web-tier.


What does this mean for Java now and/or in the future?

M. David Peterson
2006-06-07 14:22:45
That depends on whether the Java insiders decide to embrace a language neutral strategy similar to that of the CLI. With the CLI there is a very clearly defined route for any language to develop a compiler that emits CIL. NOTE: I assume that everyone already has come to understand that CLI and CIL are two separate things? If not, CLI is the actual spec from the ECMA for the Common Language Infrastructure, CIL (what used to be MSIL before they standardized with ECMA) represents the actual Common Intermediatte Language, which is somewhat comparable to Java byte-codes in function, but is really more of a high level (read: much more human readable/understandable) Assembly abstraction.


If Sun were to,


- Embrace a solid standardization effort.
- Openly support any effort in which someone who wants to build a compatible run-time engine can openly do so (e.g. Mono, as we all know, is a GPL'd runtime implementation of the CLI which is in full compliance with version 1.1 of the spec, and EXTREMELY close to full compliance with version 2.0). Of course, might hat goes off to Mark Wiellaard and the rest of the Classpath project developers who have pressed forward and brought the code base to within spitting distance of a full 1.5 Java implementation, without anything but the documentation made available to them from Sun (If I am wrong about this, and in fact Sun has supplied more than the same documentation that is publicly available, please correct me, as I would hate to suggest this to be true (I think it is) and find out later I had made incorrect statements.)
- Choose a standards body to officially take over and oversee the language and platform specification.
- Allow anyone who wants to be a part of the development of future versions of the platform and Java language implementation a clear route to joining this standards body committee that oversees this effort.


If they do this, then all of these language projects (e.g. Jython, Groovy, etc...) in which a solid effort has been put forth by a TON of talented folks to build domain specific language implementations that emit Java byte-codes would, I'm guessing, would pave the way to bring Java (the platform) back into the game as a true player in the platforms business. If they don't do this, then how can they possibly compete at ANY level with the CLI in which has a growing base of enthusiastic developers who are building all sorts of killer language and platform extension implementations.


At present time, with a clearly defined path for anyone who wants to build a runtime implementation, language compiler, platform extension, etc... and absolutely zero obstacles in their way to do this, the CLI and those in whom build against the various mentioned run time implementation as well as language/platform extensions, is the clear and uncontested winner in less than five-seven years.


If Sun were to take them head-to-head, then who knows... but they certainly have some catching up to do, thats without a doubt.

M. David Peterson
2006-06-07 14:29:49
might = my
+
"less than five-seven years." makes no sense... its either less than one or the other, or within the range of five to seven years.


I'll play it safe and go with the range of five-seven years.

Will
2006-06-08 10:59:50
The real key here that seems to be missed is this: While there is a lot of variety in the Java space, and that variety helps the entire community grow, none of the mainstream frameworks or toolset are horrid and terrible. No project will fail based on picking any of these tool sets, they're all flexible enough to accomodate most anything.


As long as your teams understands the fundamentals (basic servlets for web apps, basic EJB for EJB, or Spring fundamentals), the rest is all gravy.


We always have our eyes wandering for the next Great Thing, but in fact simply picking one, ANY one, and mastering it will solve most any problem. They'll just solve it in their own way.


None of these frameworks is a Silver Bullet, rather they're simply another round of ammunition in the constant battle to provide services to your clients (whether internal or external).

M. David Peterson
2006-06-09 04:30:45
VERY well stated, Will.


You know those times when someone says something, and you wish it was you that said it?


This is one of those times :)

Jeroen Wenting
2006-06-11 23:44:50
Java is entering an era where it's no longer the rebellious kid on the block but the established enterprise platform. That's a position similar to the likes of C++ and Cobol, and enterprises expect certain things from those platforms. Foremost among those is stability, something that the glut of "frameworks" and competing tools and libraries that constantly appear for Java (not to mention the enormous number of overhyped "new" technologies) show Java not to have (at least in the eyes of those who look to press releases as their main source of information).


The fact that overhyped techies are constantly predicting the "death of Java" due to .NET, Ruby, or whatever doesn't help either to establish the platform as a stable one to CEOs (who are ultimately the ones to make decisions on large deployments in large companies).


Unless the techie world changes to provide an outward display of stability Java will continue to have to face a wall of opposition to continued adoption at large corporations in competition with better marketed platforms like .NET.

M. David Peterson
2006-07-12 12:21:37
Thats a VERY GOOD point, Jeroen, and based off of the report I recently > http://www.oreillynet.com/windows/blog/2006/07/the_beginning_of_the_end_for_j.html > blogged about, I'd say you are pretty much smack dab accurate on this one.