Putting Java into HTML is a solution for two issues:
1 Not all HTML page designers know Java
App developers know Java. Web page designers know HTML. With JSP, Java developers can do Java, and HTML developers can do web pages.
2 Formatting HTML into a String literal is REALLY ugly
Putting even marginally complex HTML into the argument to a println() is a compiler error waiting to happen. You might have to do a ton of work to get the HTML formatted properly in a way that still works in the client’s browser, yet satisfies Java rules for what’s allowed in a String literal. You can’t have carriage returns, for example, yet most of the HTML you’ll pull from a web page editor will have real carriage returns in the source. Quotes can be a problem too—a lot of HTML tags use quotes around attribute values, for example. And you know what happens when the compiler sees a double quote... it thinks, “This must be the end of the String literal.” Sure, you can go back and replace each of your double quotes with escape codes... but it all gets insanely error prone.
Q: Wait... there’s still something wrong here! Benefit number one says “Not all page designers know Java...” but the HTML page designer still has to write Java inside the JSP page!! JSP lets the Java programmer off the hook for writing HTML, but it doesn’t really help the HTML designer. It might be easier to write HTML in a JSP rather than in a println(), but the HTML developer still has to know Java.
A: Looks that way, doesn’t it? But with the new JSP spec, and by following best practices, the page designer should be putting very little (or no) real Java into a JSP. They do have to learn something... but it’s more like putting in labels that call real Java methods rather than embedding the actual Java code into the page itself. They have to learn JSP syntax, but not the Java language.