On Thu, Jan 28, 2021 at 5:57 AM Neil C Smith <[email protected]> wrote:
> While I understand we likely need a native executable to fix this > issue, I remain of the view that it probably should be a stub calling > bin/netbeans, not duplicating its function and directly calling > platform/lib/nbexec I have deep reservations about that approach. > Philosophically, this makes sense to me. Simply, the "official" way to launch Netbeans is bin/netbeans, anything else is an implementation detail. And any wrapper used to facilitate the launching of Netbeans should rely on the script, rather than the internal workings of the script. This allows any changes to the start up behavior to be propagated globally through the bin/netbeans script, vs scattered in to other artifacts. This better leverages the community with a common code base rather than having specialty knowledge about the mac, and swift and whatever. THAT SAID, we should also be cognizant that there are "others" calling bin/netbeans, rather than just typing it in to the CLI or using some other windowing shortcut. So, it's important to keep that perspective as well. Being ignorant of the details of the overall issue, it seems that if the Swift wrapper can safely invoke the java command line code and pass on the appropriate rights, it should as well be able to invoke the bin/netbeans script with the same assurances. So, ideally, a "quick switch" away from invoking java directly to calling the bin/netbeans should work. On that note, though, if this wrapper works, and works now, and we're that close to 12.3, I would think it's worth having this capability in 12.3 now, and fix it for bin/netbeans after the release, rather than removing the capability from 12.3, or holding it up. IMHO, of course. Regards, Will Hartung
