Community
Participate
Working Groups
Currently the Eclipse native launcher locates the java executable (java.exe or javaw.exe on Windows), constructs a command line for it, and launches it as a separate process. Then it waits for it to finish. The program launched is startup.jar, class org.eclipse.core.launcher.Main. There is some handshaking to let the Java side pass info back to the C side for error messages, and also the Java side will re-invoke the C side to display a spash screen. This design causes a number of problems and limitations documented by other bugzilla entries. The purpose of this enhancement request is to replace that design with something simpler that loads and invokes the JVM directly using JNI, without going through the java executable. In addition to using JNI, any logic possible, including opening the splash screen, would be moved into the Java side.
Created attachment 17063 [details] First attempt to launch Eclipse with JNI on Windows Consider this a very rough proof-of-concept. If you apply this patch and rebuild the native launcher on Windows then you can invoke eclipse like this: eclipse.exe -vm "C:\Program Files\Java\jdk1.5.0_01\jre\bin\client\jvm.dll" This version doesn't search for a jvm (it requires you to specify one on the -vm option) and it doesn't parse command line options. But it demonstrates that it is possible to invoke eclipse apps without the extra javaw.exe process. Essentially it does the same thing as javaw.exe but with built-in Eclipse knowledge and branding capabilities.
One issue with using JNI is restarting the Workbench. Currently one of the features of the multi-process launcher is that the Java side can exit with a certain return code that causes the C side to re-invoke the java executable. I don't believe this would be possible with a JNI-based launcher. Mainly this was used in pre-3.0 pre-OSGi Eclipse where restarting was the only way to make Eclipse aware of newly installed features. Although this is still required in some cases in current 3.1 builds, it's something of an anacrhronism. Other bugzilla entries cover this, but the eventual goal is to have Eclipse be completely dynamic with no need for it to be restarted. Even if fully dynamic loading and unloading failed in some cases and restarting was required, I don't think it would be a hardship for the user to have to restart it manually. Many apps have options that don't take effect until the next time you invoke the program so users are used to that. The benefits of JNI-loading would outweigh the minor inconvenience of Eclipse not being able to restart itself.
Moving to Core/Pascal for comments.
Some thougths: - moving the splash etc to the Java side is exciting but not all that easy. The reason it is not done in Java is because we can't find SWT fast enough. (i.e., to do it the nice way we have to find the SWT plugin. To do that meets we have to have the runtime and OSGi up and everytihng installed. On warm starts this is fine. On cold starts (and especially the very first run) this can be a long time. - not sure why relaunching is a problem. - is there a known/standard dll/shared lib that eclipse.exe can look for to start the VM or is that something that has to be configured on a per VM basis? - is there a known/standard entry point on all VM dlls? - it is theoretically a goal to make all Eclipse plugins dynamic but in reality it will be some time until that happens. There are no plans to do dynamic work on the tooling (JDT, PDE, ...) plugins - relaunching is also used for the File > Switch Workspace... action
The problem with relaunching is that, at least with 1.4, you can't unload a JVM and reload it. Best you could do is have main return and then re-run it, which isn't quite the same thing (and could be done in the Eclipse code anyway). For the Sun VM the library is always jvm.dll or libjvm.so. However there are two of them, one in jre/bin/client and one in jre/bin/server. IBM's appears to be called the same but they put it in jre/bin/classic. On Windows each vendor has their own well known registry key that you can query to see where their runtime library is if you want the 'standard system' one. There will be some special casing but -vm is always available as an exit (and last I read, -vm was recommended over letting Eclipse try to find it anyway). The entry points are defined by the JNI API so they shouldn't change. I've seen Swing apps that do the splash screens in Java (animated even) and the startup speed is fine. Java startup with rt.jar generally takes 1-5 seconds. But maybe you're referring to the time to initialize the plug-in registry? If so, maybe the splash can be done in AWT before there are any plug-ins, or maybe SWT could be initialized and running early while the rest of the registry is being built?
SWT could be loaded with a classloader that encapsulates it form other plugins. Also, the "-vm" option should be compatible to old calls and smart enough to handle also paths. eclipce -vm "c:\java\jdk1.5.0_01" eclipce -vm "c:\java\jdk1.5.0_01\jre" eclipce -vm "c:\java\jdk1.5.0_01\jre\javaw.exe" eclipce -vm "c:\java\jdk1.5.0_01\jre\bin\client\jvm.dll"
Gunnar, can you provide any example code that does what you're talking about with SWT? Also I'm wondering where the best place to put the Java splash would be; in Main.java or deeper. On the one hand you want your splash to come up early, but on the other hand you want your launch code to be simple.
How important is all this unicode support in eclipse.c? It looks like it's only enabled for Windows, and the JNI interface is narrow only so I think things will get widened and then narrowed again unnecessarily. The history says it was added 3/7/04 by silenio but I didn't see a bugzilla number.
Created attachment 17091 [details] Second generation patch for Windows This version parses the command line. Also it automatically enables XP visual styles (see bug 45918 and bug 53859) and it stacks properly in the Windows Task bar (bug 9168). I left the unicode stuff in because I found some bugs that referenced it (bug 13657 and bug 78584) but it's untested.
Ed, for restarting, can you not use the current method of returning a special code from main to eclipse.exe, and then simply exec() a new instance of eclipse.exe and exit from the original instance?
Maybe... care to prototype that? I'm not convinced that re-invoking or re-loading yourself is a terribly elegant idea anyway. Two cases for it have been put forth: plug-in installs and switch workspace. Ideally both of those could be done dynamically (arguably with a better user experience).
Have you open a bug report against Sun for java to natively support branding? That is probably the most elegant solution. Two other use cases for restart: - splash screen handling - fwk restart to take bootclasspath extension into account The problem for the workspace change is harder than what it seems... because it means making changes to the whole SDK (Debug, JDT, PDE, ...) which is not a trivial task for probably very little benefits. Indeed since the workbench aspect is set on a workspace basis (which is a desired function) some large chunk of the UI would have to be shutdown / redrawn. Moreover for the whole system to really support the workspace change, all the other plugin of your system would have to support that. Dynamic plugin installation for tooling is not necessarily that interesting, and there is always a case where you install a plugin that is not dynamic... I don't think it is realistic to put extra burden on IDE plugin developers. Of course this is only my opinion.
I'm doubt Sun is going to fix any bug I report :). Splash has been mentioned before but what do you mean about bootclasspath extension? Maybe the JNI launcher can be made to do restarts (I haven't tried the exec-yourself trick yet). But if it couldn't, would making the user double-click on Eclipse to restart it be so onerous compared to the benefits like properly branding the stacked task bar and automatic XP visual styles? Name one other program that restarts itself like Eclipse, besides Windows, and how annoying is that? Bug 9168 has been open for about 3 *years* now. Other programs invoke Java through JNI (for example, JavaService [http://javaservice.objectweb.org/], not to mention the java program itself) so there is precedent.
Our exec'ing strategy is somewhat goofy. Few will argue with that. However, we have many fish to fry and it would be disappointing if this one is high up on the list. People voting for this bug should understand that fixing it means they don't get something from the SWT team. So the bug is marked as helpwanted. In this case the help needed is for someone to produce a complete implementation of this that works across all the platforms and handles all the cases/requirements (non-Sun VMs, different OS/JRE setups, relaunching, restarting, ...)
Is there a list somewhere of the different OS's and VM's that you would need to support this in? It should be very easy to snag the code from Sun for Windows and Solaris and Linux, IBM for AIX and MVS. Mac might be a bit tougher. For what its worth, The things that this would fix are a bit of an impediment for using the RCP in a commercial setting.
I think this is it: http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_1.html#TargetOperatingEnvironments
Jim, can you outline the key ways in which you see the current approach impedes RCP in a commercial setting?
Firstly, to launch an application on windows you really need the executable to be app.exe and not eclipse.exe. This is handled already for the case of a fully contained RCP app. It is not handled for the case where a company has several RCP apps and wants to share the RCP code between them. Second the stacked icons in the task bar on windows is a branding issue. It makes the app look unprofessional if it can't maintain the icon. Third seeing javaw.exe or java.exe in the task list makes tech support harder as there can be several java.exe processes on the system and finding the right one is problematic.
"there can be several java.exe processes on the system and finding the right one is problematic" - ditto on that one. I'm always killing the wrong process when something hangs up. I know, they're not supposed to hang up but... I found some resources that might be helpful for better native integration in this area. http://support.microsoft.com/default.aspx?scid=kb;en-us;281628 http://forum.java.sun.com/thread.jspa?messageID=2796924 http://www.ej-technologies.com/products/install4j/features.html (see custom process name) http://www.codeguru.com/forum/showthread.php?s=1ec7bcf7feb77f60fd67e3caa5eb82eb&p=1076160#post1076160 http://library.n0i.net/linux-unix/standards/ex-hints/ar01s05.html (for Linux)
Great. - The launcher for shared cases is mostly handled now. There are a couple remaining issues but they are currently being worked and are independent of launching strategy. Did I miss something here? - is the stacked icons problem resolved by the new -name argument to the launcher? It seems that it is NOT but I thought that is why we added -name. - process names. Agreed. There is scarely a developer who has not had this problem at one point or other. Feels like this is more of a development time issue than one for end users (at least we hope they are not having to kill things). Having said that, it is worth a solution. There may be alternatives to JNI though. For example, if killing the app.exe process killed its child java.exe this would work.
While I have not tried the -name option (which version is that in?) I don't see how it could address the problem that an ICON is not set. I could see if a title was not set...
But aren't the icons now branded into the launcher? where would the system get the wrong icons? When eclipse is run normally we get the eclipse icons. These come from the exe. If I rebrand/rename the exe with different icons, they should be different.
You don't get the right icons when they are started in the task bar. This happens when there are too many processes running in Windows XP.
Don't forget the XP themeing issue (bug 53859). Eclipse and other RCP apps should always use the XP skins set by the user. -name is in 3.1m4. See http://www.eclipsepowered.org/archives/2005/01/05/using-native-launcher/ for some "doc". I've tried it and it doesn't help the taskbar stacking issue (bug 9168). It does change the name shown in the taskbar but only if it's not stacked/grouped. According to the threads in comment #19, stacked names come from the exe's embedded resources, just like icons do. Windows XP picks the first one in the stack and uses its resources. Even in JRE5.0.1, javaw.exe aparently doesn't bother to give any value for these resources so it defaults to "javaw.exe" with a terminal looking kind of icon. Thankfully many people turn off taskbar grouping but some don't so they see this. I don't know enough about Mac or Linux to know if they have any issues like this (i.e., problems with the dual process approach).
> I don't know enough about Mac or Linux to know if they have any issues > like this (i.e., problems with the dual process approach). As a user of Eclipse on OS X, I can testify that the dual process approach is very unprofessional. It causes Eclipse (or an RCP app) to show up twice in the OS X Dock, which is confusing to end users - especially because clicking the original icon again will launch more instances of Eclipse.
> Thankfully many people turn off taskbar grouping.... I would love to hear where you got these statistics. It's kind of like developers who look down on people who don't use the Windows Classic theme. You can't make these general statements and get away with it. Users are users and will use every feature in the OS that we don't like. You can bet on that!
Andrew has started some investigations in that space.
FYI, when the java launcher is used in JDK 6, it does not launch HotSpot in the primordial thread anymore. This solves a number of issues. However, if JNI is used to launch the vm, this improvement won't be automatic. This[1] article shows what is required in this case (and explains the issue in more detail). [1] http://blogs.sun.com/ksrini/entry/hotspot_primordial_thread_jni_stack
Some time back Jeff had commented this way "For example, if killing the app.exe process killed its child java.exe this would work." I would like to know whether this is supported in eclipse 3.2.1 based rcp application
FYI: I just noted that on the latest version of Azureus (http://azureus.sourceforge.net/) there is no more separate azureus.exe and javaw.exe processes. Perhaps someone can take a look on what approach they took.
What's the status of this one? Did it make it into 3.3M5?
Yes, but VMs are different (buggy?) enough that it does not work for all them. http://wiki.eclipse.org/index.php/Equinox_Launcher
Thanks, I had my -vm pointing to javaw.exe but once I fixed that it's working great. Two thumbs up!
