I'd recommend Velocity instead. It's also quite old and stable, and takes care of the above mentioned issues - https://en.wikipedia.org/wiki/Apache_Velocity
More than 10 years ago most large companies were reliant upon JSP. The problem is that it forces front end concerns onto an army of developers who hated doing absolutely any work that was not 100% Java and you got a really expensive product of really shitty quality.
The excessive cost and low quality output were not directly caused by JSP, which was/is an excellent technology. This is a people problem (and verbose Java problem).
Over the last decade many of those companies have gone through a process called UI separation to purge JSP and forcefully separate Java from the front end. The primary concerns (self-inflicted injuries):
* Slow iteration. The UI that appears in the browser was almost never updated. I remember business leaders having fantastic ideas about improving the website and everything was fully mocked and documented. It never happened. The Java monorepo is where ideas go to die. It’s too verbose, too large, and many of the people writing in it were horrible. They really really didn’t want to dick around with front end logic that they didn’t really understand or appreciate in the first place. Any UI code that made it out was a miraculous blessing that was there forever.
* Law suits over accessibility. Since the UI was shitty AND never updated it only just barely worked for common users and only sometimes worked cross browser. As a result setting any competent expectations was a lost cause and these law suits were almost certainly a class-action win for the plaintiffs if they didn’t lose out to regulation first.
* Law suits over security. Security on the web was largely a lost cause and thought of as an unnecessary expense. The only reason to consider security was to avoid embarrassment, but otherwise it was entirely the users problem. Then credit card companies stated they would stop processing transactions from sites that failed the most embarrassing of security problems according to their PCI specification. Security was only lightly concerned with the front end, but still required updates that would never come.
As a parallel look up Google WebToolkit. This was a utility that compiled Java into JavaScript so that Java developers could produce something they never wanted to understand. What could possibly go wrong? Everything was fire and forget because the output was highly optimized obfuscation. Most of the time the Java developers had no idea what they were doing with their input and the output was completely indecipherable, so any changes meant a complete rewrite and throwing away large blocks of code without consideration for testing. Again, what could possibly go wrong?
And of course, who does'nt love a programming paradigm with simple diagrams and example code in COBOL? You can't beat it.
https://en.wikipedia.org/wiki/Jackson_structured_programming
Sarcasm aside, I guess you are talking about Java|Jakarta Server Pages, I think those are deprecated, so I recommend against using this in new projects. However, no one is really going to stop you, but keep in mind that deprecated almost always means 'not going to be around many years from now', so that depends on the time frame of your project.