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.
“Too many frameworks”
While Java does have too many frameworks, your organization can consider the following broadest enterprise frameworks that consolidate Web and Persistence frameworks within for simplicity, etc.:
1. Open source lightweight Spring Framework which includes Spring MVC and Spring JDBC (Also works well with Hibernate or iBatis persistence frameworks). Furthermore, Spring can be extended to support dynamic Java scripting languages like Groovy, BeanShell, JRuby and more.
2. Emerging open source lightweight JBoss Seam, a Java EE 5 centric enterprise framework, that consists of JSF and EJB 3 (or Hibernate) frameworks.
“Too many IDEs… all with weaknesses”
There are lots of IDEs, too. But sticking to open source, there’s Eclipse, NetBeans, and IntelliJ. If you want to go with the one best IDE/general Java framework that supports both Sun standards and open source projects, go with Eclipse. Eclipse supports Sun’s Java standards while at the same time extending/embracing open source Java plug-ins and features which includes such open source projects as Apache Ant (build tool), Jboss Eclipse IDE, Spring IDE for Eclipse, and much more.
“Too many infrastructure component possibilities”
Again, if it’s just a simple Web application, go with Apache Tomcat, by far the most widely used Web app server in deployment in Java. It’s essentially the standard.
Now, if it’s a more complex, transaction-based Java application, deploy using one of the following:
1. Apache Geronimo is an an open source lightweight J2EE/Java EE 5/Spring compliant Web application server that integrates Apache Tomcat already. While it’s relatively new, IBM has already adopted it as part of their WebSphere Community Edition. And if you use Spring, you’re probably better off going with Geronimo.
2. JBoss J2EE Web app server is the original open source J2EE deployment tool, and is now becoming more and more widely used. If you develop using JBoss Seam, then this app server may be the best.
“Open-source energy”
I don’t agree with Neil’s thoughts on this. Open Source energy is what has saved and innovated Java. While it may seem fragmented, there are clearly enough leaders in innovation and corporate vendor community backing to make open source the key asset that Java has over .NET.
It’s really Open Source Java vs. Shared/Closed Source .NET. That’s it - plain and simple. Now, there are open source .NET options popping up, but these are still quite nascent.
“Manifestation of agile methodologies within tools”
Eclipse integrates tools such as Apache Ant (and maybe even Maven) build tool, JUnit testing, and more quite well.
Summary
So, if you want to make things as simple and efficient as possible in Java, here is my recommendation:
Use Eclipse IDE (both Spring and JBoss have Eclipse IDE plug-ins) along with Apache Ant, Apache log4j, and JUnit in conjunction with one of the following two enterprise Java path choices:
1. Spring Framework and Apache Geronimo (with Tomcat)
2. JBoss Seam Framework and JBoss J2EE app server (JEMS) (with Tomcat)
Now, the interesting issue of debate of late has not necessarily been Java vs. .NET; instead, it’s becoming Java vs. Ruby on Rails or PHP or other LAMP-based programming language/platform. The vendors such as IBM/Zend and even Oracle and BEA have realized this, and are now supporting PHP for example in their products as noted at JavaOne for example.
Look closely: enterprise LAMP stacks from Zend and others are starting to becoming reality. Are they viable? What does this mean for Java?



IntelliJ is open source?
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.
Where can I download IntelliJ source so I can mess with it?
http://www.jetbrains.com/idea/
http://www.intellij.org/twiki/bin/view/Main/WebHome
"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?
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.
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.
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.
"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.
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...
Actually, I meant to say...
But I would like to hear from those who use or are involved in open source .NET now...
Steve > see: http://sharpdevelop.com/OpenSource/SD/Default.aspx
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.
See also: http://www.castleproject.org/index.php/MonoRail
as well as: http://www.codeplex.com/Default.aspx
And while we're @ it > http://dotnetpowered.com/languages.aspx < many of which are open source.
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?
Apologies to M. David Peterson if I addressed you improperly in my previous comment(s). Cheers.
>> Apologies to M. David Peterson if I addressed you improperly in my previous comment(s). Cheers. 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.
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. 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.
>> I think open source will innovate first before Sun and MS. What do you think?
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.
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?
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 :)
chose = choice
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!
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.
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.
Charlie, well said!
Steve, I agree with both you and Charlie on this. Choices are not bad things... Lack of choices is. :)
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.
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?
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.
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.
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).
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 :)
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.
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.