Hi,
Am Montag, den 18.05.2020, 15:47 -0400 schrieb Tim Boudreau:
> A script failing can't take the JVM with it.
yeah it is really tough to catch an UnsatisfiedLinkError it tasks a
whole set of try{} catch{}...
Sorry, but could we give Hector a chance before we shoot his idea?
Seriously what is wrong here?
* Yes, there are more developers out there today and it got more
diverse, so if we can (I raised my concers) cover the needed
functions and give the option to choose the native notification
system, why not?
* Yes, a notification system could be pushed into the the desktop
module of the JDK, but seriously? There is enough critisism here,
what will happen when this is proposed for the JDK? It might make it
by 2032
* Yes, there are standard distributions out there, with a set of
libraries, you can expect, and if not build in an unusual way
provide stable function exports. If you build a custom version of
java, gtk, the glibc or some other library the JDK relies on and
NetBeans fails, noone will bother. Yes as long as we stay with the
documentated API I expect it to be present, if it is not it is a bug
of the library vendor.
* Yes, we are already down that road: on windows the NIO WatchService
cause massive regressions compared to the implementation against the
win32 API, so the switch was rolled back.
Hector did good work to stabelize the the build by reactivating and
fixing unittests. So give him the benefit of a doubt. Neil already
indicated, that he has a critical eye on the native interface, so it
will not go in unreviewed.
Greetings
Matthias, who will stay with NB internal notifications and who likes
Metal LAF
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
