J2EE 1.4 provides the groundwork for Web services development with J2EE, as well as important tool enhancements, new standards for application deployment and server management, integration and security enhancements, and improvements to J2EE's web app development capabilities.

Significant programming model changes include the JSP expression language and simplified tags, as well as the new timer service and QL enhancements in EJB 2.1. Integration has received a major face-lift, with two-way communication support in the J2EE Connectors specification and message-type independent EJBs.

Two new articles have come out on this topic this week:
The Evolving J2EE Platform (or, whats new in J2EE 1.4) an article that I wrote for the OTN.
Servlet 2.4: What's in store, by Servlet expert Jason Hunter.

Some of the changes are nice. Some things I do not buy like the reasons that SingleThreadModel is deprecated. If I read about "programmers should use synchronized blocks" this sends chills down my back. Probably the real reason is just that it is rather hard to build (from a container vendors point of view) and performs awfully under load (one instance for a client). Reasons like "static variables are not protected" or "oh my got the session access is not synchronized" are just laughable. If you expect a developer to understand the servlet request/response cycle, security model etc. in the first place, you can assume he/she is able to understand such issues by reading the documentation....

The adoption of an "expression language" however, is probably the most stupid idea I've ever heard. Removing code from presentation layer, it does not. Instead it introduces a different notation of code that saves you some keystrokes. Super. Also, it just seems ridiculous that no existing expression or scripting language was adopted but something new was needed of course. In my opinion, an additional let alone a new language always adds complexity rather than reduce it.

I found the expression language very useful, much more intuitive and less verbose than previous tag libraries I was using (mainly struts tag libraries). In my opinion it's a very welcome feature!

Best regards
Enrico

It’s a time of change for those who have already invested heavily in J2EE, some of the new features mean we will be tempted or pushed to replace proprietary or open source stuff that worked.

There are two sides to this.

1. "Good"
I previously wrote a scheduler based on the J2SE Timer classes. It allowed persistent and durable events, it worked well and was quite flexible. However I had to consider some clunky work arounds when it came to using it in a cluster. I will gladly dump this in favour of the EJB 2.1 Timer services when they become available in containers, as they will provide tight integration with EJB taking care of many thorny issues.

2. "Evil"
I am a big fan of Webwork the UI framework; this has an expression language already that is quite useful. I see no reason to learn yet another sub-language to do the same thing. Even the much-maligned scriplets, I have seen them used to good effect by good developers. So even if the new expression language proves to be a good thing in the long run I can see why there would be resistance to it.

I guess my point is we all have our reasons to love or hate bits of the new spec, right now its just teething pain, only time will tell if we grow great canines to cut through problems with ease or not.

Tendayi

Google "vendorscript". Same issue.

I agree, the scripting language bit feels like a hack. I mean, why invent a new language? Isn't the idea that you are not supposed to be putting java code in the JSPs anyway? I would've rather seen a modification to the existing tags, like:

<jsp:getProperty name="someBean" value="blah.foo.bar"/>

which fits in with the whole system, rather than introdcue yet another web markup thing. Now, there's HTML, JSP, and this new expression thingy. Ugh is right.

And if we are saving typing, why not change getProperty to get. It's not like there's anything else being "gotten", so it's pretty clear what "get" does. Actually, getProperty doesn't "get" a property, it prints it into the HTML page! So, why not call it jsp:print?

I've always felt that JSP is poorly thought out and it feels like hack every time I use it. taglibs help, but there really could be an easier way to dyanmically populate web pages.

Dave

The new JSP Scripting language does look like a complete kludge! Why not just use an existing language -- how about something VBScript-ish, which is far easier to read for non-programmers than JavaScript is. After all, if removing code from the presentation layer for the sake of designers was the motivation, they I'd have to say that they failed miserably.

Not only have they introduced yet another syntax with its own idiosyncracies, but they've also managed to make it so different from anything else that a designer would be familiar with, so that he's going to be more confused than if he saw some Java language in the first place!

This business of coming up with a whole new language sub-set for each problem has got to stop!! This sounds like something straight out of academia -- invent something new so I can write a paper.. who cares if industry thinks its useful or not!

We don't need a new language.. we need the current language to be more painless and more powerful!

but you are not obliged to use this EL. Is not it?

Dmitry Namiot
Coldbeans

Yeah, but someone will use it, products will incorporate it and in the end, in a standard development environment you will be obliged to use it.

You are for example also not obliged to use all the features in C++ that are considered harmful but it has taken about 10 years to understand this (and which features are harmful is still a matter of discussion).

If I'm not mistaken, I've been using this for over a year now. It's called "Velocity".

Where is JAXM ?

Since I work in B2Bi, I am anxiously awaiting a J2EE standard for Asynchronous Web Services. JAXM seems rather underwhelming based on its dependence on a MOM, when JMS will do exactly the same thing.

All the hype is always about RPC Oriented web services, there is so little support and information for Document/Message oriented web services.

>
> Since I work in B2Bi, I am anxiously awaiting a J2EE standard for Asynchronous Web Services. JAXM seems rather underwhelming based on its dependence on a MOM, when JMS will do exactly the same thing.
>
> All the hype is always about RPC Oriented web services, there is so little support and information for Document/Message oriented web services.

Using RPC Web services is hardly as useful as using them for implementing business flows. Is J2EE going to add support for the emerging Web service orchestration standards such as BPEL4WS?

Cheers.

Jill.

Half the answer: http://jcp.org/en/jsr/detail?id=208.

As for whether J2EE will add support, well, that's up to the expert groups.

glen

I think the new EL (which is available now as part of JSTL) is a mixed bag at it stands right now. The good thing is it does simplify the code on many occasions (especially with use of JavaBeans). However it still needs improvement in many area for it to be really useful. For example, adding support for method-calling of scoped variables would be welcome which make working with existing taglibs a breeze.

In my opinion the EL and JSTL are exactly what JSP needed. Before this, it was sitting in the same mess as for example VBScript.

Now you can finally write completely script free JSP documents in the JSP xml syntax. This can not be done when you have to do constructs such as <a href="<jsp:getProperty>">. Now THAT is ugly. The EL with JSTL and JSP xml syntax gives you major spin off effects like pages that generate markup that are guaranteed to be valid xml which in turn can be used for example for transformations to pdf documents.

If you find the EL and new improvements to JSP offensive, I don't think you understand it well enough. I'd never go back to the old way to do it.

I strongly agree. To me, it's hard to understand why would someone not like the new EL. It's simple, flexible and just looks right (as opposed to say, Velocity's "getXxx()" syntax). You can even extend the EL with new functions, by mapping a Java class with static methods.
IMO, the EL and JSP tag files, new features in JSP 2.0, make JSP (finally!) a very good environment for MVC web app development.

Rogerio

I don't want to start a debate here but I believe JSP/presentation tier in Java has to learn a lot from ASP.NET code behind approach. You can literally code the whole website without writing a single line of html or embedded script code. Just think your whole website is nothing but source code written in a high level programming language. Don't you guys think it is cool? All you need is an editor and your choice of language (C#, J#, VB.NET) and that is it. I believe JSF is close but still not reach there. I don't think so adding a new expression language helps us any more. We all know that cryptic coding in the html tags is no more acceptable. I hope Java community will soon realize the power of code behind. Don’t be biased and learn from the experts(Micro Soft) who are the UI pioneer:-)

Code behind is how Microsoft choose to solve the task. It has it's points. And definitely it's drawbacks. The biggest one I think is that they still think page centric. Requests shouldn't go to web pages. They should go to the Controller.

"Don’t be biased and learn from the experts(Micro Soft) who are the UI pioneer:-)"

I believe the UI pioneers actually are Apple. From 1984 and forth.

Code-behind is a great idea, but it has nothing to do with building the UI with code (C#, VB.NET, etc.). It's only a way to associate an object with the page; this object represents both the model and the controller for the page. In ASP.NET and JSF, the model data is stored in UI component objects, while event handler methods respond to user actions.

I think this approach is better than the so-called "Model 2" approach used by Struts, where pages are not directly targeted. We could call it "Model 3". (It's also possible to define "Model 4" in JSP 1.2+, by using a controller filter instead of a controller servlet.) The big advantage of "Model 3" is that it does not require a big and ugly XML file for mapping logical URLs to JSP pages. I don't see any significant disadvantages, but apparently a lot of people do. So, what am I missing? Anyone care to elaborate?

Rogerio