This week's book giveaway is in the Performance forum.
We're giving away four copies of The Java Performance Companion and have Charlie Hunt, Monica Beckwith, Poonam Parhar, & Bengt Rutisson on-line!
See this thread for details.
Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Code In JSP: When will it stop

 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So when JSP first came out, writing code was probably somewhat accepted and a general practice. MVC was probably not an accepted term at the time and, well, PHP was doing it, so to speak.

Then J2EE 1.4 came out with the new JSP spec and, still, code is allowed in a JSP, albeit for backwards compatability.

But the industry states this is not acceptable or it is bad design because it does not follow MVC. At what point does Sun remove the ability to write java code in a JSP? Will they ever? People have talked about at some point Sun is going to have to say, screw backwards compatability with J2SE and fix all the problems that they can't touch right now. Is this something that will happen with J2EE as well? How soon? How long?

Just wanted some other thoughts on this.
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
While I agree that for a site of any size, JSP tags are better than embedded code, for someone just putting together their own site, it's easier to get started using embedded code. Get rid of that capability, and you shut out some newbies.

In addition, it would mean that anyone that has an existing site that depends on embedded code - perhaps because it was written early on - has to put in a lot of effort to port it if they are going to upgrade. If I were in that position, I'd probably lean towards switching to a platform other than Java that was more concerned about backward compatibility, so I wouldn't have to go through the whole painful process again later.

I don't see the problem with maintaining backward compatibility. No one is forced to use the old features on new code if they don't want to.
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
shutting out newbies shouldn't be a reason, newbies should start out using JSTL straight away.

backwards compatibility with existing code is a valid point. IMO depricating the entire scriptlet stuff would be a way to deal with that.
It acts as a deterrent towards use while not preventing it.
A few versions (say 2) down the line it can then be removed entirely, giving people enough time to either modify or retire applications using the deprecated API (this I advocate for all deprecated code).
 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeroen Wenting:
shutting out newbies shouldn't be a reason, newbies should start out using JSTL straight away.

backwards compatibility with existing code is a valid point. IMO depricating the entire scriptlet stuff would be a way to deal with that.
It acts as a deterrent towards use while not preventing it.
A few versions (say 2) down the line it can then be removed entirely, giving people enough time to either modify or retire applications using the deprecated API (this I advocate for all deprecated code).


I tend to agree with this. And companies don't have to upgrade if they don't want to upgrade their current appliction(s). But hopefully new features and better code would persuade them to anyway.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic