Scriptlet vs JSTL

[Ritika Misra]

Hello ranchers

Can any one tell me performace wise which is better Scriptlet or jstl???
As we are doing a net banking applciation,wanted to because i need to customize the code so that it takes lesser time to load.
Which would be better......

Also is there any possiblity to reuse jstl tags ???

Thanks in advance...

Java Dev User

[Bear Bibeault]

Please search the forum, this has been covered many time in the past.

Performance is a non-issue in the choice.

[Samuel Behrman]

Please refer to the url below:
http://www.informit.com/articles/article.aspx?p=30334

[Paul Clapham]

That article doesn't cover performance much (and that was the original question) but in any case things written seven years ago about performance are long obsolete.

Also, a better comparison would be between scriptlets in a JSP and the same code in a servlet. I don't think you would find much difference in performance there, since it's the same code running.

[Albareto McKenzie]

Bear Bibeault wrote:Please search the forum, this has been covered many time in the past.

Performance is a non-issue in the choice.

I guess there is no choice. Why to use obsolete technology in a new application?

[Bear Bibeault]

The fact that a 7-year-old article says that it's time to move on is telling. It's 2009! The original question shouldn't even be asked at this point.

Scriptlets are out-dated and discredited. It's well past the time to stop writing code like it's 2002.

[Nick Potter]

Bear Bibeault wrote:The fact that a 7-year-old article says that it's time to move on is telling. It's 2009! The original question shouldn't even be asked at this point.

Scriptlets are out-dated and discredited. It's well past the time to stop writing code like it's 2002.

You'd be amazed on how many projects still use scriptlets, and i'm not talking about projects started 7 years ago... As long as the project description says technologies used: servlets & jsp (no matter if it's + ejb or not), there's scriptlets and usually a few servlets (for other content types or to act as a filter-wannabe implemented as a very bad front controller).

[Bear Bibeault]

Nick Potter wrote:You'd be amazed on how many projects still use scriptlets, and i'm not talking about projects started 7 years ago...

Actually, no I wouldn't. It's quite evident that many developers still think it's 2002. So while I wouldn't be amazed at the number of projects using discredited technology, I am amazed and saddened that developers don't know any better, or simply don't care.

[Nick Potter]

Bear Bibeault wrote:

Nick Potter wrote:You'd be amazed on how many projects still use scriptlets, and i'm not talking about projects started 7 years ago...

Actually, no I wouldn't. It's quite evident that many developers still think it's 2002. So while I wouldn't be amazed at the number of projects using discredited technology, I am amazed and saddened that developers don't know any better, or simply don't care.

A real example, it happened not a long time ago... the deployers (which were client employees) specifically requested no new jars or else the project will be refused. How stupid is that?
Before i started working as a developer, i didn't have any real experience with scriptlets, I used them to understand better the technology, but on school projects, I only used JSTL. But recently i had to learn to use scriptlets. So, it's not really about developers not knowing any better or not caring, it's more about them having no other choice but not to care.

[Bear Bibeault]

Ah yes, the Mauve Database Syndrome.

Stupid decisions handed down from above are also a factor. (Like the ill-informed project leads who prohibit the use of the session )

"Against stupidity, the gods themselves contend in vain."

[PrasannaKumar Sathiyanantham]

please never scriptlets and use jstl onyl

the main reasons are that

the web developers who design a page which will be viewed by the user will not be proficient in java ..... jstl is much easier to under stand and hence it is the obvious choice...

the other reason said by my teacher is that the scriptlets that one uses in a jsp(jsp are converted to servlets before execution) takes a extra time ...........

[Bear Bibeault]

While I (obviously) agree with your sentiment, I'm not so sure about your reasons.

PrasannaKumar Sathiyanantham wrote:the web developers who design a page which will be viewed by the user will not be proficient in java ....

While that could be a factor in some shops, I think this level of hard separation between designers and developers is actually rather rare. More often, the developlers are responsible for many levels of the application. And, just because on might be savvy in Java is still not any excuse for using scriptlets. Regardless of whether the page developer is Java-knowledgable or not, JSTL/EL gives all the benefits of making pages easier to create, eaier to maintain, easier to extend, easier to test, easier to reuse, and so on...

the other reason said by my teacher is that the scriptlets that one uses in a jsp(jsp are converted to servlets before execution) takes a extra time ...........

Performance is not an issue. JSTL/EL needs up-front evaluation as well. But even if there were a performance difference, it would be negligible and not a factor.

[Paul Clapham]

I haven't heard anybody say this out loud, but here's another thing I suspect drives people to prefer JSPs to servlets: if there's a bug in your JSP, you just fix the bug and zap the new version directly into your server. It gets automatically recompiled and the next request gets the fixed version and everything's good. Whereas if there's a bug in your servlet, after you fix the bug you have to go through a more complicated redeployment process. A cynical person would suggest that redeploying is a bad thing because more people know about it when it happens, drawing attention to your errors.

[Leandro Coutinho]

Paul Clapham wrote:I haven't heard anybody say this out loud, but here's another thing I suspect drives people to prefer JSPs to servlets: if there's a bug in your JSP, you just fix the bug and zap the new version directly into your server. It gets automatically recompiled and the next request gets the fixed version and everything's good. Whereas if there's a bug in your servlet, after you fix the bug you have to go through a more complicated redeployment process. A cynical person would suggest that redeploying is a bad thing because more people know about it when it happens, drawing attention to your errors.

This is true when you are developing, but when you deploy the application, you'll deploy the war file. So even a change in a JSP file, will require the redeploying, right? Please, correct me if I am wrong.

[Punit Singh]

This is true when you are developing, but when you deploy the application, you'll deploy the war file. So even a change in a JSP file, will require the redeploying, right? Please, correct me if I am wrong.

No, no need to redeploy, not even need to restart your web container, just replace your jsp within extracted war file.

[Leandro Coutinho]

Punit Singh wrote:

This is true when you are developing, but when you deploy the application, you'll deploy the war file. So even a change in a JSP file, will require the redeploying, right? Please, correct me if I am wrong.

No, no need to redeploy, not even need to restart your web container, just replace your jsp within extracted war file.

Thank you Punit!

[Bear Bibeault]

The point seems to be being missed. Putting inappropriate content in a JSP just to enable "hot deploy" is not a valid reason to violate best practices!

[Leandro Coutinho]

Also the error java.lang.OutOfMemoryError: PermGen space is caused after some hot deploys.
At least with me. =) I use Tomcat.

[Robert Emminger]

I am rather sick of the lack of respect to senior knowledge against Scriptlets (designers, UI Developers, etc) and there are some very serious issues in using them depending how deep you go (NIH use to have their JDBC on a scriptlet before me, had to reboot the server three times a day). Here the small list

Scriptlets can give birth to run-a-way threads that will eventually hang (JDBC example given).

YOU CANNOT UNIT TEST SCRIPTLETS! For this one I will give the same threat my old boss at ACBL gave. If I catch you writting srciptlets there will be one less bad developer in the world. That is a good thing.

Security risk of someone is able to grab the jsp before it processed, and YES YOU CAN GET HACKED, SOURCE CODE IN PRODUCTION CODE IS LIKE A "WELCOME, EAT MY COMPANY" sign.

Ajaxing scriptlets is akin to a free headache and again giving away the structure of your app.

I won't even go into debugging jsp, jspf, and the alike with scriptlets.

YOU CAN'T EXTEND OR INTERFACE TO A SCRIPTLET. (If you disagree, go back to college and take programming and design, this time actually study. This isn't theory , it fact.)


I can go on and on dropping fact-bombs all over this subject but this should have smashed, crushed, and utterly obliterated the support for scriptlets. If not I am not only requesting you to take a degree in computer engineering or science, but the profs who taught those scriptlet supporters if any classes taken to go back to go back to school as well.

The Dracorn has spoken. Grad at University of Memphis, 15 years exp in Java/JavaEE development.

P.S Adding support for JSTL simply put JSTL is simply for UI creation and display placing limits to what can be done yet a clean working tool set to interact JS and html with session vars on the 'V'iew of MVC.

[B Stapleton]

Security risk of someone is able to grab the jsp before it processed

I've heard people mention this, but I've never found out how to do it. I'd like to do a demo for my company to show them why JSPs outside of the WEB-INF folder is a security risk.
Do you know how to do this?