On Sat, 22 Sep 2018 at 01:01, Laszlo Kishalmi <laszlo.kisha...@gmail.com> wrote: > > I think the most > viable solution is: > > Option 4: Make Module Public when There is more than a Certain Number of > Friend Dependencies. >
Slowly catching up on email post-holiday, so apologies for delayed response. Firstly, I'm disappointed, but not surprised, there's not much impetus and energy for really reviewing how module dependencies work per Jesse Glick's proposal - there's a lot of work in there! But, if we are sticking primarily with the status quo, with my platform developer's hat on can I request we consider two minor updates to Option 4 (or whatever we go with) 1. Remove the use of Friend APIs on all third-party modules. I kind of understand why this was done, but it's a real PITA sometimes! Perhaps wider discussion when introducing outside dependencies. 2. An opt-in switch to override friend dependencies externally, with perhaps in the case of NBM's a corresponding manifest flag (unstable / incubating) for plugins that do this? If we want people to contribute to stablising APIs and documentation, it's cart before horse to expect them to request a friend listing as the first step in utilising the module. Opt-in for incubating features is good, no?! ;-) http://openjdk.java.net/jeps/11 Best wishes, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
