aspose file tools*
The moose likes JSP and the fly likes JSP in Future / Future of JSP Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » JSP
Bookmark "JSP in Future / Future of JSP" Watch "JSP in Future / Future of JSP" New topic
Author

JSP in Future / Future of JSP

Prakash Dwivedi
Ranch Hand

Joined: Sep 28, 2002
Posts: 452
Hello Mr. Hans Bergsten,
Beacuse of struts and other frameworks, writing java code in the JSP page has been reduced. Developers prefer to follow MVC architecture, and also use of tags is preferred over writing methods or scriplets in the JSP Page. This is not what Sun have thought when the introduced JSP (i,e, scriplets / methods being ignored)

With the type of usage changing what new future do you expect will be or should be introduced in JSP in coming years. For last couple of years many new tag library has been added to JSP. Has we reached a level where no further improvement can be done and only work will be done in building new tags?


Prakash Dwivedi (SCJP2, SCWCD, SCBCD)
"Failure is not when you fall down, Its only when you don't get up again"
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Prakash,
I feel that JSP is matured now. The main purpose was division of labor where the web developers who are not familiar with Java can develop JSP, this would mean no scriptlets.
The previous version did not achieve the same but the JSP 2.0 version brought in JSTL, EL etc where there is zero Java code.


Groovy
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Has we reached a level where no further improvement can be done and only work will be done in building new tags?

Tags are the best way of bringing in new feature, rather than introducing something that is completely new.

I am sure that Mr. Hans Bergsten will have better answer for your question.
Prakash Dwivedi
Ranch Hand

Joined: Sep 28, 2002
Posts: 452
Tags are the best way of bringing in new feature, rather than introducing something that is completely new.
As JSP is now very often used to listen client request directly, will Sun introduce some new type of JSP.
I am asking this because when EJBs were introduced they were purely distributable that is listening only remote calls, later it was observed that in most of the cases developers were calling EJBs from local machine only, hence concept of local interfaces were introduced. Will we have some JSPs in future which may not be capable of listening Http requests at all or some other changes like that.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Will we have some JSPs in future which may not be capable of listening Http requests at all or some other changes like that.

I dont see this happening. JSP are for generating dynamic web content,if they cannot be invoked using HTTP protocol I am not sure where else they could be used.
:roll:
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Pradeep Bhat:
I dont see this happening. JSP are for generating dynamic web content,if they cannot be invoked using HTTP protocol I am not sure where else they could be used.
As a templating mechanism. As someone already mentioned, few moderately sized applications expose JSPs as the "first point of contact", i.e. receiving HTTP requests directly. Mostly it's the servlet who does that and the JSP is only delegated to for view rendering.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8919

Mostly it's the servlet who does that and the JSP is only delegated to for view rendering.

True but what is the advantage if JSP cannot be invoked via HTTP ? What I mean ..If they are just used as templates (with no HTTP enablement) are we gaining anything other than may be enforce MVC ?
[ March 11, 2004: Message edited by: Pradeep Bhat ]
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
This is also the concept of MVC. The Servlet mainly handles the requests, see which JSP should be used, and what data is needed from the DB.
Struts doing the same thing as well. But of course, usually, the entry point of the Web-based system should be a JSP, and after that, all goes to Servlets.
Nick


SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Hans Bergsten
Author
Ranch Hand

Joined: Dec 01, 2003
Posts: 106
Originally posted by Prakash Dwivedi:
Hello Mr. Hans Bergsten,
Beacuse of struts and other frameworks, writing java code in the JSP page has been reduced. Developers prefer to follow MVC architecture, and also use of tags is preferred over writing methods or scriplets in the JSP Page. This is not what Sun have thought when the introduced JSP (i,e, scriplets / methods being ignored)

With the type of usage changing what new future do you expect will be or should be introduced in JSP in coming years. For last couple of years many new tag library has been added to JSP. Has we reached a level where no further improvement can be done and only work will be done in building new tags?

I could swear I answered a similar question about likely JSP features for future revs of the spec yesterday, but I can't find it. Am I being censored?
Anyway, first let me correct to misconceptions:
1) JSP, and all other Java specifications, are developed by representatives from many companies, not by Sun. See http://jcp.org/ for details.
2) Tag libraries were part of the plan from day 1 but were not formally introduced until JSP 1.1 due to release plan deadlines. SCriptlets have never been encouraged, but they were hard to avoid until JSTL 1.0 and the EL were introduced.
Regarding what the future holds, JSP is more or less done IMHO. The only core changes I think may be desireable at this point are related to the EL API and possibly adding some hooks for better integration with JSF,
The EL should ideally be moved to a separate specification to make it easier for other technologies besides JSP to use it (JSF is one example) and to allow it to evolve independently. It should also be tweaked a bit to make it a bit more generic and "type declarations" should be added to allow for better design-time error detection.
I know that some people want to make JSP useable as a generic "template processor" outside of HTTP, e.g., for generation of mails and resports. I disagree, because I think too generic solutions end up being harder to use. A better approach would be to break out other parts besides the EL that can be used for other technologies, but keep JSP focused on generating HTTP responses.


Hans Bergsten, hans@gefionsoftware.com<br />Author of O'Reilly's<br />- JavaServer Pages,<br />- JavaServer Faces<br /><a href="http://www.hansbergsten.com/" target="_blank" rel="nofollow">http://www.hansbergsten.com/</a>
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
yes, you did answer the same yesterday
I agree that decoupling JSP from HTTP would be overkill. There's enough templating engines out there already...


42
Prakash Dwivedi
Ranch Hand

Joined: Sep 28, 2002
Posts: 452
Thanks Mr Bergsten for such a nice explaination. But i have few queries
The only core changes I think may be desireable at this point are related to the EL API and possibly adding some hooks for better integration with JSF,
Won't this be unfair to other frameworks like struts :roll:
I know that some people want to make JSP useable as a generic "template processor" outside of HTTP, e.g., for generation of mails and resports. I disagree, because I think too generic solutions end up being harder to use.
I fully agree that this could be harder to use, but won't it be better if we have both the version at the same time. That is this new change comes as an add on and not as a replacement. So that the developers can choose which is best for him.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Prakash Dwivedi:
Won't this be unfair to other frameworks like struts

Why would we be bothered about unfairness? This isn't a competition and the Struts developers are not selling Struts for a living.
Originally posted by Prakash Dwivedi:
I fully agree that [JSP as a generic template engine] could be harder to use, but won't it be better if we have both the version at the same time. That is this new change comes as an add on and not as a replacement. So that the developers can choose which is best for him.

But we do have both at the same time. JSP for page-oriented templating and Jakarta Velocity for the generic stuff. I don't see a real need for including Velocity into the JSP specification...
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61761
    
  67

Am I being censored?

Hmmm, certainly not by me -- and I can't imagine any of the sheriffs doing so. And I do recall the post. If I get a chance in a little bit I'll see if I can track it down.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
Because we always wanna things become better, that's why we try to find out more and more interesting things, like Struts, JSF, etc.
In the way of a standardization for JSPs, writing JSPs become more and more complicated. But IDE sometimes may life easier, like JBuilder, can already convert non-advanced JSPs into Struts tag format.
Nick
Hans Bergsten
Author
Ranch Hand

Joined: Dec 01, 2003
Posts: 106
Originally posted by Prakash Dwivedi:
Thanks Mr Bergsten for such a nice explaination. But i have few queries
The only core changes I think may be desireable at this point are related to the EL API and possibly adding some hooks for better integration with JSF,
Won't this be unfair to other frameworks like struts :roll:
I know that some people want to make JSP useable as a generic "template processor" outside of HTTP, e.g., for generation of mails and resports. I disagree, because I think too generic solutions end up being harder to use.
I fully agree that this could be harder to use, but won't it be better if we have both the version at the same time. That is this new change comes as an add on and not as a replacement. So that the developers can choose which is best for him.

When I say "hooks for better integration with JSF", I mean looking at what frameworks like JSF needs in order to integrate better with JSP and making the hooks generic and public. Other similar framworks can also use them if needed, so there's nothing unfair about it. I hope everyone realize the difference between a specification developed through the JCP where pretty much anyone can participate and the resulting complete API is public, and a proprietary published API where some methods are kept secret and used only by the vendor for better integration of its own products.
Regarding generic specifications, I'm all for generic components that can be used to build focused "frameworks" or products. To me, JSP is a framework that should stay focused on generating response to HTTP requests, otherwise it just get harder to use. But if there are pieces of JSP that would be usedful for a separate "template engine" specification to use, by all means, they should be decoupled from JSP so that they can be reused. The EL is one example, but there may be others. All I'm saying is that I don't believe in having one "framework" for doing everything; I rather see many "frameworks" for specific purposes, built from a common pool of components.
Hans Bergsten
Author
Ranch Hand

Joined: Dec 01, 2003
Posts: 106
Originally posted by Bear Bibeault:

Hmmm, certainly not by me -- and I can't imagine any of the sheriffs doing so. And I do recall the post. If I get a chance in a little bit I'll see if I can track it down.

I was kidding, of course. But thanks for looking into it.
Kishore Dandu
Ranch Hand

Joined: Jul 10, 2001
Posts: 1934
Future is a combination of JSF, Struts and JSP.
Go J2EE go
Kishore.


Kishore
SCJP, blog
Warren Dew
blacksmith
Ranch Hand

Joined: Mar 04, 2004
Posts: 1332
    
    2
Originally posted by Hans Bergsten:
To me, JSP is a framework that should stay focused on generating response to HTTP requests, otherwise it just get harder to use.

Hear, hear!
I haven't worked on a JSP project since the bubble, but I have to say that project - which was abandoned when the initial budget ran out - might well have been completed within that budget had we had JSTL available to ease the interaction between the programmers and the HTML folks, and possibly the workflow aspects of Struts. As best I can tell without reading your book (which Amazon says isn't available yet), the workflow benefits of Struts aren't duplicated by JSTL or JSF; it's just the tag library functionality that may overlap, which I don't see as a problem.
Then again, I haven't actually used anything other than scriptlets, so I'd be interested in hearing from people with practical experience with the more recent technologies.
I would say that it appears to me there's one weakness in all of these newer technologies (JSTL, JSF, and Struts) - they don't seem to me to interact well with client side scripting. Okay, I know client side scripting is evil, but it does allow the creation of nice UI features that depend on faster response than a page reload can provide ... after using the cool little airline seat selection windows on those web travel agency sites, I found it a lot harder to stonewall client feature requests that could only really be implemented using Javascript/ECMAscript. Am I missing something here?
Warren
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JSP in Future / Future of JSP