This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
it fails with "cannot load jvm.dll"
well, it must fail bcs nbexex.exe is a 32-bit process which tries to load 64-bit jvm.dll. I'll rewrite this part of nbexec to rather spawn a separate java.exe process instead. Quoting hell ahead :-(
fixed
FIXED?
yes
Oh great "fix", now it doesn't start on plain 32-bit intel PIII. See issue 48457.
it's already filed as issue 48441 : "Can't run IDE if JDK is in directory with space"
this one is fixed. Keep it so. The regression will be fixed shortly
What's an advantage of spawning java.exe instead of loading jvm.dll in pure 32-bit environment? I know there's no choice with 64-bit JDK, but with plain 32-bit JDK I prefer to see distinct nbexe.exe on the process list than multiple java.exe processes comming from various tools.
Perhaps easier to keep the former logic and just have distinct 32-bit and 64-bit versions?
Cezariusz: personal preference aside, do you have a real use case to support not spawning a separate java.exe process? Jesse: the former logic is problematic in itself, fragile. It has to hardwire the places of jvm.dll. It's also the reason why jrockit doesn't work. Secondly it's impossible to have one .exe to support both 32bit and 64 jvm.dll. Better to leave it to java.exe which is kept in sync with whatever jvm they ship. The old logic in netbeans.exe is in fact stolen from java.exe. Whenever the java.exe changes we'd have to change as well
The only reason I prefer in-process dll is to make memory usage monitoring easier. When you have several java.exe processes it's inconvenient to check which one belongs to NetBeans. I'm not familiar with memory usage issues regarding both methods.
Verified.