It's not converted, it's compiled.
In fact, in some webapp servers, like
Tomcat, it's compiled
twice.
Tomcat has a component called JasSPer, which is the JSP compiler. When a page request for a JSP is made, Tomcat checks its local cache (in the TOMCAT_HOME/work) directory) to see if there's an executable copy of the JSP there. If not, it runs JaSPer on the JSP source code found in the WAR to produce a temporary
Java source code file. This file defines a servlet that outputs the text parts of the JSP, invokes the infrastructure needed to deal with bean references, JSP tags and so forth, and outputs the text-only parts of the JSP. That's the first "compile" or, translation, if you prefer.
This temporary file is then compiled by the "javac" compiler to produce an ordinary Java class file for that servlet. The class file is then added to the compiled JSP cache and to the classpath of the webapp so that Tomcat can invoke it just like it would do for any other servlet.
This need for the java compiler, incidentally is why Tomcat needs to run under a JDK and not a JRE. The javac program is supplied as part of the JDK, but not as part of the corresponding JRE.
Other webapp servers may do this slightly differently, but the end result is the same.
The idea of taking source code in one language, translating it to another language, then compiling the translation into machine language is not a new idea. In fact, quite a few C and Fortran compilers actually produced assembly-language files to be compiled. And the original AT&T C++ "compiler" compiled C++ to C.