0

My question is based on a business model of a financial services organization that currently is supporting applications that are a hybrid mix of Classic ASP and Java, with some JSP’s already in some of the applications.

Specifically, in our large application, all of the FE starts with ASP and then uses a crude request based token that is used by other code to determine which JSP to call. In the other application, which is a suite of four linked applications, the main application and one other use all ASP in the front end and java code for the BE. The two others that are linked to it use JSPs and java code exclusively.

Due to excessive maintenance costs of using this hybrid system and concerns for using obsolete technology, management has bought into modernizing our applications to all Java and removing all ASPs on these applications. I'm on a panel group that would have to propose which Java UI to use as each UI technology has its own set of strengths and weaknesses.

Making the assumption that the following item makes up our basic use case: modernizing our current classic ASP UI to a Java standard, which incorporates the following goals:

  • In general, a system that is more amenable to change.
  • That would be flexible for future growth based on technology changes in the market.
  • Not tied to a niche market or something experimental or unstable or cutting edge.
  • More modularized code that would allow the UI to be converted to another technology, if the business need arises. This would coincide with the code structure and not just the technology, but I felt it was worth mentioning.
  • Better performance.
  • Stable and scalable.
  • More secure than classic ASP.
  • Better ROI on development time. It's been hard finding people with Classic ASP that also know Java well. Also, this would also have to incorporate the learning curve for new developers as I've heard JSF has a steep one.

Now, to the point, with the number of java UI frameworks that I’m aware of: JSP, JSF, JavaFx, Tapestry, Vaadin, GWT, Velocity, Freemarker, and Thymeleaf, based on actual experience from other developers that have actually had to do this type of conversion what have you used to do this?

Do you have any lessons learned that would coincide with this use case and business model? I don't want opinions, but answers from real life experiences.

Currently, we are being asked to limit ourselves to just JSP or JSF, but I'm not so sure those should be the only alternatives. Currently, the talk is to move everything to one or the other as another team is going down the JSF route. We are wanting to adopt a standard for everyone however. So overall, we have some infrastructure for JSF, but it's heavily favored for JSP at this time.

Improve this question
2
  • I have zero experience with JSP or JSF, but if you already have an infrastructure written in them, and developers on staff having experience with them, the decision seems self-evident, unless you're planning to move everything to JavaFX.
    – Robert Harvey
    Commented Jan 16, 2015 at 15:25
  • My concern was that JSP's were considered deprecated, however, now I realize that is only in reference to JSF. I don't believe it's a universal deprecation and yes I personally am favoring JSP's in our situation. I just want to be open to viable options that others have already used. One last item: the talk is should we move everything to JSF, so yes it's on the table.
    – user39741
    Commented Jan 16, 2015 at 15:38

2 Answers 2

Reset to default
2

If you've already used JSP in part of your application, don't rewrite it into a different framework. Chances are, the team you're working with already has some knowledge of JSP, and you'll be able to build on the existing core of pages that utilize it, limiting the amount of work to be done and the subsequent number of bugs needing squashed.

Remember your Joel on Software: never rewrite from scratch.

Improve this answer
2
  • 1
    +1. There's nothing wrong with JSP as long as it is used appropriately (i.e. as a view renderer called from some kind of MVC/MVP style code, rather than directly accepting and processing requests in .jsp files). Note that embedding Java code directly into a JSP file is considered deprecated, and in my opinion so should the "useBean" tag be.
    – Jules
    Commented Jan 16, 2015 at 19:34
  • After reviewing this, I would have to agree this is the obvious choice. Sometimes I get lost in the details, but bottom line JSP's are the correct choice here. If another team has a specific use case for JSF, then they can present it, but it doesn't seem to be a good fit overall for us.
    – user39741
    Commented Jan 16, 2015 at 22:35
0

After more research I concurred with our group that for this particular application, some form of JSP technology was the correct answer. These were some of the main points:

  • ASP to JSP is not a huge paradigm shift and are someone similar in my opinion. I read that JSP's came from the ASP concept originally.
  • JSF has a steep learning curve and it's hard to find devs with that expertise.
  • JSF abstracts away HTML, CSS, and HTTP from the devs and is a departure from all the modern web apps I've worked with. Therefore, if you decide later to move to something else, it's a rewrite.
  • As stated before, JSP is already in the app, about 50% of the pages approximately, so the technology is already there and it's maintained by experienced devs that have been on the app for years.

To mitigate risk and to keep costs lower, JSP's are the right choice for us. Now we are deciding on what we are going to use along with it, like Spring MVC or Struts2.

I found this official link for a listing of technologies in Java EE 7. JSP is still listed there and is still in JSR 366 for Java EE 8, so JSP's are not truely deprecated overall. What else was important to me was that JSTL and EL are also supported in Java 7 & 8.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.