This is completely unnecessary limitation in the current JSP spec. Tag files are the only real way to define reusable and composable units. The tag file itself can have scriptlets, but as soon as you move that scriptlet inside the body of a tag used by that tag file, you get into trouble.
The workaround is to either buffer the scriptlet output into a variable, or use JSTL and EL instead. But the latter approach has a huge impact on performance.
Here's a sample snippet that prints out the system properties map, first without and then with scriptlets:
I've tested this out on a Mac with tomcat, and the scriptlet approach is consistently 20 times faster than the non-scriptlet version. I'm guessing it only gets worse as the complexity goes up (nested loops, etc.).
But the latter approach has a huge impact on performance.
I've been using JSTL and EL since they were introduced in 2002 and have never detected any perceptible performance issues. Even if it is consistently "20 times" slower, if it's not detectable, it's moot. I've been using JSTL and EL since it was introduced in 2002 without any demonstrable performance issues. Such micro-tuning is almost always imperceptible among the network activities that are much much slower.
I'm guessing it only gets worse as the complexity goes up (nested loops, etc.).
I'm guessing it's irrelevant in the face of other latencies. I've written many highly complex JSP pages employed in high-volume (banking) web sites (to the tune of thousands of transactions per minute) and never run into perceptible performance issues that weren't networking or database bottlenecks.
But, the bottom line is that if you want to use JSP 1 scriptlets with tags, you'll need to use the JSP 1 classic tag handlers with which they are compatible.
My advice, though, is to avoid premature optimization and address performance issues when, and if, they actually become detectable problems.
Thomas Hudson wrote:The fact that it is significantly slower is just one of many issues.
I'll disagree that it's an issue at all.
If you follow that line of thinking to its logical conclusion, we'd all still be using the command line for everything because "them durn graphics" have higher performance requirements.
Suppose I want to change the code to: ... snip ... Doing that check with more JSTL tags and EL would be silly.
I'm not seeing the silliness. It'd be very straight-forward and much cleaner in my opinion.
One of the selling points of JSP is to have quick access to the java language.
That may have been thought to be true when JSP was introduced in 1998, but the folly of that approach is well understood. That's why scriptlets were replaced with JSTL/EL in JSP 2.
"Quick access" to Java got a lot of developers in a lot of trouble, and resulted in a lot of untestable and unmaintainable code. It took a lot of discipline, which most developers do not possess, to keep JSP pages in check and following proper separation of concerns.
My point was that this limitation in the spec seems completely unnecessary.
It may seem so, but I recall reading about the new tag handling mechanism when JSP 2 first came out and remember that the no-scriptlet proscription for the JSP 2 tag handlers had a very justifiable reasoning behind it. But it's been so long that I cannot remember the details off the top of my head. It had to do with how JSP fragments are processed, if I recall.
It seems like someones misguided attempt to force JSTL and EL down the throats of developers.
No forcing. All the JSP 1 stuff is still there. You just can't mix-and-match some of the JSP 1 mechanisms with newer JSP 2 stuff. Seems like a perfectly reasonable approach to me. If you want to use JSP 1, no one is stopping you.
You are, of course, free to dislike JSTL and EL for any number of reasons. But you probably won't find much commiseration here, especially among people who have been using JSP for a long time. I've personally found that using JSTL and EL, along with proper separation of concerns, to be a godsend over the "bad old" JSP 1 days ( and before -- I started using JSP with version 0.92, and before that, used JHTML).
At this point I guess I have to ask the point of your topic. You don't seem to be here for advice, and you haven't really asked any questions.