Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Java EE 5 Development Waiting on Vendors 99

twofish writes "Java EE 5 was a major update and most of the major application server vendors do not yet have compliant versions released. Dr. Dobb's reports that this is delaying most solution providers from developing products based on it, as their customers are not ready for them. However there is some significant movement among the big players. Among the major vendors, Sun has released support, WebLogic is close with JBoss following soon after. Oracle has not announced a road map and IBM is lagging significantly behind, with full support not due until 2008."
This discussion has been archived. No new comments can be posted.

Java EE 5 Development Waiting on Vendors

Comments Filter:
  • by MythMoth ( 73648 ) on Saturday October 21, 2006 @10:41AM (#16528113) Homepage
    Companies in the market for significant numbers of Java EE application servers and their attendant support contracts are rarely in a hurry to adopt the newest and latest technologies. Companies I work with usually lag at least a major revision - sometimes two - behind the bleeding edge.
  • SAP (Score:5, Informative)

    by ut.linuxer ( 1016433 ) on Saturday October 21, 2006 @10:48AM (#16528143)
    SAP released a Java EE 5 compatible application server a few weeks ago.
  • by Jason Hood ( 721277 ) on Saturday October 21, 2006 @10:57AM (#16528193)
    Why switch? If you need a feature from 1.5 or 1.6 then upgrade. Many server side applications of Java have absolutely no reason to upgrade. Most companies will be using 1.4 for many years.

    There are significant upgrades on the rich client side for 1.5 and 1.6 especially in the Look and Feel area. My 1.6 apps in GTK look just like a native app, thus I use 1.6 for on the client side. I still however use 1.4 on the server side since there are no performance benefits for my applications. Nice thing about java is everything is byte code compatible downstream. I am sure there are providers out there who still use 1.3 on the server side.
    • by Anonymous Coward on Saturday October 21, 2006 @11:06AM (#16528239)
      Well, the main reason to switch to 1.6 is that earlier versions won't run under Vista [betanews.com]. (Of course, that assumes you're running Vista in the first place...)

      As for Java 1.5, the main reason to switch to it is for generics which are very useful server-side. Of course, there's no technical reason that generics couldn't be backported to 1.4, but Sun refuses to allow code with generics to generate Java 1.4-compatible bytecode, so if you want generics, you're stuck with 1.5. (Despite the fact that generics are implemented via what's effectively a compiler preprocessor.)

      But other than supporting Vista, I know of no reason to upgrade to 1.6. As far as I can tell, it offers nothing that anyone would want. (The only major upgrade is the addition of various scripting libraries, in yet another Sun library-bloat move. There's no reason Java should require 500MB, but that's the size of my Java directory.)
      • Re: (Score:2, Informative)

        by Anonymous Coward
        Well, the main reason to switch to 1.6 is that earlier versions won't run under Vista.
        FUD alert.

        Java on Vista: Yes, it Works [java.net].
        Don't base your assumpsions on half-year old articles on beta software.
        • Re: (Score:3, Informative)

          by gutnor ( 872759 )
          From the article:

          "Java SE 6 is the Best Solution for Vista"
          "J2SE 1.5 Will Also Work
          Many of the Vista fixes have already been, or will soon be, back-ported to J2SE 1.5. However, don't look for everything to work exactly the same; our primary focus was to make Java SE 6 the main release vehicle for Vista."
          "J2SE 1.4.2 Will Basically Work..."

          That means that if you want to have your Java application working smoothly on Vista, you beter have something that support Java1.6. You can still use 1.5 or even
      • by nuzak ( 959558 ) on Saturday October 21, 2006 @01:55PM (#16529433) Journal
        1.5 added more than just generics, and the bytecode format really is not compatible, so there really isn't much they can do about it.
            Use retroweaver to get 1.5 features and annotations in 1.4 code -- http://retroweaver.sourceforge.net/ [sourceforge.net]

        > There's no reason Java should require 500MB, but that's the size of my Java directory

        You have something pretty funny going on there. My jdk1.6 install is 178 megs. I didn't download the separate docs tho, which do add loads and loads of space. Most of the JDK comes with source anyway, and eclipse pulls javadoc right out of source, so I saw little need for it.

        Not that 178 megs is small, but I think as long as the full JDK weighs in under 200 megs, it's doing all right.

        Now glassfish (the JEE5 reference platform) is monstrous, but it was intended to be the kitchen sink from the start.
    • by the eric conspiracy ( 20178 ) on Saturday October 21, 2006 @11:08AM (#16528259)
      Java 5/6 (not J2EE 5) has some very important enhancements to its concurrency support. Under the right circumstances and if you know what you are doing they can accelerate your application by 50% or more. There are also some nice debugging tool improvements that especially improve profiler performance over Java 1.4.

    • by Anonymous Coward on Saturday October 21, 2006 @11:08AM (#16528261)
      This article is about Java EE 5, not the JDK. While it is true that Java EE 5 will require JDK 5, they are not the same thing. J2EE 5 brings significant developer productivity enhancements many stemming from the use of annotations. Alot of this comes from the EJB3 spec, which makes J2EE persistence actually usable vs the old spec (don't take this as a flame, I'm currently waking up from the nightmare that has been my last 3 years of EJB 2 development.) I think that J2EE 5 will be a good step for organizations that can't yet embrace the lightweight develoment model that spring (and others) provides for whatever reason.
    • by frodo from middle ea ( 602941 ) on Saturday October 21, 2006 @11:13AM (#16528301) Homepage
      Umm, Java 5 or rather JDK 5, is different than Java EE 5.

      As for JDK 5, there are plenty of reasons to use JDK 5, over 1.4, even on a J2EE 1.4 App.

      TO name a few...

      • Generics, type safety at compilation time
      • Enhanced for loops, bye bye, iterator.hasNext()
      • Auto Boxing of primitives... bye bye List.insert(new Integer(5)
      • Proper enumeration suport.. bye bye scores of static final variables
      As for using Java EE 5, there are even more reasons to use it, once ejb 3 specs are stabilized.


      • Java Persistence API is so so much better than J2EE 1.4 entity beans.
      • JSF is so so much better than struts.
      • Stateful session beans make much more sense now. see jboss-seam

      Last but not least, Annotations , bye bye xdoclets, ejb descriptors, . Seriously Annotations, alone, make a very strong case, for adopting Java 5, and Java EE 5.

      • Have they made it "Write once, run anywhere" though? Can the same .EAR be dropped into any environment and expected to run?
        • Re: (Score:3, Informative)

          by heinousjay ( 683506 )
          There are still things the programmer has to do to ensure that works, but as long as cross-platform rules are followed and environmental configuration is handled sanely, that's been possible since the beginning. It's not often Java's fault that an application won't work on multiple platforms.
      • Re: (Score:1, Interesting)

        by Anonymous Coward
        Too many developers that I've talked to are still leary of EJBs from their past experiences. Architects are spooging over the damn things but developers live in the real world. EJB 3 really needs to be able to show significant benefits without being a complete PITA like the last version.

        JSF is still a wreck. I guess it has its place, but our architects were all gung-ho for it and some of our programmers swore it would be the best thing for our company. After 6 months of using it they found out that it took
        • Re: (Score:3, Interesting)

          by Doctor Memory ( 6336 )

          Too many developers that I've talked to are still leary of EJBs

          Yep, me too. But once they've had a chance play with JEE 5, they'll find it's not so bad. Annotations have pretty much solved the deployment descriptor nightmare (I'll put an ejb-jar.xml file up against a Sendmail config file any day!), so now it's mostly just a matter of writing the beans themselves, not first writing them then trying to hook them up.

          Annotations are HAWT!!!

          Fo shizzle! When I wrote my first web service, it was your typical J

      • by Type-E ( 545257 )
        I talked to a developer who uses JSF over Struts for a new project. The more he uses JSF, the more he hate it and would like to switch back to struts. I wouldn't say JSF is any better than struts but it's nice that there is a standard within J2EE
  • by gabrieltss ( 64078 ) on Saturday October 21, 2006 @11:18AM (#16528337)
    I built a EJB3 set of services along with working with another group who built JSF/Seam pages (interface) and using EJB3 stateful session beans and we deployed it all on JBoss using JDK1.5.0_06. In fact we used the J2EE 1.5 - granted we had to "spoof" Eclipse/MyEclipse into using the J2EE 1.5 jars and capabilities. But JBoss worked just fine with it all. This was a company internal application but it worked just fine. We used JBoss 4.0.4 GA Patch 1. I love the JDK/J2EE 1.5 stuff. Wish my current company would move from 1.4.2 to the 1.5.
  • by MarkWatson ( 189759 ) on Saturday October 21, 2006 @11:31AM (#16528399) Homepage
    I used to be very much into J2EE (even wrote a book on it), and it is great to see the platform evolve as the Java language evolves.

    That said, I have "moved down the food chain", starting to favor just running Tomcat+custom tag libs+JSPs+persitence. I used to mostly use Hibernate, then simplified to using Prevaler. In the last year or two, I have favored Rails for small quick web apps.

    J2EE is great for large scale projects, but for most web apps and portals there are easier to use solutions. I have even gone back to using Common Lisp for web apps and web services in the last year (that is "moving back up the food chain" :-)
    • Re: (Score:3, Interesting)

      by David Off ( 101038 )
      I actually have your book Intelligent Java Applications
    • by bigbird ( 40392 )
      I used to be very much into J2EE (even wrote a book on it), and it is great to see the platform evolve as the Java language evolves.

      That said, I have "moved down the food chain"

      Yes, I too used to be a J2EE tech-head. But I've got bored with keeping up with loads of APIs constantly evolving, and eventually realised most of it wasn't necessary for 90% of web apps.

    • I have even gone back to using Common Lisp for web apps and web services in the last year

      I looked at using Lisp for some web based things a while back. I found a FastCGI implementation, but the only documentation it came with said 'read the code.' Can you recommend anything a bit higher-level (if I have to implement a web framework myself, that eliminates a lot of the advantage of going with Lisp.

      Have you tried Seaside? It's a Smalltalk web app environment which is pretty much exactly what I want fro

  • My old team at Sun used to port everything from soup to nuts to Solaris, Linux and later versions of middleware, so that sounds like an opportunity for some fixed-price ports (;-))


  • by kimanaw ( 795600 ) on Saturday October 21, 2006 @12:36PM (#16528831)
    I'm sure the /. ubergeeks will reel off a dozen reasons to upgrade to EE 5, but my customers are still beating up their vendors for forcing them to move to JDK 1.4, and practically begging me to continue supporting JDK 1.3/J2EE 1.3. Making such upgrades costs money, and unless the end user's core business (which usually is not about building out app servers) sees a real ROI in upgrading, its not likely to happen...unless/until vendors force them kicking and screaming to upgrade.

    I.e., if it ain't broke, don't fix it.

    • by drewmca ( 611245 )
      There are MAJOR performance improvements in 1.4/5.0 JVMs versus 1.3. That's a major reason for upgrading, besides the language improvements. I can understand a client not being too keen on developer improvements (although that short-sightedness could cost them in actual development costs), but performance improvements essentially for free are a pretty good reason for upgrading no matter who you are.
      • by kimanaw ( 795600 )

        ...but performance improvements essentially for free...

        I see. I was unaware that my IBM/Sun/Oracle/BEA/etc. site engineer was going to just waltz into my office, do a quick copy of all those J2EE 1.4 JAR/XML/WAR/etc. files over to a shiny new EE 5 system, flip the switch and it will all magically work wo/ any service interruption. And of course, there will be no bill. Just like when they forced us to upgrade from 1.3 to 1.4...er, um, wait a sec...

        I'm guessing you've never had to budget for such an up

        • by drewmca ( 611245 )
          No need to be a smart-ass. I'm referring to the speed improvements in the JDK alone, nothing to with J2EE. If you're using an app server that's still running on the 1.3 JDK, I'd say you've got pending trouble on your hands. And I am not seeing any major J2EE users try to identify app servers they can replace with LAMP stacks. At all.
    • by jilles ( 20976 )
      Upgrading the jvm does not cost that much. It's a free download and the upgrade is backwards compatible. On top of that 1.3 is now pretty much unsupported stuff and the 1.4.2 version performs a little better and has lots of nice improvements related to scalability. I'd recommend to go straight to the latest 1.5.0 runtime unless you have some very specific technical reason not to do so. And even then you should consider fixing it rather than not moving to 1.5. You can of course choose not to use the new lang
  • by iabervon ( 1971 ) on Saturday October 21, 2006 @02:30PM (#16529769) Homepage Journal
    I remember when Weblogic got support for EJB 2.0 (I think; it was a while ago now). They were much more prompt about that. They had it implemented and in production use before the standard was even done getting major changes. When we switched (for cost reasons) to JBoss, almost all of the porting effort was in porting from the intermediate version of the standard that Weblogic had implemented to the actual released version.
  • Would you ask it to bring me a beer and maybe some nachos, please?
  • I do work with eCoupons.com (big $avings, etc), and we're stuck using J2SE for all of our stuff, just because we need things like generics etc. No, don't worry it's not actually a server app, it's more number/text crunching (finding y'all good deals, etc), but still it's a real pain.

    Here's hoping the venders get EE 5 out RSN :)
  • Honestly, when installing a vendor app, you have to install the corresponding jre leading to tons of different jre versions installed on the system (that takes much place and slow down install process. Trust me, when you want to deploy new version of Matlab across your network, you're happy to remove the bloated bundled java! Now I through every application that do no work with latest java 1.5.0_09. Netbackup: => replaced by bacula and backuppc: works fine (backuppc is killer app BTW) Matlab: repaca
    • How do you test that nothing subtle has changed?
      • Java is mainly used as a GUI frontent. If it displays correctly , have all menus and functions available and no crash during a day to heavy users, then I deploy. I'm not in a bank company ultra tested environment. If something goes wrong, then this is not dramatic. BTW, one more point for the opensource. All java opensource apps that I know of are java 1.5.0_09 compatible. (MyFreeTv, azureus, ...) Closed source apps are realy a hell. Not because you need to pay for, but because you have such problems like
  • Based on reading the Apache Geronimo dev mailing lists, it seems like Geronimo is looking to have some JEE5 preview features in their 1.2 release (maybe later this year?), with full JEE5 support likely coming in 2007.

    From the Geronimo dev mailing list: [mail-archive.com]

    To me the main open question about 1.2 is whether we can certify on j2ee 1.4 with jee5 spec libraries. If so it is fairly simple to include jee5 preview features.

e-credibility: the non-guaranteeable likelihood that the electronic data you're seeing is genuine rather than somebody's made-up crap. - Karl Lehenbauer