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.
Could try to do this in the core instead of the launcher. If the user is forbidden to keep core upgrades in the user directory, and is forbidden to install into the user directory modules which use lib/ext/ (which few if any modules should still need to do, especially if modules/patches/ is reimplemented) then it should be possible to set the user directory interactively in the core. In fact it would be possible to switch user directory at runtime, or in fact to implement more subtle arrangements than the current two-directory system, according to the needs of projects. Any code which persisted a choice of user directory (assuming it was not the IDE's default selection) would have to be portably implemented in Java. I.e. no Windows registry; perhaps a pointer file in the user's "home directory" would be enough. Someone suggested recently on nbdev (cannot find ref) that JNI could be used to implement native hooks where appropriate, e.g. to access the Windows registry.
Not required immediately; maybe for 4.0 projects. Auto Update needs to help out by making sure that the user dir never contributes to the classpath.
I would like to have it done in 3.3. This issue has been around for too long. The intial dialog is horrible from the user point of view. I would like to remove it altogether. I've posted a proposal long time ago to nbui/nbdev, will dig it out of the archive and put the URL here.
OK. I may need help from someone w/ VC++ experience at some point. If we store the Windows userdir in a non-registry file, this might not be necessary; however I don't know whether a .bat file would suffice on Windows if it were simplified (specifically whether the problem with DOS boxes appearing for every command would still crop up). Another concern: the autoupdate restart logic is more complicated than it used to be. I don't think restarting can happen without spawning a fresh VM - but maybe it can, if the bootstrapper has a small fixed classpath (JRE plus bootstrap.jar). Finding environment variables on Windows (or Unix for that matter) could be handled with JNI, maybe.
branch in core: bootstrap_feb_2002
Created attachment 4849 [details] Aborted patch
Was looking into ways to actually replace the initial classpath setting altogether with a bootstrapper, but this introduces a number of serious problems and doesn't make the launcher that much simpler. Will try a simpler tact. #17460 may be required first. If the userdir is set in Java code, then the shut down - update - restart sequence cannot be done for user-dir NBMs, I guess. So autoupdate had better install or upgrade user-dir modules while the IDE is running. Anyway they will not be able to use lib/ext/ etc. so there is little reason to restart the IDE for them.
See also issue #22085.
I am actually not aware of any visible problems remaining that would be addressed by such a change, as the default user dir is now set quietly on Windows anyway. There may be a need to change user dirs on the fly for session support in 4.0, but no requirements for this have been written up that I know of. Code cleanliness in the core might be improved by certain changes, but not necessarily setting the user dir in Java; more just simplifying startup code in general. This is an internal maintenance concern.
Is not this obsolete? I have heard that there is a fixed default userdir on windows in version 3.4, but I cannot verify that...
Yes, the userdir dialog is gone. This is probably obsolete, can reopen if there is a concrete reason why setting the userdir in Java code would be necessary. For now I don't see any.