Slashdot Mirror


Java EE 5 Development Waiting on Vendors

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."

21 of 99 comments (clear)

  1. Not that big a deal. by MythMoth · · Score: 4, Insightful

    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.

    --
    --- These are not words: wierd, genious, rediculous
  2. SAP by ut.linuxer · · Score: 5, Informative

    SAP released a Java EE 5 compatible application server a few weeks ago.

    1. Re:SAP by Viper+Daimao · · Score: 4, Funny

      Knowing SAP, it won't actually work until Service Pack 7.

      --
      "In the game of life, someone always has to lose. To me, if life were fair, that someone would always be Oklahoma." -DKR
  3. If Java 1.4 works for you.... by Jason+Hood · · Score: 5, Interesting

    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.

    --
    Are you intolerant of intolerant people?
    1. Re:If Java 1.4 works for you.... by Anonymous Coward · · Score: 5, Insightful

      Well, the main reason to switch to 1.6 is that earlier versions won't run under Vista. (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.)

    2. Re:If Java 1.4 works for you.... by the+eric+conspiracy · · Score: 5, Interesting

      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.

    3. Re:If Java 1.4 works for you.... by Anonymous Coward · · Score: 5, Informative

      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.

    4. Re:If Java 1.4 works for you.... by frodo+from+middle+ea · · Score: 4, Informative
      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.

      e.g.

      • 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.

      --
      for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
    5. Re:If Java 1.4 works for you.... by heinousjay · · Score: 3, Informative

      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.

      --
      Slashdot - where whining about luck is the new way to make the world you want.
    6. Re:If Java 1.4 works for you.... by nuzak · · Score: 5, Informative

      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/

      > 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.

      --
      Done with slashdot, done with nerds, getting a life.
  4. Re:It's just too damn complex. by MythMoth · · Score: 5, Insightful

    The architecture of Java 5 EE is unnecessarily complex.

    This usually translates as "I don't understand all of the Java features - therefore it must be BAD.

    No. Java is necessarily complex. The features aren't their for Sun's entertainment - they're there because certain customers need and use them. It's not the most appropriate environment to build a "little" website, but that doesn't make it "unnecessarily" complex when building big ones.

    --
    --- These are not words: wierd, genious, rediculous
  5. JBoss already supports Java 1.5 by gabrieltss · · Score: 4, Interesting

    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.

    --
    The Truth is a Virus!!!
  6. Re:IBM and Oracle by Tim+C · · Score: 4, Insightful

    Then there is Oracle...gads..when Microsoft finally gets SQLServer up to speed (and they will...they have a 20 year history of turning crap into gold)...Oracle is going to be standing out in the weeds wondering what the hell happened

    What exactly does MS SQL Server and Oracle's RDBMS have to do with J2EE 5 and Oracle's Application server? You may or may not be right about SQL Server eventually supplanting Oracle as the big name RDBMS, but regardless, that's not what's being discussed here. The application server is completely separate from the DB server.

    but having to trust IBM and Oracle to keep up is a major problem, without them showing REAL plans: I am left with Sun driving the bus ?

    Hardly; JBoss and BEA (producers of WebLogic) have already released compliant servers. Given that I've only heard bad things about WebSphere (or indeed much of IBM's technology stack), I'm really not too concerned.

    well we all know what can happen when you let geeks (and I am one) run free, then don't execute on what they make

    What tends to happen in my experience is that they get it more or less good enough for their own use, then move on to the next thing that captures their imagination. That's all well and good, but someone needs to put in the remaining, tedious 80% of the effort to do all the boring tidying up, polishing, documentation, possibly accreditation, etc.

  7. love-hate relationship with J2EE by MarkWatson · · Score: 3, Interesting

    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" :-)

  8. Re:It's just too damn complex. by Anonymous Coward · · Score: 3, Interesting

    No. Java is necessarily complex. The features aren't their for Sun's entertainment - they're there because certain customers need and use them. It's not the most appropriate environment to build a "little" website, but that doesn't make it "unnecessarily" complex when building big ones.

    I stopped J2EE at JDK 1.4 and EJB 2.0, so perhaps J2EE 5 has some useful features. However, I can say with some certainty that Sun's spec have been on the one hand grossly overdesigned and on the other hand ridiculously limited. Examples:

    java.io.*
            1. Why in the world should a FileInputStream/FileReader not automatically use a BufferedInputStream/BufferredReader underneath?
            2. Why can't one just read a String from an InputStream by passing an encoding?

    java.net.HttpUrlConnection
            1. Why can't I get the actual HTTP error number and error page returned by a web site? (If you didn't already know, 404's are not returned as a generic error but rather thrown as a FileNotFoundException. But it also does it for 403, 405, and others so that you can't actually report the REAL error code. Also, in JDK 1.2.2, the function getErrorStream() returned null in all non-404 cases.)

    java.lang.ref.*
            1. The API to reference methods and variables is silly with all the Exceptions one must catch just to .invoke() a function.

    EJB - Actually, just read Bitter EJB. There's 200 pages of complaints and solutions, all hinging on the fact that Sun pushed a standard before they had any applications out there that needed this kind of functionality.

    Swing - Read Bitter Java. Another 200 pages saying that Sun made Swing without even trying to use it on an Office-like application.

    The really funny part

  9. Re:It's just too damn complex. by Anonymous Coward · · Score: 3, Insightful

    This usually translates as "I don't understand all of the Java features - therefore it must be BAD.

    Yes, it is very bad if your developers can't easily understand the tools they're working with. That directly leads to poor software systems that will often completely fail.

    Look at the Java EE 5 API for yourself: http://java.sun.com/javaee/5/docs/api/

    There are literally hundreds of interfaces and classes you'd need to understand to have a full knowledge of Java EE 5. Of course, that's in addition to the hundreds of interfaces and classes of the standard Java class library.

    Just look at some of the class names. One particularly bad one is javax.faces.component.ActionSource2. Why the fuck is a class called "ActionSource2"? To me, that's a sign of very poor object design. Unfortunately, this is the sort of stuff we see throughout the Java world.

  10. Re:It's just too damn complex. by kevin_conaway · · Score: 5, Insightful
    No, Java is often unnecessarily complex. Most languages get by with arrays; Java has arrays, Arrays, Vectors, and ArrayLists, all with subtly different APIs. Ditto Hashtable and HashMap. Mostly this explosion of APIs has happened because Sun hasn't thought through the design before adding stuff to the language.

    The differences you describe are there for concurrency. A Vector is a thread-safe List. A Hashtable is a thread-safe Map.

    Futhermore, you shouldn't be programming to concrete implementations like Vector, ArrayList or HashMap anyway. You should be programming to interfaces like List or Map so that implementation differences don't matter.

  11. ...and Vendors Waiting On Customers by kimanaw · · Score: 4, Insightful
    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.

    --
    007: "Who are you?"
    Pussy: "My name is Pussy Galore."
    007: "I must be dreaming..."
  12. Re:Dude, you're gay. by Marcus+Green · · Score: 3, Informative

    Yes you are right, Java is not popular at all. In fact I am always amazed at the way there are more adverts for Java jobs than just about any other skill (usually number 1 sometimes number 2) when hardly anyone uses it. I guess the companies just like paying for adverts for the fun of it.

  13. Better than the alternative by iabervon · · Score: 3, Interesting

    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.

  14. Re:It's just too damn complex. by nuzak · · Score: 3, Informative

    > Look at the Java EE 5 API for yourself: http://java.sun.com/javaee/5/docs/api/

    Then when you're baffled by reading reference docs, go read the tutorial: http://java.sun.com/javaee/5/docs/tutorial/doc/

    --
    Done with slashdot, done with nerds, getting a life.