Talk:Equinox Launcher Plan
What's the rationale for not parsing the Manifest.MF to obtain the Main-Class, and instead having it as a specific argument? Is it just for speed? If so, how much difference does it make? I'd have thought a RegExp would be fairly quick.
- We would like to avoid having to parse the manifest file mostly for simplicity's sake. To parse the manifest would would first need to extract it from the jar. Easy enough in Java, but a little more complicated in C. We don't really have time to write something like that ourselves. Admittedly I haven't looked, but I'm not sure that there's a library that we could use that covers all the platforms. Aniefer.ca.ibm.com 22:37, 21 November 2006 (EST)
- After thinking about this a little last night, I realized that we don't need to get the manifest using native C. The idea is that after creating the VM, but before looking for the Main class, we could use JNI reflection to get the manifest. Aniefer.ca.ibm.com 09:54, 22 November 2006 (EST)
Getting the dll, and the -vm option
Before 3.3 the best practice was to use a command line with this option:
In 3.3M5 this still works and invokes javaw.exe as a separate process. In order to use the new JNI loading you have to change the option to:
This doesn't work:
even though the article says something about searching around for the right path. First of all, is that correct and the way it was intended? And secondly, why not make the first form be equivalent to the second? Is there a use case where you would NOT want to use JNI and load the java dll directly? --Ed.burnette.sas.com 09:25, 12 February 2007 (EST)
- Yes there are reasons to want to launch java in a separate process. For example, bug 167310 and bug 168726. Also, we have had problems on some vms on some platforms where JNI invocation isn't working, in that case you want a work around to specify forking java.
- There is some detail here on the details of the -vm argument. Aniefer.ca.ibm.com 18:54, 15 March 2007 (EDT)