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
SAP released a Java EE 5 compatible application server a few weeks ago.
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?
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
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!!!
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.
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"
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.
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.
.invoke() a function.
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
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
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 (;-))
--dave
davecb@spamcop.net
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
We have Smalltalk-based financial systems that process 500000 or more transactions each hour
It can't be that large a European financial institution then. I have clients who specify 20000 transactions per second for their J2EE based trading platforms.
This is like saying that a human's appendix is the result of bad design, and nature should have thought it through better, because its mostly useless now. Its just an artifact of evolution, just like Java's old collections. I think Sun has done a pretty decent job of retrofitting their old utilities into the collections framework, and then into the new generics framework.
That article you cite is over 3 years old! Sure, mistakes have been made, but EJB3 is sooo much better than anything out there for what it does - and I am also a Rails developer (its all fun until you try and use it for legacy databases, deploy it, or maintain it).
http://www.coderoshi.com/
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.
Yes, but I don't want a programming language that has evolved through random mutation and natural selection. I want one that has been carefully designed for expressive power, ease of use, and consistency.
As to whether EJB 3 is better, well, doubtless I'll read up on it eventually and see. Once there are more actual implementations.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Did you mean simplistic? According to dictionary.com that word means
characterized by extreme simplism; oversimplified:
It's not very good to compare arrays with ArrayLists etc. I am sure programmers in other languages than Java also uses dynamic structures like List or Map. array[] Array and ArrayList are three different things and they are there for purpose. I think it is great that I have ready-made ArrayList, HashMap, and even more complex dynamic structures, so I do not have to "homebrew" them. Don't you?
Understandable. But I also like being able to use artifacts without having to wonder if they still work. My personal belief is that, when JDK 7 adds support for scripting languages and a compiler API/hooks, Java as a language will slowly be replaced by task-specific ones, becoming just a really good JVM. Use the language you want (like .NET is supposed to be). The fact that JRuby has been brought on by Sun is a step into this direction.
http://www.coderoshi.com/
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.
1. Why in the world should a FileInputStream/FileReader not automatically use a BufferedInputStream/BufferredReader underneath?
Why do you assume that filereaders must be buffered? I agree that the syntax for reading files is horribly redundant, but I bet with a few static imports, I could make java file handling code look downright pythonish. Write convenience methods for godsakes, don't listen to the aescetic code monks who insist you use nothing but the standard library.
I stopped J2EE at JDK 1.4 and EJB 2.0, so perhaps J2EE 5 has some useful features.
I'll say -- EJB3 is much simpler, for one! It's not without its problems, but it actually makes a lot more sense now. I'd agree that a large number of Sun's API's are bloatastically overengineered, but EJB really has gotten its long-needed overhaul. Other than perhaps optionally dispensing with local interfaces altogether and just using the raw class, I really can't see how it can get any easier.
Sun pushed a standard before they had any applications out there that needed this kind of functionality.
This is a wholly unfounded opinion -- there were in fact plenty of apps that needed what EJB was offering, things like reservation systems that needed to coordinate across multiple vendors. Only problem was that it didn't go far enough for the shops that did need it, and that 90% of business apps were simple CRUD apps that didn't need it at all. Java's got the enterprise and embedded angles covered, but it's still not offering a whole lot toward the middle. Not that I think that offering a mediocre platform is the answer, but they could at least have offered better tooling instead of assuming you'd have a massive team of "enterprise architects" putting apps together. But go look at EJB3 -- there's some signs that they're actually catching on.
And I don't even like Java -- the language itself, that is.
Done with slashdot, done with nerds, getting a life.
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?
It's true I tell you, feller at work's next door neighbour read it in the paper.
> 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.
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.
... I just see the RDBMS and J2EE5 as having a conection in the eyes of the "CTO" types, and that if Oracle doesn't come along they are at (even more) risk of Microsoft moving in on both fronts....I may have skewed the topic a bit here....again pardon my skew.
You are absoultly right. Please pardon my mixing
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.
My point here is that I don't see JBoss and BEA being able to keep Sun on track...by this I am again mostly speaking of the need for the JBoss, BEA, Oracle, Sun and IBM keeping on some common track. MS will divide and kill...maybe I'm just looking ahead too far.
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.
You have an excellent definition of "geek" here...I was using the term as it applies to Sun as a company..They geek out and without the other players keeping them on track; I just don't see who has the geek power and geek control to replace them......I'm probably just looking too far down the wrong line here again.
Your comments have been well taken...I'm hip...Thanks.
]] The differences you describe are there for concurrency. A Vector is a thread-safe List. A Hashtable is a thread-safe Map.
These additions were also made royally late in the game, and only when Sun had to realize, to its embarassment, that all these fancy java.util classes were completely un-reentrant. The GP poster is still right in his complaint.
Religion is what happens when nature strikes and groupthink goes wrong.
I think you're missing the point. I'm not saying that all you need is arrays; I'm saying you don't need 4 different implementations of arrays that have different interfaces.
The same is true of other Java APIs; it's not that the functionality exists, it's that it exists multiple times with different APIs because they didn't think through the right way to do it before dashing in to an implementation and stuffing it into core Java.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Have you only ever used Java?
I find that when somebody advocates the use of Java, it's because Java is basically the only language they know. They're not aware of how easy data structures are to create and manipulate in languages like Common Lisp, Haskell, OCaml, SML, Python, Ruby, and Smalltalk.
Take the Smalltalk collection classes. They're a work of art, and put the Java Collections classes to shame. The homepage of the Jaggregate project, which offers Smalltalk-inspired collection classes for Java, shows very well just how fucked up the JCF is.
I agree to your accessment, however, the GP post is also correct regarding "subtly different" APIs - which is annoying.
At least, any good API designer would have named them "ReentrantList" and "ReentrantMap" other than inventing new names "Vector" and "Hashtable" out of thin air that bear no semantic resemblance to what the classes actually do.
Let the interfaces have generic names, but the concrete implementations should at least be named clearly for what it does.
I hope this would change when Java generics become powerful enough to support metaprogramming, like C++ templates do - since it would support policy-based design - so instead of Vector, ArrayList, HashMap, you'd have Map<Reentrant> or List<Reentrant>.
I don't think that "they didn't think through the right way to do it before dashing in to an implementation and stuffing it into core Java" is a fair characterization at all, when it comes to Java's collections. History indicates otherwise, at least to me. Java 1.0, circa 1995, contained only three collection types - the primitive array type, Vector, and Hashtable. These provided adequate functionality for simple things, but certainly didn't provide full-fledged collection support. It wasn't until late 1998, with the release of 1.2, that the collection interfaces and classes were officially added to the JDK. So what happened in between? There were several independent efforts to provide more powerful collection support. One was a set of public domain classes developed by Doug Lea. (It's described here: http://g.oswego.edu/dl/classes/collections/.)
The other was the Java Generic Library (JGL), which was essentially a port of C++'s STL. Prior to 1.2, JGL was quite popular, but Sun eventually went with a solution derived from Doug Lea's classes, rightfully so, in my opinion. (The old Vector and Hashtable classes had to be kept around for backward compatibility, but they were incorporated into the new framework, by being made to implement List and Map, respectively.)
To me, this history shows that in the case of the collections, Sun certainly didn't dash in to an implementation and stuff it into the JDK. Had they done so, there wouldn't have been that 3 year delay, and we'd have ended up with something much worse than what is there now; and what is there now is not bad at all, IMHO.
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
Agreed, although Vector and Hashtable are not really there for concurrency; they're there for backward compatibility, having been around since 1.0. They don't really support thread safety properly anyway, so there's really no reason to use them ever, unless you're communicating with an API that uses them.
Instead of waiting for big corps like IBM, Oracle, and Weblogic to step up, my suggestion is to simply not use their servers. I honestly don't know a "rational" reason for using any of them. It's amusing that companies will use tons of open source software but not if it's the app server. I could understand it if they were actually better but they aren't. In fact, they flat out suck.
Any man who afflicts the human race with ideas must be prepared to see them misunderstood. -- H. L. Mencken
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: repacakged to rpm killing builded java. Matlab 2006b works fine (even better) using java 1.5.0_09 :-) I keep it
Like he said, unnecessarily complex.
http://rareformnewmedia.com/
This is a seriously important debate.. But there is no one right answer.
On the one hand, you have the perl paragidm - keep absolutely everything in one file.. code, docs, API, meta-information.. In perl you had __DATA__ and __POD__ sections of the file for meta-data and documentation.. In Java you've almost always had javadocs, then xdoclets, and now annotations.
The advantage of this is the idea that code-changes almost always necessitates doc changes or meta-data changes.. The further away those items are from the code, the greater the probability that they'll get out of sync.
ALSO, new-commers that see the code for the first time won't have as far to go to get all the information about the code that is relevant.. If they are paging through a new project, they may not know where the associated meta-data XML files are.
Now, good annotation packages (like hibernate-annotations) allow you to override just about every possible annotation in use... And as a result, it makes the most sense to only annotate to the degree that generality necessitates.. Consider this object-oriented annotations (even though it's a hack-job on the back-end, because the code has to know to recursively check for annotations and XML in all the right places).
The other side of the story is important too... That if your code is dependent on annotations (say you're hack-job didn't facilitate XML overrides), then you reuse code in two different contexts, you're screwed, because you've historically coded to one annotation schema, but then in one or more use cases, those annotations are not correct.. This is most common in interfaced' API libraries (with little or no actual code). If say a @Transactional attribute is present in the API, but it's being deployed in a non-transactional environment (say a trivial front-end web-app that doesn't do any DB activity and thus doesn't have a registered transaction manager), then you might be in for a shock when you first deploy the code. That being said, things like @Transactional are encouraged to exist only in the class implementation code, not in the interfaces. But you might have a poor annotation package which doesn't handle this properly.
Another example is if you define schema attributes on the POJO, say
@Length(max=32) String firstName;
Then you use this Person object everywhere... Well, not every place is going to want a column length of 32 chars (though this might be a good-thing).. Again, in Hibernate at least, you can always override in XML for a particular deployment... But it violates the use-case above of a 1'st time prorammer paging through the code.. Now they have a false expectation.
I'm sure there are other pros and cons. But Annotations are far better than xdoclet.. And xdoclet as a paradigm has exploded.. For trivial one-use-case code, xdoclet and annotations are a god-send. Consider EJB2 XML files and meta-interfaces which are a nightmare. All are handled elegantly via annotations. Less code/files == less chance for error.. Concice with little revocation of flexibility. Though in huffman-coded style, that old flexibility now requires twice as much conceptual complexity (knowing to look at XML for only special cases - and thus forgetting about it).
-Michael
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:
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.
+10. C/C++ are most often used languages in real life. That's fact.
Java is also used - in data centers and in middle ware. IOW, precisely what I call niche: for every server in the world using Java there are at least ten running PHP or something else. And for every server out there - whatever it is running - there are lots of gadgets and embedded systems around us. PHP == C, embedded == C/C++. GCC is true king of the software world.
People like Java - so let them be. It is unfortunate that Sun still keep the stewardship of Java platform. I'd love to have stripped down Java, so that we could bundle Java applications with our own stack. But Sun doesn't allow to ship one particular version, nor stripped-down version: they do not like embedding (slave JVM inside other application - applets in browsers are notable exception), they want auto-updates (no way we are allowed to have updates from 3rd party), they want plugins, they want megabytes of useless stuff to be shipped. As my company stands, we are not allowed to include untested code - and no way we would be able to test all java libraries Sun includes. And Sun disallows us to ship subset. Dead end, IOW, as I am concerned.
All hope abandon ye who enter here.
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.
Implementation differences do matter when it comes to performance. If you're using a large List for random access, it better be an ArrayList. If somewhere down the line the code creating the list changes it to a LinkedList, you want your code to fail to compile/run because you'll need to change it to avoid performance issues.
Except that has back in Java 1.0 before the Collections interface in 1.1. And that was - what 7 or 8 years ago??? A very early release (late in the game?).
Time for the GP to get over it. Nobody uses Vector or Hashtable anymore, they are only there for backwards compatability and for newbee / incompetant coders who can't handle multi-threaded code (like so many early Java programmers who came over from C/C++). When Sun tried to remove them in 1.4 and again in 1.5 the market shouted them down. Don't blame Sun for them, blame the industry and your fellow coders.
We do not inherit the Earth from our parents. We borrow it from our children.