Java Champion / JavaOne Rockstar Adam Bien ( is a self-employed consultant, lecturer, software architect, developer, and author in the enterprise Java sector. He is also the author of several books and articles on Java and Java EE technology, as well as distributed Java programming. adam has posted 59 posts at DZone. View Full User Profile

9 Reasons Why Java EE 6 Will Save Real Money

  • submit to reddit
  1. Prototyping: in general (Enterprise) Java projects start with evaluation which frameworks to use. This can take from few hours, to several months (although these times are hopefully over). Java EE 6 comes with “one stop shopping”. You can download Java EE 6 with the IDE (eclipse, netbeans, jdeveloper and commercial IntelliJ) and just start hacking. You can install and develop a prototype in minutes. The package sizes are small e.g. NetBeans 6.8 with Glassfish v3, Derby and all required plugins take 146 MB Eclipse with Glassfish / Java EE tooling is also small: 147 MB for MacOS X.
  2. Development: Java EE 6 implementations are lightweight. Glassfish comes with 30 MB for the Web Profile, or 75 MB (everything). Deployment takes only few milliseconds. Incremental deployment is supported out-of-the-box. You only have to save the file. The other application servers (JBoss, Caucho's Resin, Geronimo / openEJB) are expected to be similarly lightweight. Because the majority of the libraries and frameworks is already located on the server, you have only to deploy the application code. The deployment archive contains mainly your application code and is so surprisingly small - a kilobyte deployment is possible.
  3. Production: Glassfish, JBoss, Geronimo and probably the others do follow the opensource model. You can decide whether you need commercial support or not. You can start small - then scale.
  4. Licensing: Java EE 5/6 applications are surprisingly portable - there are no more vendor specific deployment descriptors required. You can easily port your application from one server to another. It is actually the matter of copying of an WAR / EAR archive from one directory to another. We actually did it in the past to ensure application server independence. These are is possible since Java EE 5 and so 2006. Knowing that, you have a good position to be able to get better offers for licensing / support. You are not dependent on a particular vendor and can pick the most interesting one.
  5. Training / Knowledge: You “only” have to learn Java EE 6 and so its API - the start is easy. This knowledge is generic and can be applied to any application server out there. If you know Java EE 5 already - you will love Java EE 6 :-).
  6. Portability: ancient legacy J2EE 1.X projects are easy to migrate to Java EE 5/6. Java EE 6 containers still have to support the old programming model. Porting your application is fun - it mainly consists of deleting superfluous artifacts. J2EE 1.X and Java EE 6 components can even peacefully coexist.
  7. Adoption: Java EE 6 was developed by the JCP. It wasn’t developed by Sun, rather than by the community and all major players. IBM, Oracle, SAP, Red Hat, Google, even Spring Source / VMWare (Rod Johnson) contributed an API. The Java EE 6 spec is expected to be adopted as well as Java EE 5. There were 14 different certified Java EE 5 servers.
  8. Freedom of Choice / Investment Protection: because Java EE 6 was developed by the community (BEA, IBM, SAP, Oracle Sun, SpringSource etc.), and not a single vendor it will remain stable. It is impossible for one entity to change / break the spec, an API. This is a huge advantage of Java / Java EE over other languages. You can still run your ancient J2EE 1.4 apps on your shiny Java EE 5/6 server without any modifications.
  9. Risk Mitigation / Plan B: Java EE APIs are not intrusive and heavily based on annotations and Convention over Configuration / Dependency Injection principles. In case for some reason Java EE 6 will not work for you - the migration to the alternatives like Spring is relatively easy. Both components models (EJBs, CDI / Spring) are rather similar.
Published at DZone with permission of its author, adam bien.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Artur Karazniewicz replied on Sat, 2009/12/26 - 3:33am


Althought I see some of Your points little bit exaggerated (like who cares if glassfish is 30 or 300MB of downloads - guys it's 2010 almost, we have broadband and terabytes of disk-space, who actually cares? 'ons-stop-shop' - do anybody believe that in real-life application you will need only stuff provided with JEE?, deployment size? - reminds me times when we compared processor cycles - but hey - C64 gone 20 year ago:) - but actually I agree. Unfortunately this is only one side of equation. The other one, quite heavy and real, which everybody will have to confront with above points, is migration cost. You see the whole problem with JEE 6 is that's... runtime. Means that I have to convince my company to redo all QA stuff, migrate all legacy applications (even those which are not supposed or needed to be migrated - just because I have to upgrade runtime, regardless my application will benefit from JEE, or not), train support and infrastructure staff, probably buy some licenses, support and finally migrate lots of app servers just to be able to use JEE 6... It's what I call barrier to entry. Those are real, hard numbers which have to be confronted with above, quite valid statements. Even worse, fist I have to wait for JEE 6 support in all allowed servers in my company (usually companies standardise on some particular Vendors or servers and usually You are not easily allowed to introduce new one). So far we have one and only one certified JEE 6 server. Glassfish. Unfortunately in most companies, having seen market share numbers, Glassfish isn't on the list of allowed servers. So we have to wait for vendors catching-up. I remember that in the case of Oracle, IBM or JBoss leap from J2EE 1.4 to JEE 5 took almost 2 years. Maybe this time it will be little bit faster - but will see yet. The problem is that relatively small and incremental change in the JEE (actually nothing ground breaking) comes with ground breaking changes in the whole runtime. Why we cant have stable core - like lightweight runtime kernel (threading, pooling, clustering), JTA, JCA as a runtime and pluggable 'containers' (EJB 3.1, CDI, JPA 2.0 etc.). This would drastically lower the barrier for this technology. Now we have nice, but still nothing ground-breaking (it's what we have EJB 3.1, not 4.0), new version of JEE which needs huge effort of time and money to be adopted. I said myself I would not join the holy 'Spring vs JEE' war - but take a look at Spring 3.0. It's, form my point of view, drop-in replacement. It's my, Architect's decision. I could have new version of spring based on pure technical merit, not no budgeting and all this stuff. Wouldn't it be nice we could have 'JEE' container and put it as a part of deployment regardless we have this or that runtime, in this or that version? We have it actually right now - it's embeddable EJB container - but actually it's not that easy, if possible, to put this on, say, JBoss 4.2, or Oracle iAS 10.2. To sum up - I'm, for the first time, from dark ages of early J2EE considering JEE 6 as a viable option (JEE 5 was still painful in my opinion), but unfortunately, I probably will have to wait 1-2 years to be able to use it in production. That's the problem.

Otengi Miloskov replied on Sat, 2009/12/26 - 2:12pm

Your article Rocks, and JEE 6 is wonderful!.

@Artur the vendors will follow very soon, Already on my VPS provider they are mounting Glassfish 3 so on many VPS's JEE 6 will be supported soon enough, Just be patient.

Spring is like to say help your self(Self service).

JEE 6 everything is out of the box.

I like Spring and MVC but after checking the JEE 6 spec and what the expert groups accomplished Im turing full steam to JEE 6 development. Anyway If I need a MVC framework Struts 2 is the best one out there and already have plugins for JEE 6(CDI) and much more.

Raphael Miranda replied on Sat, 2009/12/26 - 8:23pm in response to: Otengi Miloskov

It's a competitior for Spring 2 but it loses to Spring 3 in all those points mentioned in the article when considering Grails and Roo.

If one is comming from a Spring shop that has upgraded to Grails or Roo than JEE6 is out-dated already.

Otengi Miloskov replied on Sat, 2009/12/26 - 8:38pm in response to: Raphael Miranda

Grails and Roo?. Do you think the big players or even small shop are going to bet on grails? c'mon. If thats the case I will go striaght with JRuby and Rails.

In a Java Shop with Java the language we dont care Grooy,Grails,Rails or Roo's or whatever. It is Spring or Java EE and Java EE 6 have all out of the box compared with Spring 3. Your comparistion does not make sense really and I was not discussing if Spring 3 is better than JEE 6 or my framework vs your framework. My point is with JEE 6 we have out of the box the features and with Spring are self service.

Wal Rus replied on Sat, 2009/12/26 - 11:55pm

will somebody look beyond the usual yada-yada and realize that making new standards and then getting people to move onto implementation JEE(next) is a way that this industry survives. There is nothing bad about it and so there is nothing good either. It's just a usual progression of things lingering along the net zero line. No money to be made there. No money to be lost there. Just moving the money around and staying in the game.

Henk De Boer replied on Sun, 2009/12/27 - 5:16am


For us upgrading Java EE is about the same amount of work as upgrading Spring. We don't see the AS as some irremovable piece of software that statically resides on our server until the God System Administrator gives his blessing to upgrade it.

Instead, for us the entire AS is just an application on the JVM. So it doesn't matter whether we update Spring (inside a war or inside the common lib directory of the AS), or the AS itself. We'll deploy both just as easily.

Wat REALLY matters is not the deployment, but testing whether the app as a whole still works after some update. This is work that has to be done both for upgrading Java EE and Spring. It think Java EE is easier here, since it's more everything out of the box. Just like in Linux, you're not going to test yourself whether the supplied version of Firefox cooperates nicely with the supplied Thunderbird in say Ubuntu 9.10, but of course you do test whether your own code still works.

And yes, Jboss AS 5 took some 3 years, a somewhat shameful amount of time. But, to their defense the bulk of that time went into re-architecting their micro container, which was a completely separate effort from the Java EE 5 implementation. Jboss AS 4.2.x. already had a lot of Java EE 5 elements in it. This time around they *should* be faster. Jboss AS 6 m1 is already released with m2 planned for february. Logic says it should be with us within the year, maybe faster. We'll see...

David Lee replied on Mon, 2009/12/28 - 12:30am

Java has never saved money in the past and won't in the future. Java developers cost more, development takes longer, and there are usually many more decisions to be made for Java projects than say C#/.Net projects.

And Spring is making matters worse with their layer of nonsense over JEE.  My company can't even choose a web framework out of fear of choosing wrong. And this happens while the .net guys are pumping out applications.  

 Java could save companies money, in very capable hands. But Many of the developers I've worked with seem to be framework fanatics, insisting on using library every under the sun.  Thus creating applications that are a nightmare to maintain and to hire new developers for.

Artur Karazniewicz replied on Mon, 2009/12/28 - 2:15am in response to: David Lee

@David Lee

What a bold statements, bunch of urban legends and, unfortunately, lack of evidence. I feel really sorry for Your company ;). Glad to hear that, anyway, You have found something where You are not scaried, not having to choose and You're fine with cheap developers. 

Shaw Gar replied on Mon, 2009/12/28 - 10:56am in response to: David Lee

@David Lee - Java won't save money in the future? I can understand your frustration at not being able to make a good career in Java. But, that does not give an excuse for you to insult an article author by posting garbage, and making statements without any evidence or backing up claims?

The same author has a thing or two to say about .NET as well. It's worth the read.

Shaw Gar replied on Mon, 2009/12/28 - 10:44am in response to: Artur Karazniewicz

@Artur - cheap developers? Come on.. you don't want this thread to be converted to Java vs .NET debate, do you? I guess the moderator would be on alert now!

David Lee replied on Mon, 2009/12/28 - 11:33am

I did not insult anyone.  Can you read ?  I've made an excellent career as a Java developer, and with over 10 years of using Java, hiring Java developers, managing VB, ASP, C++, .Net and Java projects I am very much in a position to make the statements I made.  What kind of proof do you want and how do you get to the point knowing anything about my career?  Java is more expensive than its counterparts particularly for web development.  That's a fact. Check dice, monster,any salary or project management survey.  Where have you been?   You need to re-read my post and simmer down.  


Otengi Miloskov replied on Mon, 2009/12/28 - 12:01pm in response to: David Lee

@David You dont have a clue bro. You are talking only BS. Just because you check monster or dice you think thats all the projects and jobs in the world, Thats not a fact, That it is stupidity.

Your comment is pathetic and better go back annd code in your lovely .Net and let us Java developers really work on the important projects.

David Lee replied on Mon, 2009/12/28 - 1:18pm in response to: Otengi Miloskov

Please explain how the changes the author noted will result in monetary savings for new or exising projects.  

The one assumption we can agree on is "time == money".


Prototyping -  Companies still have the framework debate, the last 5 I've worked for did. Maybe they don't have 2, but they do. JEE 6 will not solve this problem.

Development -  The author talks about the size of app server and deployment artifacts.  These are non issues during development.  I don't see how JEE will save more time here.  I do a lot of Groovy without Grails already for web development, so I see my changes instantly anyway.  Since I will pay for software, I use JavaRebel to avoid restarts and IntelliJ pretty much keeps me from restarting a lot any way.  Actual deployment is rare.  I dont see cost or time savings in this section.

Production -  The author offers nothing to suggest how that JEE will result in support cost savings.

Licensing - The author doesn't actually speak about licensing cost, but rather vendor lock-in.  I just don't see how anything in this bullet point will affect cost or time.

Training  - The author might be right on this one, but history and Spring will make him wrong.  I don't care for Spring because if you know the JEE APIs you have to conclude that Spring offers little that make it worth the investment.  That's my take on Spring.  But it's so popular that people will continue to adopt and train for spring and for no other reason than to just be in the know. Java's history of complexity will make it hard for the new features to be perceived as time savers.  But whether you're going JEE, Spring or something else, if you don't already know it, you'll have to train for.  

Portability -  The author really doesn't make a case for cost savings here.  Also, he doesn't make it clear how or why moving from framework X to JEE6 is going to be faster.

Adoption - Again, no tie in to cost or time savings. None.

Freedom of Choice / Investment Protection - Again, no tie in to cost or time savings. None, not one.

Risk Mitigation / Plan B - Again, no tie in to cost or time savings. Nothing.

Java development is expensive in terms of time and resources, and it will be just as expensive with JEE6.  You might not like it, but it's true.  The author simply does not make his case.  He does point out some good things about JEE, but the title and the content are at odds.  I stand by my original post.

 OtengiM, I might sound stupid but I'm right (and yes, every project in the entire world is posted on Dice and Monster. Every project.)

Artur Karazniewicz replied on Mon, 2009/12/28 - 2:40pm in response to: Shaw Gar

Sure I'm not. Please see that I even didn't mentioned .NET. From what I understood, David complained that Java developers 'cost more' so my understanding is: His company is doing fine with some cheaper developers. I'm fine with this. But it doesn't mean that's anyone's failure, especially Java, and proves actually nothing. That's my point. I'm far from heating flamewar.

Artur Karazniewicz replied on Mon, 2009/12/28 - 2:48pm in response to: David Lee

David - I'm feel sorry for this. Really. But actually it is Yours experience. Mine is exactly the opposite. But I don't generalize it. That's it.  

Wal Rus replied on Mon, 2009/12/28 - 2:56pm

Pretty much agree with David Lee, I too have plenty of experience under my belt(more then a decade) and find most of the Java OSS pure nonsense (there are rare exceptions).

Moreover, I was able to make and confirm an observation that seasoned and productive developers are very likely to share Lee's point of view, and they become productive by NOT! using any OSS. Or, if there is an OSS project they want to use they'll strip it down to the very core.
An OSS project that has excessive dependencies gets discarded right away.

java-oss-space is full of junk projects and using all of them has become somewhat of a sickness that developers get ill with. slf4j – anyone? I can't wait for a facade to slf4j, I find it needs yet another abstraction.

java-OSS-craze has killed many previously successful projects. WebLogic: for once successful, has become complete junk in version 8/9, ever since it started adopting java-oss projects excessively.

There are some java-OSS pojects that do make things better. ant, xerces, xalan, POI and so on, are excellent examples. But all them have little in terms of dependencies on other OSS projects and provide value.

Spring either tm or dm, on the other hand, is utter garbage.

It's too bad that Hani stopped his bileblog, it helped lots of people.

Henk De Boer replied on Mon, 2009/12/28 - 4:18pm in response to: David Lee


Java is not THAT bad as you like to make it sound. Nevertheless, there might be some advantages that .NET brings to the table. It's much more a single platform that's tightly controlled by a single dictator.

This means that a .NET developer basically knows .NET and uses Visual Studio and that's almost the end of it (but not quite, read below). In the Java world, you never really know what a "Java developer" brings to the table. He probably knows Servlets and JSP, but does he knows JSF or Struts? Or maybe Wicket? Or perhaps Spring MVC? Of maybe even Tapestry? And what about the enterprise layer? Does he know about EJB or is he experienced with Spring beans?

And what about the IDE? Eclipse? Netbeans? IntelliJ? And if he's used to Eclipse, would that be plain Eclipse with WTP? Or perhaps with MyEclipse? Or with Jboss tools?

The list goes on. It's just that there is A LOT of choice in Java land. This is typically seen as a Good Thing as it offers a wealth of options and a healthy breeding pond for new idea.

Yet, we must not be blind to the fact that there's another side to the coin, and that's a side of a strongly fragmented work force. In our company the Java department uses a fairly standard stack consisting of pretty much everything in Java EE (JSF, EJB, JPA, etc) with Eclipse/MyEclipse as IDE and Jboss AS on Linux as deployment platform. Our chances of hiring a new developer having experience with *precisely* this stack is basically zero. Compare this with .NET, where the chances of a developer knowing your exact stack is actually pretty high.

Another concern regarding the fragmented Java space is the IDE support. Visual Studio supports .NET and it supports it well. MyEclipse for instance must divide its resources between many Java frameworks. They recently added Struts 2.0 support. If Struts 2.0 didn't exist, they maybe could have diverted all their resources towards improving the JSP editor, which till today still doesn't even support all JSP 1.2 (from J2EE 1.4!!!) features.

Yet, the .NET building does have some cracks here and there. Microsoft made an interesting decision to make their JVM and library as much as possible language neutral, which had led to a slew of languages that can be used on the CLR. This *choice* however, has the same effect as the framework choice in Java. I heard from some friends in our .NET department that there actually IS a battle between programmers adhering to the two most dominant languages on .NET: VB and C#. Although I've never been a part of that battle, but apparently VB guys are accusing the C# guys of using needlessly complex methods, while the C# guys look down on the VB guys and telling them VB is a language for n00bs, beginners and a major origin of the most severe WTF's.

Then there's also the ASP.NET vs ASP.NET MVC debate, which can be rather fierce. The latter even introduces different view engines like NDjango, NHaml, NVelocity, etc. Then there's also NSpring, NHibernate. I really have no idea how popular this alternative stuff is in the .NET world, but it just shows that apparently there are some cracks.

Otengi Miloskov replied on Mon, 2009/12/28 - 4:39pm

David and the other guy wal_rus are just .Net trolls flaming this thread, how sad. .Net(M$) people still are the same idiots as a decade before with their junk Visual Basic.

Otengi Miloskov replied on Mon, 2009/12/28 - 5:37pm in response to: David Lee

@David, Alright David I went to Dice and I checked the job numbers right now is like this:

Java 9633 jobs
Ejb 766 jobs
Spring 1850 jobs
Hibernate 1381 jobs
Jsp 1972 jobs

C# 4600 jobs 2600 jobs 305 jobs


I think with this numbers I see the opposite of what your said, It seems all the projects are at Java and not .Net.

So your facts are just BS!.

David Lee replied on Mon, 2009/12/28 - 5:46pm

This a freakin amazin.  How many people read the author's post and its title? You guys are name calling and not dealing with any point that I or the author  made.  I stated why I don't agree with the authors assertions.

I didn't know we all had to agree.  

Can any of you name callers point out how JEE 6 is going to save us money or point out the BS or FUD in my comments ?

OtengiM - I am a Java developer.  Let's try to keep it classy and stick to the topic - JEE saving money.  






Mark Unknown replied on Mon, 2009/12/28 - 7:52pm

First, You should have stuck to the topic (i.e. Not brought up .Net).

Second, I am not sure it will save "tons" of $ but if you were one of those using EJB1/2 and not using Spring, then it should be some savings. I don't think all the points were well made (i.e. introduced some info that thwarted what he was trying to do) nor valid.

 Back to your original comments - Both .Net and Java can be more expensive or less expensive. The whole lifecycle and all factors must be taken into consideration. I think, not sure, that is the point the author is trying to make.

Otengi Miloskov replied on Mon, 2009/12/28 - 7:55pm in response to: David Lee

@David, Really this is a waste of time. It could be better if you started to discuss in a better manner but it seems your comments you just bash the author article and all the Java ecosystem.

So why continue with it?, As I said is a waste of time this discussion.

For the record, The article rocks and Java EE 6 rocks thats the important and yes it will save money because is more easy to work with and take less resources than before. Java EE 6 apps severs are following soon already there is JBoss 6 m1 and Jonas and Geronimo are on the horizon implementing EE 6 with their roadmaps just be patient and you will see that 2010 is the year for Java EE 6.

Cheers and Happy New Year!.

Mark Unknown replied on Mon, 2009/12/28 - 8:19pm in response to: Henk De Boer

@Henk NHibernate is popular enough for Microsoft and .Net Magazines to specifically talk about it when talking about their new (yet another) ORM attempt.


Microsoft has had plenty of choice in the past that has caused issues. They usually surround data access. This has been going on for years. Any remember DAO/RDO/ADO? 


Shaw Gar replied on Mon, 2009/12/28 - 8:51pm in response to: David Lee

Prototyping - Companies still have the framework debate, the last 5 I've worked for did. Maybe they don't have 2, but they do. JEE 6 will not solve this problem."

It's clear you did not try JEE yet or you did not understand what the author was trying to say. JEE6 saves time when you are required to make a quick prototype/POC - and yes, it can be done faster (saves time) compared with other Java releases such as J2EE - NOTE that the author didn't mention anything on .NET here.
Development - The author talks about the size of app server and deployment artifacts. These are non issues during development. I don't see how JEE will save more time here. I do a lot of Groovy without Grails already for web development, so I see my changes instantly anyway. Since I will pay for software, I use JavaRebel to avoid restarts and IntelliJ pretty much keeps me from restarting a lot any way. Actual deployment is rare. I dont see cost or time savings in this section.

As and when we develop we run it to see the results, that's actually deploying the application to test. Deployment doesn't mean production deployment. JEE is light and so it saves time because you don't have to wait long. What do you mean by actual deployment is rare? Obviously the author was not talking about production deployment every other second.
Production - The author offers nothing to suggest how that JEE will result in support cost savings.

Please read again! Author mentions about how you can use open source software to develop and deploy enterprise application. You pay zero for application server. That's saving money. If you want to pay for support, you can do, but still no one charges you for the application server, thats saving money. He never said you save on support costs - you can if you can!
I don't think it's worth spending time educating you. Positive criticisms are good, and I'm sure a lot of community members would have jumped in to answer you, but you are just the opposite.
Go and enjoy your .NET. Don't hurt your head with JEE, it's way too heavy for you ;-)

Shaw Gar replied on Mon, 2009/12/28 - 9:05pm in response to: Otengi Miloskov

"Net(M$) people still are the same idiots as a decade before with their junk Visual Basic."

don't generalize...I have worked with very good .NET folks. There are people there who appreciate the way things are done in Java, and some of them are behind ALT.NET initiative. Trolls are a fact of web life. Fortunately, web makes it easier to ignore trolls :-)

David Lee replied on Mon, 2009/12/28 - 9:32pm

Mark Nnn, First you tell me I should have not posted on .Net and then you go on to Brilliant. 

OtengiM, what can I say, you're just some kind of master debater/point maker.  Its clear you've never posted a job, interviewed Java developers, assessed salary demands for a potential Java new hire, or fielded proposals for projects where you can to see projected cost from X number of companies willing to do the project in every  language under the sun.  There is a reason why the Java proposals almost ALWAYS cost the most and have the longest projected development time. I knew I could MAKE YOU get on topic.  Unfortunately just because you say JEE will save money, doesn't mean it will.

shaw78 you can stretch and pull the articles words from here to the moon, but that's still not enough to back the authors claim.  And Yes, JEE is too heavy for me.  J2EE was also too heavy for Rod Johnson and now we have Spring.  Google was willing to break JEE(guess who complained...Sun) and now we have the GAE for Java.  Guillaume Laforge clearly had a preference for Java, but also clearly programmed in other languages,  thought ..."it would be nice to have language feature X in java" now we have Groovy.

Java and its ecosystem are being advanced by those that see the flaws and do something about them, not by those that think it's perfect already.

Again, the author's title is not supported by his post. 

Wal Rus replied on Mon, 2009/12/28 - 10:38pm

OtengiM, I don't feel I know you well enough to comment on your personality or tell you where you should go and or what you should do, but I'd like to point out that your attitude does not make for a mature opinion that should be taken anything seriously. And as it's been noted: "progress is made by recognizing a problem and solving it", not by protecting the status quo. That is absolutely pointless as things will always develop. I stand by my assertion that JEE6 will not save any money.

JSF has plenty of flaws to begin with, so that alone is a failure IMO. So that alone needs to be addressed in order to not waste money.

Secondly, Servlet Web Fragments: I can't even imagine the start of the problems that it will cause if developers start actively using it.

Shaw Gar replied on Tue, 2009/12/29 - 2:06am

@David, @ wal_rus: this article is focuses on JEE vs other Java implementations available. It does not compare everything under the sun with JEE. I think you miss the point completely there. Your point on maintaining the status quo is baseless. If that were so, nobody would dump J2EE and adopt spring. Sun dumped EJB 2, adopted ideas from leading open source projects and came up with EJB 3.. and now onto 3.1... Java community has a history of moving on with newer and better ideas all the time. You both make valid points, that are to be considered when people evaluate middle ware solutions for their businesses. Why don't you come up with an article comparing JEE with other popular options quoting facts, figures and quantify them? It's just all too easy to dismiss the work of another, but hard to come up with something worth reading!

adam bien replied on Tue, 2009/12/29 - 8:49am

Java EE 6 will save money - Java EE 5 did it already in my recent projects. With Java EE 5 we were able to deploy our application to different application servers at the same time. This saved us once several weeks of workarounds because we bumped into a Hibernate specific bug and were able to proceed with TopLink. We just switched the servers with literally no effort.

In other cases we were able to implement a showcase, where a critical application was able to run on opensource application servers as well. My client got better licensing conditions, just because of this fact. It was a very "good" argument for the pre-sales guys. They just underestimated the portability of Java EE.

A huge amount of money can be saved in the support as well. You need only a contract with a single vendor. There was always a fraction in the past running e.g. Spring applications on commercial J2EE servers. You needed two contracts and lots of time to coordinate two, often competing, companies. With Java EE 6 you can blame a single vendor.

Lastly development: with Java EE 6 you can start hacking an app in minutes - without the need of downloading and installing esoteric frameworks.

Wal Rus replied on Tue, 2009/12/29 - 2:01pm

Hype. Savings become real when you don't need to re-invest in learning yet another API that does not make things better (new – yes, but no better then the old one). The real problem of this industry is that the number of developers who are proficient in JEE is small, because we throw new technologies way too often at them. And, we manage to convince a good majority that if they don't know the latest API of whatever they somehow become deficient. Career span of a programmer is so small, its ridiculous. Only a few choose to stay in the field for longer then 10 years, otherwise they are fattening the management layer of organizations. Apply there a 20/80 rule and you'll have a pretty scary picture where 1 productive programmer will carry 10/20 people. That's all done by the stupid attitude this industry exhibits. The only thing that this industry deserves is the crap they get. Good and efficient things such as Delphi and so on don't stand a chance at surviving because what drives this industry (just like any other) is hype and false advertisements like the one above. So, forget it. It won't save any money, it'll be just same old thing but with a new toy.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.