Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:Equinox Launcher Plan"
(→Getting the dll, and the -vm option) |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 2: | Line 2: | ||
: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. [[User:Aniefer.ca.ibm.com|Aniefer.ca.ibm.com]] 22:37, 21 November 2006 (EST) | :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. [[User:Aniefer.ca.ibm.com|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. [[User:Aniefer.ca.ibm.com|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: | ||
| + | |||
| + | -vm "c:\path\to\jdk1.6.0\bin\javaw.exe" | ||
| + | |||
| + | 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: | ||
| + | |||
| + | -vm "c:\path\to\jdk1.6.0\bin" | ||
| + | |||
| + | This doesn't work: | ||
| + | |||
| + | -vm "c:\path\to\jdk1.6.0" | ||
| + | |||
| + | 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? --[[User:Ed.burnette.sas.com|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, [https://bugs.eclipse.org/bugs/show_bug.cgi?id=167310 bug 167310] and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=168726 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 [[Equinox_Launcher#Finding_a_VM.2C_Using_JNI_Invocation_or_Executing_Java|here]] on the details of the -vm argument. [[User:Aniefer.ca.ibm.com|Aniefer.ca.ibm.com]] 18:54, 15 March 2007 (EDT) | ||
Latest revision as of 18:54, 15 March 2007
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:
-vm "c:\path\to\jdk1.6.0\bin\javaw.exe"
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:
-vm "c:\path\to\jdk1.6.0\bin"
This doesn't work:
-vm "c:\path\to\jdk1.6.0"
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)