Home

News: Javalobby: Why are we not using Java EE 5?

  1. Javalobby: Why are we not using Java EE 5? (40 messages)

    Javalobby has published a recent dzone article, a guest editorial by Antonio Goncalves, "Why are we not using Java EE 5?" It's a slightly confused editorial, offering lots of reasons why Java EE 5 isn't used, but yet recommending that Java EE 5 is the way to go.
    Believe it or not, in a few months the Java EE 5 specification will be two years old (Final Release on the 11 May, 2006). And nobody is using it. We have all read about how easier the development model is in Java EE 5 compared to J2EE 1.4. Complexity reduced, less XML file descriptors, less code, injection and so on. Despite all these good things, Java EE 5 projects are not taking off. Here are some reasons why : Java EE 5 is a rupture more than a continuity. J2EE 1.4 and Java EE 5 are really different. That means development teams have to be trained to something new and develop new projects leaving behind years of EJB CMP or JAX-RPC. Some teams have invested a lot in J2EE 1.4 and are willing to wait a little bit more and see. And what if Java EE 6 is another big rupture again ? Java EE 5 is based on Java SE 5 (heavy use of annotations). But JDK 1.4 is still widely use in projects, making it impossible to migrate to Java EE 5. Even if Java EE 5 is much simpler than its predecessors, it is still too complicated and has many specifications. With profiling in Java EE 6 the number of specs will be reduced, but until now, to be Java EE 5 compliant, application servers have to implement 23 specifications.
    The "profiling" mentioned for Java EE 6 is actually the Java EE 6 profiles, which specify groups of specifications required for compliance with subsets of the umbrella specification - for example, the "web profile" might imply just servlet and JSP support, while the "full profile" might add the rest of the Java EE 6 specifications. [Editor's note: the profiles are still under discussion by the Java EE 6 expert group, so the component specs of the profiles offered here should not be taken as being final in any way.] Antonio then offers a number of reasons why Java EE 5 hasn't become the one specification in the darkness to bind them: perception is one aspect, specification support is another. His conclusion, though, is that Java EE 5 is still worth adopting:
    [Some] aspects of Java EE 5 are still not at their best (testing, injection could be better, JPA still has to get richer, JSF model is a bit complex..), but the overall is that Java EE 5 is definitely much easier than its predecessor, J2EE 1.4. Projects that are using Spring might not see the benefit of Java EE 5. Except that these big projects are all using Spring within an app server (for clustering and performance issues). Upgrade your app server and start developing some EJB 3.0. You‘ll see how easy it is (and you can even combine Spring and EJB). For projects in J2EE 1.4, well, if you use Websphere, you are stuck, for the others, upgrade your app server (Weblogic 10, GlassFish 2…) and develop your new projects with Java EE 5. It is backward compatible and you can call an EJB 3 from an EJB 2.1. Do not migrate yet, just let both versions co-exist. And you, why don't you use Java EE 5 yet?
    Of course, he assumes development is able to change architectures from J2EE 1.4 or Spring to Java EE 5 without much opposition, which isn't likely to be true in most organizations; one doesn't just drop an application server, or even upgrade to a more recent revision, lightly. What's more, if you're using Spring, Java EE 5 might not offer as many upgraded features as one might expect, especially considering later versions of Spring - although users of Spring 1 may see a real benefit by now. What do you think? Are you using Java EE 5 yet? In what kind of environment? What helped you make your choice?

    Threaded Messages (40)

  2. And nobody is using it
    At this point I think somebody should give me the definition of "nobody", since I'm not understanding. The point is that I'm seeing a lot of customers of mine using Java EE 5 (even though I'm slightly in favour of Spring). Only more "bureaucratic" customers, those whose reaction times are very long, are still running old applications servers and maybe Java 1.4. BTW, people using JPA (and I see even more around) are using a part of the JEE 5 specification - and yes, they're using Entity EJBs. :-) So in the end I'd say: yes, there are a lot of people still running older versions, but JEE 5 users are well far from being "nobody".
  3. I completely agree with Mr Giudici, people ARE using Java EE 5 , it's not because you don't hear about them that they are not using it, and sometimes possibly to a large scale. For instance, i worked at Amadeus,known for their Global Distribution System for travel distribution, well they are slowly migrating their systems towards EE 5, because it provides a much more easier distributed object programming model than the previous versions. Even in my university at the Royal Institute of Technology in Stockholm, when students are to work on the enterprise side, lots of us use Netbeans with glassfish or SJSAS 9, or Eclipse + WTP 2.0.
  4. For instance, i worked at Amadeus,known for their Global Distribution System for travel distribution, well they are slowly migrating their systems towards EE 5, because it provides a much more easier distributed object programming model than the previous versions.
    Well, I don't think that such a migration would be carried out by an unkown company. I guess (bet) that some big vendor is managing such a project. Do you really think that in 2008 any big J2EE player would put this system on his success stories without using their bleeding-edge products ?


    Even in my university at the Royal Institute of Technology in Stockholm, when students are to work on the enterprise side, lots of us use Netbeans with glassfish or SJSAS 9, or Eclipse + WTP 2.0.
    Well, no offense, but this means nothing. Nobody has to put money here any student decides to move from Tomcat 3.3.1 to Glassfish. Guido
  5. Exactly. We got 4 commercial vendors - IBM, BEA, Oracle, SUN. OK, Oracle bought BEA, but real impact is not yet here. I work in ISV company and our customers always have own appservers bought from big fish tender winners - IBM, HP, Siemens. Nobody else seems to be allowed to win government contract (because contract include both HW and SW). IBM obviously brings J2EE 1.4 WebSphere 6/6.1. HP sells J2EE 1.4 OracleAS 10.1.3. Siemens usually SJAS (year ago J2EE 1.4 SJAS 8.0, now maybe finally 9 or 9.1). Nobody sells BEA because it is nearly two times expensive as IBM. Well looks like that in year 2008 we cannot use any JEE 5 server. Result is agony of EJB 2.1 or Spring. Which will you choose?
  6. Re: No JEE5 server are realy sold[ Go to top ]

    Exactly. We got 4 commercial vendors - IBM, BEA, Oracle, SUN. OK, Oracle bought BEA, but real impact is not yet here.

    I work in ISV company and our customers always have own appservers bought from big fish tender winners - IBM, HP, Siemens. Nobody else seems to be allowed to win government contract (because contract include both HW and SW).

    IBM obviously brings J2EE 1.4 WebSphere 6/6.1. HP sells J2EE 1.4 OracleAS 10.1.3. Siemens usually SJAS (year ago J2EE 1.4 SJAS 8.0, now maybe finally 9 or 9.1). Nobody sells BEA because it is nearly two times expensive as IBM.

    Well looks like that in year 2008 we cannot use any JEE 5 server. Result is agony of EJB 2.1 or Spring. Which will you choose?
    I beleive IBM is planning an app server release the middle of this year. Oracle AS is Java EE 5 certified already, albeit has a smaller customer base.
  7. Re: No JEE5 server are realy sold[ Go to top ]

    Well, don't be fooled by press announcements. Right now we have to develop on OracleAS 10.1.3.2 (ouch! ouch!) which is latest and greatest OracleAS for production. They have JEE5 compatible OC4J 11g, but it is only toy for developers and it is not sold. They will probably release production OAS in few months like IBM, but anyway everybody will wait next few month to let them patch to make it at least half usable. Funny is 10g OAS Release 3 (10.1.3) FAQ claiming that OAS is 10g J2EE 1.3 Compatible(TM) Sic! So 2008 is lost for JEE5.
  8. Re: No JEE5 server are realy sold[ Go to top ]

    I meant lost for commercial ISV development. Few day ago we had discussion with other coworker and he said interesting idea. FYA politics which states for F**k Your Appserver (We were little drunk) It means to let customer look like idiot for buying such overpriced and obsolete crap, and deliver our application on appserver we choose (of course free appserver we know much much better). But usually we doesn't have such strong position.
  9. Re: No JEE5 server are realy sold[ Go to top ]

    To my knowledge, Websphere 6.1 is JEE 5 compatible. Perhaps you say that because WSAD is not compatible with Java 5 ?
  10. To my knowledge, Websphere 6.1 is JEE 5 compatible. Perhaps you say that because WSAD is not compatible with Java 5 ?
    WebSphere App Server 6.1 is J2SE 1.5 compatible and J2EE 1.4 compatible. However, there are a number of free downloadable feature packs for WAS 6.1 that provide support for significant subsets of Java EE 5 function: the webservices feature pack (supporting JAX-WS, JAXB and other webservices-related specs) and the EJB 3.0 feature pack (supporting EJB 3.0 and JPA). These are not betas or previews; they are supported for production use. Randy (IBM/WAS)

  11. WebSphere App Server 6.1 is J2SE 1.5 compatible and J2EE 1.4 compatible. However, there are a number of free downloadable feature packs for WAS 6.1 that provide support for significant subsets of Java EE 5 function: the webservices feature pack (supporting JAX-WS, JAXB and other webservices-related specs) and the EJB 3.0 feature pack (supporting EJB 3.0 and JPA). These are not betas or previews; they are supported for production use.

    Randy (IBM/WAS)
    But not certified, right?

  12. WebSphere App Server 6.1 is J2SE 1.5 compatible and J2EE 1.4 compatible. However, there are a number of free downloadable feature packs for WAS 6.1 that provide support for significant subsets of Java EE 5 function: the webservices feature pack (supporting JAX-WS, JAXB and other webservices-related specs) and the EJB 3.0 feature pack (supporting EJB 3.0 and JPA). These are not betas or previews; they are supported for production use.

    Randy (IBM/WAS)

    But not certified, right?
    They are certified and pass the CTS for the applicable specs they support.
  13. Anticipating change[ Go to top ]

    One of the main reasons we at TomTom don't use JEE5 is because we are using Spring, so frankly, we don't care about it all that much. So, this is one of the reasons why I haven't felt the urge to move on to a new version of a JEE5 application server yet. Another - and maybe even more important - reason is that I believe the model for enterprise computing will change. Spring and Hibernate had a huge effect on the direction of the standards. It did not solve all problems of JEE though. Even with Spring, you are still bound to the limitations of JEE's module system. The granularity of the module system just isn't right, dependency management between units of deployment stinks, deployment and configuration management is a pain, and the classloading hell is always round the corner. It's just getting in the way of creating great systems quickly. I suspect Spring will tear down those walls as well. That is, I hope it will. With Spring's adoption of OSGi, adding support for OSGi deployments has become an interesting opportunity for application server vendors. Since they changing their module systems under the covers anyway, adding support for an OSGi runtime should not be all that hard to do. Now from my perspective, that would be a dream come true. So that's why I sit and wait for a while. Hopefully something will arrive soon. The fact that GigaSpaces is moving towards OSGi is a good sign.
  14. The Fact remains that People wants to get rid of the Application Server.LightWeightFramework provides the Alternative. Conclusion:JCP Members wont allow LightWeightFramework to become popular as their members should close their businesses(IBM,Oracle,Sun,Bea,JBoss)? Bea Entrepreneurs should look at this opportunity and could come with the LightWeightFramework from an open fresh mind. They could think of a plugin which works on top of Openservers(Tomcat). May be this could be the competitor to the existing spring and Hibernate??
  15. We use Java EE 5[ Go to top ]

    We are not in the "nobody" list and we do use Java EE 5 for some of our projects. We use Glassfish v2 as the application server. But i admit that initially we hesitated to use Java EE 5 because of the lack of app server support other than Glassfish. But Glassfish is such a fun to use and we now i feel, we made a correct decision in choosing it. Nevertheless, Java EE 5 adoption will be slow unless the biggies (Websphere, Weblogic) provide full-fledged support.
  16. It depends whom you are asking. The author might have spoken to some IBM customers. Our EJB 3/ JPA book EJB 3 In Action is selling very well. Why would they buy book if they do not or plan to use the technology? This book is also being translated to Chinese and Portuguese. Many of our customers are using Java EE 5 technologies (e.g. EJB 3 and JPA )in their applications. regards Debu Panda Blog
  17. I saw the article in my email yesterday and I was wondering if I was included in the definition of "nobody" My guess is that people won't be running to upgrade old applications to JEE, but new projects can certainly be done unless you tie yourself to Websphere
  18. Firstly, It takes 1-2 years to bake a JSR spec, then 1-2 years for the vendors to update their products, then 1-2 years for the Big customers to start using the stuff. As of today, we are just reaching the point where adaptation is starting and it's bit too early to tell whether Java EE 5 was success or not. I'v certainly seen a lot of interest towards Java EE 5 among big clients and unlike wicket, grails etc people try to tell you, JEE 5 not being ignored, but it's not that widely used either. Secondly, i'v seen fair amount of Resistance against Java EE 5 and EJB 3.0 -- there were lot of people and projects that got burned by earlier version and this is causing flashbacks. Thirdly, from technical point of view Java EE 5 falls short in several important areas, for example the dependency injection is half baked, JPA is lacking criteria query API, and the spec requires big app servers that satisfy more needs than the users have, and thus come with the associated complexity. /Henri Karapuu
  19. Firstly, It takes 1-2 years to bake a JSR spec, then 1-2 years for the vendors to update their products, then 1-2 years for the Big customers to start using the stuff.

    As of today, we are just reaching the point where adaptation is starting and it's bit too early to tell whether Java EE 5 was success or not.

    I'v certainly seen a lot of interest towards Java EE 5 among big clients and unlike wicket, grails etc people try to tell you, JEE 5 not being ignored, but it's not that widely used either.
    J2EE5 adoption will happen sooner or later. Indeed independently from the eventual benefits it carries. Just because old products go in end-of-life and you have no support anymore. Guidi
  20. Thirdly, from technical point of view Java EE 5 falls short in several important areas, for example the dependency injection is half baked, JPA is lacking criteria query API, and the spec requires big app servers that satisfy more needs than the users have, and thus come with the associated complexity.
    As a side note, these are all concerns that are being actively addressed under the Java EE 6 umbrella.
  21. As a side note, these are all concerns that are being actively addressed under the Java EE 6 umbrella.
    Yep, i know. But much water will flow under the bridge before Java EE 6 will be used in production in the big companies. I think it'll be around 2011. In the mean time, the developers who got burned by ejb 2 and migrated to spring don't have any pressing reasons for architectural change. Spring works fine for now, there are no significant advantages in moving back to EJB camp. /Henri Karapuu
  22. We migrated to Java EE 5 in 2007. Our apps run in production on Sun Java App Server 9.1 (GlassFish V2), use EJB 3.0, JSF and JPA. I was quite happy with JPA although I think it is missing unidirectional one to one (must be bi-directional), criteria API, and standardized cache hints. These are being taken care of in JPA 2.0. All of the missing things in EJB 3.0 are being taken care of in EJB 3.1. JSF is getting a major overhaul in 2.0 and we are looking forward to all of the proposed changes. The next version of GlassFish (v3) will be light weight like Tomcat loading only what is needed for deployed apps. It will also support advanced deployment options such as running multiple versions of the same app at once, and rolling back to an older version. We are really looking forward to Java EE 6 and GlassFish v3.
  23. And nobody is using it.
    I think Antonio was just using a little bit of an overstatement for dramatic effect. Of course there are a lot of people interestred in Java EE 5, but the point is that adoption is slow. Maybe adoption rates of J2EE might shed some light here? Is Java EE adotion rates below par in comparison? In any case, I do agree with the fact that a lot needs to be done in order for greater adooption of Java EE and that the market dynamic has changed (mostly for the better). Reza


  24. I think Antonio was just using a little bit of an overstatement for dramatic effect. Of course there are a lot of people interestred in Java EE 5, but the point is that adoption is slow.
    I agree. I think this is the simple and right definition of "nobody", but only in this discussion! IMHO J2EE 5 specs falls in some points like JPA and IoC, and of course many people do not use it. Anyway: - Many people still use J2EE 4 and don't want (or can not) pass to J2EE 5, so do not use it; - Many people use Spring, and think that J2EE is usefulness and not flexible enough, so do not use it. Finally, who use J2EE 5 ?
  25. J2EE missing something..[ Go to top ]

    Back in the db ages we had this notion of schemas or namespace or tablespaces in oracle or even database itself in mysql..! But the main thing is that they still reside in the same logical server. So we could sometimes divide departments/divisions concerns using this different tablespace, this way the same application type could still be used but only targeting different tablespace. So sometimes i wished that j2ee would have the same notion of tablespace or 'application space'. so using the same ear we could create different instances of those ear using this notion of 'application space' rather than the current one ear one instance of app service. just a wishful thinking.. :) regards, johan
  26. Why I can't use JEE 5[ Go to top ]

    I currently can't use JEE 5 because we are a Websphere shop. We are stuck at 1.4. :-(
  27. Re: Why I can't use JEE 5[ Go to top ]

    I currently can't use JEE 5 because we are a Websphere shop. We are stuck at 1.4. :-(
    If you haven't already, you may want to consider the WebSphere App Server 6.1 feature packs for webservices and EJB 3.0. They provide support for two of the most-popular sub-specs from Java EE 5. Each has been certified for spec compatibility using the Sun CTS test suite, and they are supported for production use. Randy (IBM WAS)
  28. Because Spring is better for me[ Go to top ]

    I don't use JEE, and I'm really curious as to why anyone does, because: 1) For all intents and purposes Spring is a superset of JEE functionality. Anything I get with JEE, I get with Spring, but Spring provides more (EIS framework integration, remoting choices, Groovy/JRuby support, etc, etc, etc). Why limit myself? 2) Similarly, Hibernate is a superset of functionality of JPA. Why choose JPA and limit myself? 3) Being an independently maintained framework, with the interest of supporting its users by solving real integration problems, Spring moves much faster than any JSR. Need ActiveMQ or Mule integration? Spring does that now in ways that real people regularly use in production. A spec may never support common ways of integration. It moves very slow in comparison. Specs are useless. What is useful is free open-source frameworks that adjusts quickly to the needs of real-world developers and solve common problems that we all see. Things that prevent re-inventing the wheel and do it in a flexible and configurable manner.
  29. Re: Because Spring is better for me[ Go to top ]

    For all intents and purposes Spring is a superset of JEE functionality.
    First of all, this isn't necessarily true. There are genuine innovations in Java EE 5 that Spring has not yet completely caught up to. And these aren't just tangential features that are bells and whistles, but fundamental usage pattern improvements. I would ask you to carefully consider the amount of code to write a Java EE vs. Spring application, particularly paying attention to metadata (I believe Adam Bien did this already as a test). Being informed is in your best interest anyway, so why limit your options by making sweeping generalizations?
    Being an independently maintained framework, with the interest of supporting its users by solving real integration problems, Spring moves much faster than any JSR
    That's not necessarily true. Besides what I mentioned above, there are many instances were the standard based solutions often overtake any given non-standard solution. The reason? The nature of the standard means that it can act as a pool of "best ideas" from a variety of sources rather being tied to the ups and downs of any particular small group of people. The alleged "slowness" of the standard is often not borne out as reality. Also, some folks use the standard as a measure of guarantee that they will eventually benefit from the best innovations from a number of sources instead of being likely to be painted into a corner. Again, why limit your options by making sweeping generalizations?
  30. There are genuine innovations in Java EE 5 that Spring has not yet completely caught up to. And these aren't just tangential features that are bells and whistles, but fundamental usage pattern improvements.
    Care to elaborate on what exactly Spring 2.5 has not "caught up to"? Both in its own component model and in its integration with Java EE 5 facilities? Are you aware how far Spring 2.5 goes beyond EJB 3 in terms of annotation-driven configuration options? That Spring 2.5 brings all those options to Java-5-based J2EE 1.4 servers as well, in a completely portable fashion? Are you aware that ongoing Spring improvements will be immediately available for use on existing Java EE 5 servers, whereas spec improvements like EJB 3.1 will require a major server upgrade (once those are out in the first place)? BTW, why raise that same vague point in two threads in parallel? http://www.theserverside.com/news/thread.tss?thread_id=48198#246574
    The alleged "slowness" of the standard is often not borne out as reality.
    Well, not in terms of the specs being released maybe... However, that problem is out of the question in terms of those specs becoming available in the mainstream market. How many Java EE 5 servers do you count today, nearly two years after the spec went final? And how much marketshare do they have? The problem with enhancements in standard Java EE specs is that they're out of reach for users of existing platform versions. And it's not exactly a secret that J2EE servers are often treated like a piece of system software analogous to a database - i.e. upgraded very conservatively, more based on operations concerns than with API upgrades in mind. That's why e.g. WebSphere 5.1/6.0 and WebLogic 8.1/9.2 are still very common. Juergen
  31. Care to elaborate on what exactly Spring 2.5 has not "caught up to"?
    I apologize that I really don't have the personal bandwidth to answer this in detail right now or try to do justice to the resulting inevitable torrent of responses (both positive and negative). However, I am updating my Spring 2.0/EJB 3.0 comparative analysis soon so I'll have a rather comprehensive answer to this question shortly. As I've promised you SpringSource guys, I'll send it to you for review and comments as soon as I can - give you guys a head-start on Spring 3.0 :-). Maybe someone else can shed some light here in the meanwhile. Again, I apologize profusely that this is really all the time I have right now. The post on EJB 3.1 really sucked up a lot of my time than I was anticipating... Reza
  32. Re: Because Spring is better for me[ Go to top ]

    Care to elaborate on what exactly Spring 2.5 has not "caught up to"?
    I apologize that I really don't have the personal bandwidth to answer this in detail right now or try to do justice to the resulting inevitable torrent of responses (both positive and negative). However, I am updating my Spring 2.0/EJB 3.0 comparative analysis soon so I'll have a rather comprehensive answer to this question shortly. As I've promised you SpringSource guys, I'll send it to you for review and comments as soon as I can - give you guys a head-start on Spring 3.0 :-).
    I'm sorry Reza, but this is a really weak response. When you referred to "genuine innovations in Java EE 5 that Spring has not yet completely caught up to...not just tangential features that are bells and whistles, but fundamental usage pattern improvements" it seems strange that suddenly don't have time to discuss them. Surely they're so substantial that you can enumerate them without working up a whole presentation? As for "I would ask you to carefully consider the amount of code to write a Java EE vs. Spring application, particularly paying attention to metadata," it's been repeatedly pointed out to you that in Spring 2.5 previous comparisons are obsolete. Furthermore, the EJB 3.0 XML format is extremely verbose, so when you get to the cases where annotations alone are not sufficient--or, for example, where you need to use interception without annotating all your classes with @Interceptors--the amount of configuration in EJB 3.0 increases rapidly. I respect your dedication to EJB and desire to make it better. But frankly, if you are going to compare with other technologies you owe it to your audience to have up-to-date knowledge of those technologies. To conclude I totally agree with the final point that you make:
    Being informed is in your best interest anyway, so why limit your options by making sweeping generalizations?
    I'm afraid that making sweeping generalizations (and failing to back them up) is exactly what you're doing. Rgds Rod
  33. Re: Because Spring is better for me[ Go to top ]

    There are genuine innovations in Java EE 5 that Spring has not yet completely caught up to. And these aren't just tangential features that are bells and whistles, but fundamental usage pattern improvements.
    For example? I'd genuinely like to know - my interest is not Spring vs JEE vs anything else, but the most complete and flexible mechanism for Java enterprise developers. My opinion is that Spring provides that today better than anything else, but if you could clarify otherwise, I'd be very happy to investigate further.
    I would ask you to carefully consider the amount of code to write a Java EE vs. Spring application, particularly paying attention to metadata (I believe Adam Bien did this already as a test). Being informed is in your best interest anyway, so why limit your options by making sweeping generalizations?
    I'd like to think I'm well informed since I'm heavily involved in open source communities and make it regular practice to continually evaluate frameworks and make sample applications to test different approaches. In that sense, I feel that my comments were not a sweeping generalization, but rooted in actual practice. With Spring annotations and autowiring (closer to how JEE does things), a Spring application can have extremely little configuration and code is not complex. Add in optional things like a Groovy Spring Builder, and it drops configuration further than XML _and_ provides IDE support (flexibility, choice). Given these multiple configuration options, some of which reduce code as much as JEE, I don't see your argument about reduced code holding much weight since a Spring app can have very little configuration as well.
    Besides what I mentioned above, there are many instances were the standard based solutions often overtake any given non-standard solution.
    For example? You haven't listed one, giving a "sweeping generalization" without concrete representation. :)
    The nature of the standard means that it can act as a pool of "best ideas" from a variety of sources rather being tied to the ups and downs of any particular small group of people. The alleged "slowness" of the standard is often not borne out as reality.
    One does not have to look any further than the JCR specification as an example of Spec "slowness". And, for "pool of 'best ideas'", at least in Spring's case, the driving force is not a "particular small group of people". Because of Spring's adoption and its very large user community who regularly contribute and actively voice their needs, I would argue that the "best ideas" come from a pool _much_ larger than any JSR spec committee. In my experience at least, if you need a feature in Spring, and you have a valid case that it can serve the needs of many, odds are very high that it will be incorporated to the framework. And probably far faster than a Spec committee composed of multiple companies can agree on incorporation.
    Also, some folks use the standard as a measure of guarantee that they will eventually benefit from the best innovations from a number of sources instead of being likely to be painted into a corner.
    That is true if the corresponding competing frameworks potentially blocked you into a corner. Spring at least in no way suffers from this - Spring integrates with frameworks and provides implementations of things that aren't even addressed in JEE. Spring remoting is just one of many examples. Now all this being said, I _do_ think competition and new ideas, wherever their origin, are good for the community. It drives innovation, which helps everyone. It is just my personal opinion that Spring provides the most complete and flexible enterprise development solution available today versus any other alternatives. Finally, I do genuinely wish you the best on your endeavors and work with the JEE spec. Maybe one day there will be a clear case to cause my opinions will change. I'll look forward to it :) Best regards, Les (not affiliated with SpringSource or any Spec committee :) )
  34. Re: Because Spring is better for me[ Go to top ]

    Specs are useless.
    I currently have the same sentiments as you do - I know Spring and Hibernate very well, so why would I choose to learn something else that I am not convinced will offer me more? But many specs are very valuable. The current Spring-based app I'm working on is using JMS, JTA, and servlets (as well as JNDI to look up some EJB2's that unfortunately can't be changed yet). What's interesting to me is that specs that address "plumbing" (e.g. JMS for messaging, JDBC for db access, JTA for transactions, servlets for processing HTTP requests) are almost universally used, but specs that build on these specs and attempt to provide a higher level of abstraction as programming frameworks - such as EJB and JSF - face a lot more competition, and naturally aren't used as much. JEE provides both kinds of specs, and thus it should be expected that many shops won't choose to use all of the specs when some don't compete as well with other choices. And has been mentioned on other threads - the competition is essential, as it makes the specs better.
  35. Re: Because Spring is better for me[ Go to top ]

    +, let application servers do the plumbing and let frameworks (such as Spring) to the frameworking.
  36. Re: Because Spring is better for me[ Go to top ]

    People are not using JEE 5 because the god-architects in corporates that usually make these decisions realize that they would have nowhere to hide their incompetence. You see, for years the world of J2EE has been a refuge for pompous know-it-alls to hide between a multitude of totally unnecessary layers. With "layering" not much of a requirement for JEE 5 development anymore, these poor sods would only have one thing left to do - to solve the business problem at hand using good old fashioned OO. And of course they can't. Whatever their excuses and hand waving, it is becoming blatantly clear that most of the supporters of the status quo simply do not understand OO. Oh yes, and the Spring guys will never use JEE5 because it is simply WAY too conformist. Long live JEE 5!
  37. Re: Because Spring is better for me[ Go to top ]

    Oh yes, and the Spring guys will never use JEE5 because it is simply WAY too conformist.

    Long live JEE 5!
    Do you realize that Spring 2.5 has great support for Java EE 5? In other words, that a Java EE 5 server (such as GlassFish) is a great runtime platform for Spring-based applications and that Spring 2.5 has very explicit support for that platform generation? So we do "use" Java EE 5 as far as it is relevant as a deployment platform and as a service provider (e.g. for JTA 1.1, JPA 1.0, JSF 1.2, JAX-WS 2.0)... We just prefer to keep our focus on the very successful Spring component and configuration model itself, even when running on a Java EE 5 server - in integration with core Java EE technologies such as JPA and JSF. I don't see anything bad about that; it's arguably the best of both worlds. Long live Spring on Java EE 5! :-) Juergen
  38. Re: Because Spring is better for me[ Go to top ]

    Right, why use one platform (with a proper specification), when you can use a tie-it-all-together configuration-service-gone-wild AND a hundred different libraries that - put together - do more or less exactly what JEE does. The fight against entropy is indeed futile.
  39. If IBM, JBoss, Oracle, BEA had them out earlier we would have bough them. This is one of the reasons why Glassfish (Sub App Server is serging now) To be fair, these companies have built many systems ontop of J2EE 1.4 and would mean a big change for something like IBM, to re-write/certify hundreds of products (From workflow, to Financial, to POS Systems, and Medical research to name a few) with the new major version of an App Server. And than convince their customers to upgrade to the new version? Yeah, I know the discussions from Spring to JEE. These technologies are not exclusive, they complement each other, especially in the terms of JEE 5. Yes you can build a complete application on Tomcat and Spring, but as an Enterprise Architect would I choose this for my mission critical 20 clusters Fail-over environment with Voice XML, Phone WebServers System which uses a custom load balancer business integration engine which interacts with Oracle Financials, Seible, with 6 clustered databases, reporting SNMP Event data to a NOC, an on-line Payment system, and serve as a Business Process Server for my business logic and rules server to be displayed in a customer specific Portal View for my customers? There is a place for all technologies. Spring is great where it fits, and the best when it comes to modularity. It allows me to use what I want to use. Dependency Inject, and AOP and replace the web front end with a SIP interface of Phone Web Server for VXML. It's speed and flexibility to solve difficult problems quickly is it's greatest benefit. So we need both! In some cases JEE 5 by itself, in more cases Spring with Tomcat/Spring with JEE. With true enterprise application J2EE Server/Services are needed. If your application collects information from the web and writes it to a table, I am not sure why you would pick JEE as a solution, except for familiarity. For all else we have choices.
  40. I disagree from the author of the article, don't know the depth of his market knowledge... Here we are using JEE5 in several big (BIG...) projects, a couple of them, imagine, to the most bureaucratic and slow adopter kind of market, the State departments. Using basically all technologies from the JEE stack.
  41. Greenfield projects only[ Go to top ]

    I think that it is only viable to use JEE5 in Greenfield projects. If you don't use it there (when going the JEE/J2EE way) you deserve to be fired. For all other projects the decision is not that easy. Most large projects/deployment are (sad enough) not really modularized. So when developing for these you cannot just get rid of the old stuff. You will very often handle two versions of J(2)EE at once which tends to destroy all your benefits. There is no real easy and low impact way to introduce JEE, unlike say introduction of hibernate or spring which can be used in a sub project (and increase the overall system entropy in a bad case but create a more modularized application landscape in a good case). It usually takes years to make an execution environment (SSO, Web Server, J2EE, JEE, Tomcat&Spring&hibernate etc.) really manageable, so infrastructure teams will show resistance to migration of a runtime environment. And the list goes on. On the other hand: If I would be on a greenfield project and have decided to go J(2)EE today I would try my very best to be able to/allowed to use JEE5, because it limits the number of the myriad number of 3rd party libraries and tools that I would need instead. I could do without hibernate, without extra "micro containers", without extra AOP tools, precompilers, myriad of helper classes and so on.