Why does the constant exist in the first place? My question would not be how to reference the constant from the JSP, but how to get rid of it in the first place.
Do you mean, use a context init param instead? I think the reason it was done this way was to enable reading in all these settings via a Properties object and then populating the bean properties. I'm not quite following you.
Costs matter. Justice lies in processes not outcomes. Crime is caused by criminals.
My question is simple: what is the purpose of the constants in the Constant class?
It's not all clear from what you're posting, and I'm having a hard time not seeing a huge anti-pattern red flag waving.
If the answer is: to provide run-time flags, then a constant class is a huge anti-pattern. Use a properties file. Easily read by a context listener and stored as a Map in app context where the EL can easily access it.
OK, I more or less understand. I've been looking at this code and trying to understand why we need a class at all if it's just a big wrapper for a Properties object, and I could not come up with anything. This code was done a long time ago.
Costs matter. Justice lies in processes not outcomes. Crime is caused by criminals.
Updating a web app to move away from scriptlets and to the JSTL/EL is almost never as easy as a line-by-line substitution, unfortunately. There's usually some refactoring involved and this is a perfect example.
As previously mentioned, the approach I'd take is to put the values into a properties file and read them in in a context listener. Store the name/value pairs in a Map in app scope. Then it's trivial to access the values from anywhere in the app, including the JSPs.
It's not only a clearer, more conventional approach, but it doesn't require code changes and rebuilding to change the values.