The java launcher code in src/java.base/share/native/libjli/java.c and its related files has accumulated code some of which is no longer applicable in recent versions of the JDK. There's also the C code in this launcher which parses the JAR files for MANIFEST information very early during the launch. The JAR (i.e ZIP) parsing in this C code doesn't take into account ZIP64 files and unlike its Java counterpart in the java.util.zip.ZipFile code, doesn't have the necessary validations and robustness when it comes to the ZIP format parsing.

This issue proposes to cleanup the launcher code to help improve its maintenance. Very specifically:

The launcher code has a function called SelectVersion() which prior to Java 9 days was around to support selecting a particular JRE. It was used to implement the Multiple JRE feature (mJRE). mJRE was removed from the JDK in Java 9 https://bugs.openjdk.org/browse/JDK-8058407. At that time this function was trimmed down to just making sure that the "-version:XX", "-jre-restrict-search" and "-jre-no-restrict-search" command line options to the launcher are rejected during launch. In addition to this, the implementation in the SelectVersion() was left to parse the jar's MANIFEST file and find a Main-Class and any SplashScreen-Image in the jar. Leaving around this part in the SelectVersion() was merely an convenience because, previously before mJRE support was removed, this code in the SelectVersion() anyway used to parse the MANIFEST to find the "JRE-Version" manifest attribute. That manifest attribute hasn't been supported (in any functional way) starting Java 9. So there's no need to be parsing the manifest file in this SelectVersion() function. Furthermore, the SelectVersion() function itself is no longer necessary and the parsing of the command lines options (including rejecting the outdated options) can be done in the ParseArguments() function that gets called shortly afterwards.

With the proposed removal of SelectVersion() method, it then means that the manifest parsing itself can be done in the Java code when the java launcher through its `JavaMain()` function invokes (through an upcall) a java method on the LauncherHelper. The LauncherHelper already has the ability to (and does infact) construct `JarFile` instance, parse the manifest and return suitable information back to the `JavaMain()` function so as to allow launching the relevant main class' main method. The advantage of allowing the java code to do the parsing of the manfiest file is that, it will now reuse the same java.util.zip.ZipFile implementation for parsing the JAR file and thus has the necessary support for ZIP64 files, has proper validations and will provide consistency between the launcher and java runtime code when it comes to dealing with JAR files.

Additionally, in addition to parsing the jar's manifest for the Main-Class, the C code in the java launcher was also parsing the manifest to find any SplashScreen-Image manifest attribute so as to display a splash screen before the application's main method would be invoked. Experiments show that displaying this splash screen can still be done without having to parse the manifest in the C code and let the `JavaMain()` method through the LauncherHelper provide the necessary SplashScreen-Image value to the C code.

Although these appear to be almost independent improvements in this code, it's not straightforward to do them as separate individual tasks. So this current issue will do these changes in this single issue.