To author

[Pradeep bhatt]

How do you think that the J2EE web tier will grow in coming years?

[Jayson Falkner]

That is quite the question....
Honestly, I think the best way to tell will be to look in a few years, but I'll dump a few thoughts.
Some of my favorite things about the J2EE web tier (i.e. Servlets/JSP) is that it is completely open-source (http://jakarta.apache.org/tomcat), it is free to use, it leverages off the existing JVM/Java API, and it provides a clean migration path to more complex, demanding needs such as server clustering and state management in a distributed environment.
I think it is fair to say that most web-page-making languages *can* do this, but in the open-source, free arena, JSP is hands down the winner. It is a standard, it has a good development cycle, it has been proven to work, the Java programming language is incredibly powerful (not to mention has an incredible amount of existing API), and there are lot a big companies putting a lot of money behind the language. IMO, JSP/Servlets will be around and in popular use for at least a few more years, simply because nothing in the open-source world can compete. If you throw in the closed-source alternatives (namely .net), the situation is more interesting, but J2EE will definitely always be stiff competition -- especially with the popularity of Java/Linux.
What do you think?

[Kevin Jones]

I have a major concern about the web tier, which is fragmentation.
Over the years Servlets have grown from an 'wow' technology, as in 'wow you can do that with Java,' which was my original response to seeing Servlets; to being a cornerstone of many web projects and many web architectures. By this I mean that Servlets are themselves used as parts of applications and also as the heart of various frameworks.
The servlet specification has had to grow to fit into these roles and unfortunately as a consequence of that growth can be seen as incoherent and muddled in parts. There are obvious parts of the specification that are fossilized. There has been discussion on various blogs recently (for example (here)
that the Servlet specification needs a grounds up re-write because of this.
Currently I have no real strong opinion on this either way but I do feel that it is important the the next revision of the specification keeps the community together. We have important battles to fight in the form of Microsoft and the ASP.Net framework, and know is maybe the time to revisit the entire servlet/filter/event architecture and come up with a similar model that is more extensible, and that has been designed to be extensible from the ground up, and designed to work well in the face of multiple protocols (HTTP 1.0 etc), multiple environments (J2ME?) and multiple usages (web services). Now the servlet spec has worked well in many environments and may only need tweaking, we'll have to wait and see.
Of course the risk is that re-writing the framework will destroy much of what has already been done and so, again, fragment the community.
I have the same issue with JSP. Many people that I respect regard JSP to be a complete waste of time and prefer to use a 'real' markup technology. Things like Tapestry come to mind. JSP 2.0 has made great strides away from being a Java environment to being a markup environment, but (IMO) it is still too difficult to use for non Java developers. As much as I love tag libraries they are too clunky to be used for control statements (such as loops). I strongly feel that we need a real page level language in there with a syntax that's easy to use and understand. The EL only gives us expressions, what I would like to see is a limited form of control in the language

[Ko Ko Naing]

Mr.Kevin and Mr.Jayson,
What do u also think about Business Tier's trend in the future? Will be it growing like Web Tier? As far as I know people are afraid to use EJB, coz it may build a problem back to the application, if it is not developed with care... I mean people, who does not have enough ability to handle EJB tech, are afraid of using EJB in their app, coz they do not want to mess the application up because of their influent ability.... What is your opinion on the business tier, comparing with web tier? Correct me, if my opinion is wrong...

[Pradeep bhatt]

Thanks Jayson and Kevin !
What do you feel about this MS article comparing ASP .NET and J2EE struts.
http://msdn.microsoft.com/asp.net/default.aspx?pull=/library/en-us/dnaspp/html/aspnet-aspnet-j2ee-struts.asp

[Frank Carver]

Kevin wrote: I strongly feel that we need a real page level language in there with a syntax that's easy to use and understand. The EL only gives us expressions, what I would like to see is a limited form of control in the language
I'm intrigued by this. Can you expolain a little more what benefits you would see in layering yet another (probably not-quite-compatible-with-anything-else) language for use in JSP?
As far as I recall, the original JSP spec allowed for alternative scriptlet languages, but the community as a whole ovewhelmingly adopted Java as the scriptlet language, as opposed to (for example) the simpler JavaScript. There are obvious benefits to using Java for such scripting: availability developer skills, familiarity, and the ability to easily move scriptlet code straight in to tags, beans or regular Java classes during maintenance or refactoring, etc, etc..
Sure the page markup language in (for example) Velocity/WebMacro may be "simple", but it's different, next to nobody is skilled in it, you can't get hundreds of books and courses like you can in Java.
So. Given that we already have an extremely powerful, flexible, and well-known scripting language built right in to every current JSP container, what might you see as the incentive to invent another one?

[Pradeep bhatt]

Does any vendor support scripting language other than Java?

[Gregg Bolinger]

I have the same issue with JSP. Many people that I respect regard JSP to be a complete waste of time and prefer to use a 'real' markup technology. Things like Tapestry come to mind. JSP 2.0 has made great strides away from being a Java environment to being a markup environment, but (IMO) it is still too difficult to use for non Java developers. As much as I love tag libraries they are too clunky to be used for control statements (such as loops). I strongly feel that we need a real page level language in there with a syntax that's easy to use and understand. The EL only gives us expressions, what I would like to see is a limited form of control in the language
Interesting thoughts..I would just like to argue a bit if I may. I can't agree that we need a "...real page level language..." and I would argue that the control you speak of

Maybe should be abstracted out into the model

IMO is already available with JSTL

unless I am misunderstanding what you mean by "control". The reason I like JSP over other "view" technologies is because it holds true to the XML markup language that every web developer (HTML or Java) should already be aware of if not know very well. Most people are already used to browsing through code and seeing ${...} as the EL now provides (ANT comes to mind). But I just find it silly, yes i said silly, to see things like #variable in an HTML page like velocity uses.
Too much "code" in an HTML page and you might as well use PHP or something of that nature.
As far as fragmenting the community, there are already so many options available in the Java community in general and our community is already fragmented to an extent. Have you seen the WW and Struts wars going on? It's crazy. And those are just frameworks. If there is anything nice about .NET it's the fact that you don't have so many options. You know what you have to use going in. And you can concentrate on getting the project done. With Java and more specifically J2EE you start the project with

Struts, WW, Tapestry, straight servlets??

Hibernate, JDO, JDBC, Castor??

Ant or Maven??

Eclipse, IntelliJ, JDeveloper, Notepad?

Xerces, JDom??

And the list goes on. My point is our community is fragmented into "option" factions. Struts clans, Maven clans, Notpad clans. And someone wants to rework servlets from the ground up? Why not just make another spec all together and give us 1 more option? :roll:
Just my opinion anyway.
[ January 29, 2004: Message edited by: Gregg Bolinger ]

[Frank Carver]

Pradeep wrote: Does any vendor support scripting language other than Java?
I'm sure that Resin 1 and 2 support Javascript scriptlets in JSP, but I'm not sure whether that capability is still in Resin 3.

[Pradeep bhatt]

What is this Tapestry all about? :roll:

[Basavaraju Banakar]

Any comments over using XML/XSL/XSLT in place of JSPs?

[Ko Ko Naing]

Originally posted by Frank Carver:
I'm sure that Resin 1 and 2 support Javascript scriptlets in JSP.

That's a good news for JavaScript programmers... By reading through the JSP 2.0 spec, I always think that "java" is the only value for language attribute in the page directive... Does it mean that we can specify as language="javascript" and use JavaScript scriptlets in JSP with Resin 1 and 2?
Thank you for your info, Mr.Frank....

[Jeroen Wenting]

iPlanet supports (or supported) Javascript as a scripting language though their way wasn't JSP (they invented their own JSP-like language based on serverside Javascript which was introduced at around the same time, it didn't take off).
The servlet API is working out quite well IMO.
Maybe it's too large and parts need to be deprecated (and it's high time to remove all the deprecated stuff left over from 1.0 and 1.1, maybe 1.2 JDKs out of the entire standard platform as well but that's another story. Some classes and functions have been deprecated since JDK 1.1 with messages in the javadoc saying they'll be gone in the next version yet are still there, that's no incentive for people to not use deprecated stuff).
The MAIN problem I see with J2EE is the extremely bloated and ill thought out thing that is EJB and especially entity beans.
That API DOES need not just a good cleanup but a complete rewrite in which IMO entity beans should be dropped completely and session beans made a lot simpler to create and maintain.
JSP is good as it is now that it's reached maturity in 1.2 and 2.0.
There's nothing on the market that can come close to the power and flexibility you can garner from using JSP with JSTL, custom tags and careful use of scriptlets.
Any other language that tries (like ASP or PHP) yields huge reams of application code inside the page, much like JSP 1.0 was plagued with.
As to XML/XSLT to generate output instead of using JSP, I've done it and still do on occasion.
The main incentive is when you have output that needs to be generated differently from the same data depending on where the request is coming from or what the request wants (for example, a servlet that will be called from desktop computers, PDAs, maybe cellphones, and SOAP clients is an ideal candidate for this treatment).
Depending on how you code the transformation engine (and I think I've coded a quite efficient one) it can be very fast indeed, preventing almost no overhead compared to JSP execution.
But due to the relative complexity and lack of sheer power inherent in XSLT (as compared to JSP) the things you can do are somewhat limited so it doesn't lend itself to everything (plus I find XSLT often hard to read in comparison to JSP which makes maintenance more problematic).
[ January 30, 2004: Message edited by: Jeroen Wenting ]

[Pradeep bhatt]

Does the book cover JSF?

[Ko Ko Naing]

Originally posted by Pradeep Bhat:
Does the book cover JSF?

I don't think so, Pradeep... That topic looks like beyond the scope of the book... Here is the book's "Who is this book for" page and there is no JSF topic listed, even not a word of "JSF"...
http://www.jspbook.com/about.jsp

[Kevin Jones]

I'm intrigued by this. Can you expolain a little more what benefits you would see in layering yet another (probably not-quite-compatible-with-anything-else) language for use in JSP?

I'm not advocating another language but I think it is worth looking at extending the EL so that it supports certain control functionallity such as conditionals and loops.

As far as I recall, the original JSP spec allowed for alternative scriptlet languages, but the community as a whole ovewhelmingly adopted Java
as the scriptlet language, as opposed to (for example) the simpler JavaScript.

This is correct. However I believe the reason the community adopted it was because of two reasons. One, Tomcat (the RI) used Java, so other sides followed suite, and two, because of limitations in the spec. The JSP spec is layered on top of the Servlet spec and stated that JSPs are servlets. In that case there is already a translation between 'JSP' and Java code. So leaving the script language as Java makes this translation much easier. Also the spec stated that any scripting language must give full support to all the Java runtime (all the classes etc.) Again this makes it much easier to use Java as the scripting language rather than anything else.

There are obvious benefits to using Java for such scripting: availability developer skills, familiarity, and the ability to easily move scriptlet code straight in to tags, beans or regular Java classes during maintenance or refactoring, etc, etc..

Using Java for scripting was always a really bad idea! Java on a JSP page causes so many problems in maintenance that it sould never have been allowed through in the first place. Most if not all people reading this will be Java programmers, however in web application development many folks aren't Java programmers and trying to get those guys to learn Java and understand objects/references/arrays etc is very hard. This is why such a concerted effort has been made in JSP 2.0 to discourage the use of Java as the page level scripting language

Sure the page markup language in (for example) Velocity/WebMacro may be "simple", but it's different, next to nobody is skilled in it, you can't get hundreds of books and courses like you can in Java.

Sure, but could you expect a non-progammer to learn Java as quickly as a programmer. I don't think so.

So. Given that we already have an extremely powerful, flexible, and well-known scripting language built right in to every current JSP container, what might you see as the incentive to invent another one?

To make life easier! We're not talking about a full blown language here, we're talking about extending the EL to have something like a forEach construct to iterate over collections. That has to be easier than writing Java code.
Each language has it's place. Java is great for the business and control logic, but it does not work well as a scripting language!

[Kevin Jones]

Interesting thoughts..I would just like to argue a bit if I may. I can't agree that we need a "...real page level language..." and I would argue that the control you speak of
* Maybe should be abstracted out into the model
* IMO is already available with JSTL
unless I am misunderstanding what you mean by "control". The reason I like JSP over other "view" technologies is because it holds true to the XML markup language that every web developer (HTML or Java) should already be aware of if not know very well. Most people are already used to browsing through code and seeing ${...} as the EL now provides (ANT comes to mind). But I just find it silly, yes i said silly, to see things like #variable in an HTML page like velocity uses.
Too much "code" in an HTML page and you might as well use PHP or something of that nature.

In general I agree with you, however the fact that we need JSTL points to the conclusion that we need more control in the page. And I would guess that the most common JSTL tags are c:if and c:forEach, which points to the conclusion that we're missing something in the EL. I would never argue that we should put model level logic in the page. But we do need some display level logic (again, otherwise we wouldn't need c:forEach). The aim should be to make life easy for page authors, JSTL makes it easier but we could bo better

As far as fragmenting the community, there are already so many options available in the Java community in general and our community is already fragmented to an extent. Have you seen the WW and Struts wars going on? It's crazy. And those are just frameworks. If there is anything nice about .NET it's the fact that you don't have so many options. You know what you have to use going in. And you can concentrate on getting the project done. With Java and more specifically J2EE you start the project with
* Struts, WW, Tapestry, straight servlets??
* Hibernate, JDO, JDBC, Castor??
* Ant or Maven??
* Eclipse, IntelliJ, JDeveloper, Notepad?
* Xerces, JDom??
And the list goes on. My point is our community is fragmented into "option" factions. Struts clans, Maven clans, Notpad clans. And someone wants to rework servlets from the ground up? Why not just make another spec all together and give us 1 more option?

I know, great isn't it This is what keeps the community vibrant and alive so fragmentation is not necessarly a bad thing. However the Servlet spec is the bedrock of so many things, seeing that disrupted could cause real issues.

Just my opinion anyway.

It's all about opinions

[Jeroen Wenting]

To make life easier! We're not talking about a full blown language here, we're talking about extending the EL to have something like a forEach construct to iterate over collections. That has to be easier than writing Java code.
Each language has it's place. Java is great for the business and control logic, but it does not work well as a scripting language!

You already have an excellent such construct using the c:forEach tag from JSTL.
Java may be pretty powerful for scripting but noone says you have to use all of it.

[Frank Carver]

Kevin Jones wrote: we're talking about extending the EL to have something like a forEach construct to iterate over collections.
I can see where you are coming from. It's just that, in my experience, even a supposedly simple construct such as this disturbs the nature of the psuedo-HTML of JSP so much that it becomes a programming task rather than a page design task.
I remember waves and waves of discussions about this very issue during the early development of WebMacro (the syntax from which was "borrowed" and tweaked to become Velocity). Whatever syntax you choose for such an "iterate" operation, you will probably need at least:

some way of indicating what you are iterating over

something to hold/represent the "loop variable" (may be implicit)

something to indicate where the repeated bit starts

an arbitrary amount of page content and EL/tags/scriptlets etc.

something to indicate where the repeated bit ends

The obvious options for this seem to be:

something like XML/HTML (the style used by JSTL, FreeMarker etc.)

something like content, orthogonal to XML (the style used by EL expressions, WebMacro/Velocity etc.)

something that's a strange mixture of both (traditional scriptlet markup)

None of these work well with HTML editors, especially graphical ones. The current use of EL/WM/Vel expressions is the least intrusive. JSTL, FreeMarker and traditional scriptlets need customised editors to even make sense of the pages.
As far as I can tell, adding iteration to a page is a programming task, and will need special training of web designers and special tool support whatever language or syntax is used
Now to the question of whether the EL should be extended to include such operations. The EL as it stands is nicely self-contained: parse from ${ to }, process the contents, forget it and move on. If you add some sort of operation which allows arbitrary chunks of page between EL "bookends", you need to maintain state, potentially recursively, allow for the possibility of incomplete closure of nested elements, maybe deal with exceptions thrown by intermediate code, or page redirects inside loops, etc. etc.
My personal feeling is that Java scriptlets, especially the XML scriptlet syntax, and the simpler Java 1.5 foreach are quite a compact way of expressing such things, as is the JSTL foreach.
As for the question of whether Java scriptlets are too complex for such things, I'd just note that the complexity (and power) of Java need only be there if it's needed by the application. I don't see much difference between asking a web designer to use
Conventional scriptlets (a la 1.5)

<% for (line : invoice) {%>
blah blah ${line}
<%}%>

XML scriptlets

<jsp:scriptlet>for (line : invoice) {</jsp:scriptlet>
blah blah ${line}
<jsp:scriptlet>}</jsp:scriptlet>

JSTL

<c:foreach var='line' items='${invoice}'>
blah blah ${line}
</c:foreach>

or some invented EL-like syntax

${foreach line in invoice}
blah blah ${line}
${end}

None of them are much like HTML, and once a page designer has seen it, it's just boilerplate.
To my mind the advantage with using regular Java is that if more complexity is needed (a) the power of the language is there now, without waiting for several version releases to slowly extend a new "scripting" language, or needing to use ugly "back doors" to real Java (b)full-fat Java can be used as scriptlets while prototyping, then simply and mechanicaily migrated out to tags or beans for delivery and/or reuse.
Have you ever tried to convert a PHP application to JSP/Servlets? The languages have a similar expressive power, but they are sufficiently different that converting is laborious and fiddly. I'd hate to see a similar level of compexity creep in for the common process of refactoring in-page JSP scripting out to other server-side Java objects.
Any way, thanks for such an interesting topic of discussion

[Gregg Bolinger]

In general I agree with you, however the fact that we need JSTL points to the conclusion that we need more control in the page. And I would guess that the most common JSTL tags are c:if and c:forEach, which points to the conclusion that we're missing something in the EL. I would never argue that we should put model level logic in the page. But we do need some display level logic (again, otherwise we wouldn't need c:forEach). The aim should be to make life easy for page authors, JSTL makes it easier but we could bo better
Jeroen and Frank pretty much responded for me and I tend to agree with them. Frank made some very good points. Suffice it to say, they responded for me.