I just across this comment by Douglas Crockford on threads.

No. Java did not get it wrong. In the Java (or even other managed languages) world, the system level software are the containers. Containers use threads to manage the applications deployed on them. Applications are managed, and rarely use threads.

Yesterday, I was tipped by one of my ex-colleagues at BEA that both JSR-286 and WSRP 2.0 have been finalized and submitted for voting by JCP and OASIS respectively. I was an active contributor to both these specifications till mid 2007. Congratulations to both the working groups!

No, this is not about Rails vs Java/JEE. There have been a number of Rails vs Java/JEE debates over the past couple of years, and I realize there is not much left to be debated. Most of us have settled into one camp or the other. I will also leave it to others to debate whether Ruby on Rails is just serving a niche area, or whether it has become or will become mainstream for enterprise developers. This post is about a few of features that I wish JEE borrows from the Rails framework to make matters easy for enterprise developers.

Here is a key deployment problem that the servlet spec needs to address in its next version.

So far, the servlet spec recognized only two classes of users:

• Containers developers: Developers who implement the spec.
• Web developers: Developers who program to the servlet API and develop web apps.

But there is a growing third category of users of the servlet spec, and this group needs recognition from the servlet spec.

This reminds me of Swing.

Where is WebAWT? Can't wait.

Angle brackets or annotations? Is JAX-WS over-engineered or does it simplify web services development? I am disappointed with the points made by Richard Monson-Haefel and Jason Greene in their challenge and retractions against how complex or easy it is to use JAX-WS. Both their posts were provocative, but sidestep most of the requirements of complex web services. IMO, their positions are at the extreme ends.

While I was googling for some web services related work, I came across several pages containing "SOAP over JMS". SOAP over HTTP makes sense, SOAP over SMTP makes sense, but what about SOAP over JMS?

If you have been using JAX-RPC for developing web services, you may have noticed how XML gets into churned into typed objects. Implementations may differ in the exact details, but the Java SOAP toolkits I know go through some hoops to get request/response data from memory to the wire and vice versa. Some of these hoops cause data duplication, which you may want to avoid for performance reasons.