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