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."
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
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.)
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
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.
It's official. Most of you are morons.
Excuse me? I develop software for a large European financial institution. I understand perfectly the complexities of enterprise development. Except that we use Smalltalk, rather than Java. Smalltalk offers many of the same OO capabilities as Java, and then some. But unlike Java, Smalltalk is about writing tight, compact class hierarchies. It's about architectures that are so simple that they naturally scale. We have Smalltalk-based financial systems that process 500000 or more transactions each hour, all running on DEC Alpha hardware from a decade ago.
And no, I don't know all the features of Java EE. Nobody does, because it's so unnecessarily complex. If somebody claims to, you know immediately that they are a liar. Ask those people if they know Smalltalk, or have even heard of it. Chances are they won't have. Thus the don't know how unnecessarily complex Java EE is for enterprise applications, as they have nothing better to compare it to.
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.
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.
Then there's the whole EJB and EJB QL fiasco. Massive amounts of additional complexity added for zero gain.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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.
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..."
Yeah. It's only the largest development API in the world.
... )
(Before answering, think Java ME and cellphones, except if you're american - then you're just several years behind in that area
Um. I think you're confused about the meaning of "complex". I find the JDK's collection classes to be decidedly lacking in unnecessary complexity. As a matter of fact, they reduce complexity, by hiding data structures behind generic interfaces. It's called polymorphism. In contrast, if all I had to work with were arrays, my application code would need to be much more complex.