Java EE 5 Development Waiting on Vendors 99
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."
Not that big a deal. (Score:5, Insightful)
Re: (Score:1, Insightful)
(Before answering, think Java ME and cellphones, except if you're american - then you're just several years behind in that area
Re: (Score:2)
+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 k
Re: (Score:3, Informative)
SAP (Score:5, Informative)
Re:SAP (Score:5, Funny)
Re: (Score:1)
If Java 1.4 works for you.... (Score:5, Interesting)
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.
Re:If Java 1.4 works for you.... (Score:5, Insightful)
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.)
Re: (Score:2, Informative)
Java on Vista: Yes, it Works [java.net].
Don't base your assumpsions on half-year old articles on beta software.
Re: (Score:3, Informative)
"Java SE 6 is the Best Solution for Vista"
[...]
"J2SE 1.5 Will Also Work
Many of the Vista fixes have already been, or will soon be, back-ported to J2SE 1.5. However, don't look for everything to work exactly the same; our primary focus was to make Java SE 6 the main release vehicle for Vista."
[...]
"J2SE 1.4.2 Will Basically Work..."
That means that if you want to have your Java application working smoothly on Vista, you beter have something that support Java1.6. You can still use 1.5 or even
Re:If Java 1.4 works for you.... (Score:5, Informative)
Use retroweaver to get 1.5 features and annotations in 1.4 code -- http://retroweaver.sourceforge.net/ [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.
Re: (Score:1)
Re:If Java 1.4 works for you.... (Score:5, Interesting)
Re:If Java 1.4 works for you.... (Score:5, Informative)
Re:If Java 1.4 works for you.... (Score:5, Informative)
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.
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.
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:2, Informative)
Using your definition, no language would ever be WORA because of stupid programmers who make invalid assumptions about the operating environment.
Re: (Score:2)
Good, you understand what the problem is.
Re: (Score:1, Interesting)
JSF is still a wreck. I guess it has its place, but our architects were all gung-ho for it and some of our programmers swore it would be the best thing for our company. After 6 months of using it they found out that it took
Re: (Score:3, Interesting)
Yep, me too. But once they've had a chance play with JEE 5, they'll find it's not so bad. Annotations have pretty much solved the deployment descriptor nightmare (I'll put an ejb-jar.xml file up against a Sendmail config file any day!), so now it's mostly just a matter of writing the beans themselves, not first writing them then trying to hook them up.
Fo shizzle! When I wrote my first web service, it was your typical J
Re: (Score:3, Interesting)
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
Re: (Score:1)
Re:IBM and Oracle (Score:5, Insightful)
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.
Re: (Score:1)
You are absoultly right. Please pardon my mixing
Re: (Score:2)
Re:It's just too damn complex. (Score:5, Insightful)
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.
Re: (Score:2, Insightful)
Re: (Score:1, Informative)
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.
Re: (Score:3, Interesting)
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 limi
Re: (Score:3, Informative)
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 E
Re: (Score:3, Insightful)
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/ [sun.com]
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 hundred
Re:It's just too damn complex. (Score:4, Informative)
Then when you're baffled by reading reference docs, go read the tutorial: http://java.sun.com/javaee/5/docs/tutorial/doc/ [sun.com]
Re: (Score:2, Insightful)
Then there's the whole EJB and EJB QL [ath0.com] fiasco. Massive amounts of additional complexity added for zero gain.
Re:It's just too damn complex. (Score:5, Insightful)
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.
Re: (Score:2)
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.
Re: (Score:1)
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 f
Re: (Score:3, Interesting)
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
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
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 ch
Re: (Score:1)
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
Re: (Score:2)
As to whether EJB 3 is better, well, doubtless I'll read up on it eventually and see. Once there are more actual implementations.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2, Insightful)
Re: (Score:2)
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.
Re: (Score:1)
Have you only ever used Java? (Score:1, Interesting)
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 [sourceforge.net] project, which offers Smalltalk-inspired collection classes for Java, shows
Re: (Score:1)
Re: (Score:1)
characterized by extreme simplism; oversimplified:
JBoss already supports Java 1.5 (Score:4, Interesting)
love-hate relationship with J2EE (Score:4, Interesting)
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"
Re: (Score:3, Interesting)
Re: (Score:1)
That said, I have "moved down the food chain"
Yes, I too used to be a J2EE tech-head. But I've got bored with keeping up with loads of APIs constantly evolving, and eventually realised most of it wasn't necessary for 90% of web apps.
Re: (Score:2)
I looked at using Lisp for some web based things a while back. I found a FastCGI implementation, but the only documentation it came with said 'read the code.' Can you recommend anything a bit higher-level (if I have to implement a web framework myself, that eliminates a lot of the advantage of going with Lisp.
Have you tried Seaside? It's a Smalltalk web app environment which is pretty much exactly what I want fro
Hmmn, that sounds like an opportunity(;-)) (Score:2)
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
...and Vendors Waiting On Customers (Score:5, Insightful)
I.e., if it ain't broke, don't fix it.
Re: (Score:2)
Re: (Score:2)
I see. I was unaware that my IBM/Sun/Oracle/BEA/etc. site engineer was going to just waltz into my office, do a quick copy of all those J2EE 1.4 JAR/XML/WAR/etc. files over to a shiny new EE 5 system, flip the switch and it will all magically work wo/ any service interruption. And of course, there will be no bill. Just like when they forced us to upgrade from 1.3 to 1.4...er, um, wait a sec...
I'm guessing you've never had to budget for such an up
Re: (Score:2)
Re: (Score:2)
Better than the alternative (Score:4, Interesting)
Waiting *on*? (Score:1)
Still waiting here... (Score:2)
Here's hoping the venders get EE 5 out RSN
I kill all non java 1.5.0_09 compatible apps. (Score:1)
Re: (Score:2)
Re: (Score:1)
Apache Geronimo & JEE5 (Score:1)
From the Geronimo dev mailing list: [mail-archive.com]
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.