> On Feb 27, 2018, at 12:13 AM, Jan Lahoda <[email protected]> wrote: > > Hi Scott, > > On Mon, Feb 26, 2018 at 11:54 PM, Scott Palmer <[email protected] > <mailto:[email protected]>> wrote: > >> That is of course the “correct” way to do this. But I still wonder, why >> doesn’t NetBeans use the standard java launcher that is produced by >> javapackager? >> > > I am not sure what exactly is the proposal - could you please share some > more details? > > Looking at the current launchers, they seem to provide at least these > services: > -run the updater before or after the IDE/application is run, and possibly > restart the IDE/application after running the updater > -find a viable JDK (or read the path from etc/netbeans.conf) > -read extra options (including VM options) from etc/netbeans.conf > -detect userdir and cache dir locations > -for Windows, the launcher itself probably has an icon > > Also, our builds are currently multiplatform (esp. Linux build can run on > Windows), and I think it would be good to keep this. > > It we can maintain less platform-specific code, that would be nice, but I > think I'd need a more complete proposal on how to exactly do that without > loosing too many of the above features. > > Jan
It may not be feasible given everything the current native code does. Things like determining the userdir and cache dir seems to be something that the Java code can do. The native side should really just be about starting up with the right JRE/JDK with the desired JVM parameters. The standard launcher installed by javapackager already has a way of specifying the JRE or using the system JRE, and specifying user-configurable JVM parameters. It would likely make the current netbeans.conf file obsolete. The javapackager tool also embeds the icon resource on Windows. The main concerns would be around the update & restart cycle. Perhaps restarting netbeans would need to be handled differently. Alas, I don’t have the cycles to dig in and come up with a proper proposal. I just wanted to make the point, the JDK has a tool that provides a native launcher stub - unless we have a good reason not to use it, I think it makes sense to use it. Perhaps for now we have a good reason ;-) Scott
