> unless we have a good reason not to use it, I think it makes sense to use it.
Well, the existing launchers work and somebody inside Oracle was capable of building them at some point so we should be able to do it too with some effort. Migrating to another launcher might be more work to make sure everything we expect still works, or move stuff from the native to the Java side, etc. It just seems much less work short-term to just compile this binary. Of course, long-term using the 'standard' launchers from JDK sounds better but we might get the surprise of those launchers being abandoned too rather soon ;-) --emi ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On 1 March 2018 7:35 PM, Scott Palmer <[email protected]> wrote: > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
