Bug 85228

For this is unusual and I do not know how this can happen I want to ask you for
more information. A thread dump of both IDEs can help us. You can use jps +
jstack if you run on JDK6 to get these.

What do you mean by "both IDEs"?
Just start NB 5.0 and look at the task manager.

Ideally there should be only netbeans.exe

really there are 4 processes. OTOH what's the problem? 

two instances of nbexec.exe seems to be strange. the rest is more an enhancement
to load these things as a DLLs into one process.

The problems are:
- killing netbeans.exe does not close the main window and you have to kill 
other three processes
- netbeans.exe does not consume CPU time but java.exe does and it is not 
possible to define whether it is NetBeans or another Java application

re killing netbeans.exe: maybe this can be fixed

re java.exe: surely there are tools that will tell you more about running
processes. unfortunately this platform does ship with reasonable set of tools
:-(. OK if we change the launcher to link with java.dll this will solve the problem.

Now I see why there are two instances of nbexec.exe:

netbeans.exe (or nb.exe) start nbexec.exe with some set of params.
nbexec.exe checks at the begining if the mode is runnormal or runupdater and if
it is not it starts nbexec.exe with aditional params to set this mode.

This is even more strange for RCP-based applications. You get your app.exe and
two instances of nbexec.exe running (and java.exe of course). This is not very
friendly for non-developers to guide them through their process list, just in
case something bad is happening.

We plan to solve this issue in NB 7.0. We plan to move nbexec functionality to dll and run netbeans in single process.

Created attachment 75107 [details]
patch

please see http://wiki.netbeans.org/WinNB7Launcher for details

[JG01] If java.exe is no longer a separate process, how does AU restart the IDE to install updates? Is it guaranteed
that file locks acquired by Java code are released when the JVM exits, even though the process does not exit? How do we
install updates to the o.n.bootstrap pseudomodule which contains the launchers themselves?


[JG02] "--sproc" is not a very intuitive option name.

> [JG01]
I would expect that all resources are released when JVM exit. However, bigger problem is that NB calls System.exit() on
exit which terminates whole process and control is not returned to launcher as I expected. So I was forced to change it
to create new process on NB restart.

> [JG02]
I changed --sproc to --javaprocess. Feel free to choose better name if you wish.

Created attachment 75196 [details]
updated diff

To JG02: --fork-java seems clearest to me.

t_h I may be missing something where you talked about System.exit, but the JVM shared library will not allow you to
release it and reload it unless this has been fixed in recent years. It has always had a bug where two instances can
never be created in the same process, but again, maybe that is fixed now. I haven't tried that in years as it had been
an issue. 

Most OS and C environments have hooks for the messages a given process will be given. You should be able to setup a hook
for when the process is shutting down. Now, if you can't capture a system message or install a native hook into the
process using which ever tools and runtime you're using, another solution is to create a new Java package to use native
methods which is only used by the launcher. Essentially what you will do is use:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#getRuntime()
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#addShutdownHook(java.lang.Thread)

and thus from the native code, instantiate an instance of what ever class you have created for the shutdown hook, then
inside that class, it uses native methods to do what ever you need to do to setup to run the application again, and I
guess if you can get that work done from plain old Java classes then you wouldn't even need any other native logic from
that point of view. Either way, the Java classes being specific to the launcher, can be added to the classes by the
launcher automatically when launching the JVM, so none of the rest of NB will be affected by them. That will allow it to
work as now on restart. That of course is the JVM shared libraries still can not be reloaded. Last I heard that wasn't a
priority.

>[JG02]
OK.

> wadechandler 
Maybe it was not clear from my message: Original intention was to restart JVM within single process without creating new
one (on NB restart). Because it is not possible (due to System.exit() and maybe it would not be possible even without
System.exit() because of the issue you mentioned) new process is created on restart (and old one is finished).

core-main #8dd0fe0d2bd1

Integrated into 'main-golden', will be available in build *200901070201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/8dd0fe0d2bd1
User: Tomas Holy <t_h@netbeans.org>
Log: #85228: new launchers for windows

Integrated into 'main-golden', will be available in build *200901170201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/eff88627be15
User: Richard Michalsky <rmichalsky@netbeans.org>
Log: #85228: missing lib/nbexec.dll caused suite JNLP build to fail

ok