This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes JSP and the fly likes Scriptlet vs JSTL Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » JSP
Bookmark "Scriptlet vs JSTL" Watch "Scriptlet vs JSTL" New topic
Author

Scriptlet vs JSTL

Ritika Misra
Ranch Hand

Joined: Jun 17, 2009
Posts: 30
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

Java Dev User
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61318
    
  66

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

Performance is a non-issue in the choice.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Samuel Behrman
Ranch Hand

Joined: Oct 02, 2009
Posts: 49
Please refer to the url below:
http://www.informit.com/articles/article.aspx?p=30334


RAQ Report: Web-based Excel-like Java reporting tool.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18570
    
    8

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
Ranch Hand

Joined: Apr 08, 2009
Posts: 298
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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61318
    
  66

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
Ranch Hand

Joined: May 07, 2008
Posts: 126
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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61318
    
  66

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
Ranch Hand

Joined: May 07, 2008
Posts: 126
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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61318
    
  66

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
Ranch Hand

Joined: Nov 12, 2009
Posts: 110
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 ...........


To err is human,
To forgive is not company policy
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61318
    
  66

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
Bartender

Joined: Oct 14, 2005
Posts: 18570
    
    8

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
Ranch Hand

Joined: Mar 04, 2009
Posts: 417
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
Ranch Hand

Joined: Oct 16, 2008
Posts: 952
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.


SCJP 6
Leandro Coutinho
Ranch Hand

Joined: Mar 04, 2009
Posts: 417
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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61318
    
  66

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
Ranch Hand

Joined: Mar 04, 2009
Posts: 417
Also the error java.lang.OutOfMemoryError: PermGen space is caused after some hot deploys.
At least with me. =) I use Tomcat.
Robert Emminger
Greenhorn

Joined: Jun 08, 2012
Posts: 1
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
Greenhorn

Joined: Sep 07, 2010
Posts: 3
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?
 
GeeCON Prague 2014
 
subject: Scriptlet vs JSTL