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

6 of 99 comments (clear)

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

  2. 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!!!
  3. 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" :-)

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

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