I think you are annoyed by friend APIs just because nobody cared through time about those APIs to bring them to a public API. But that's just a sign of no money / human resources poured into it, not a lack of automation or other processes.
If you somehow force people to reconsider friend APIs as they become public in 2 releases then they will just stop using friend APIs and find other creative ways via reflection, the global lookup, etc. So... you only obfuscate the matter. Note that the Friend API is not only for NetBeans! You could also have your own bunch of modules and defined friends among some of them, etc. I know that some NetBeans friend APIs are quite juicy so I understand the frustration but it's a frustration with the NetBeans codebase, not the concept itself. --emi ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On 13 July 2018 2:11 AM, Peter Nabbefeld <peter.nabbef...@gmx.de> wrote: > Hello all, > > I personally don't like "Friend" APIs, as really I like the idea of an > > open, extensible IDE. > > From my point of view, Friend APIs make it difficult or impossible to > > extend NetBeans for personal use: > > - You have to ask for being added to the friends list. This is > > especially a problem, if You want to implement some private-use feature, > > e.g. for Your employer. > > - Alternatively You could depend on the implementation version; but I > > don't see how to do that, if You're using Maven. > > - Third possibility is just patching the modules to remove the friends > > and make the API public - very ugly, and You have to do it after every > > update. > > OTOH, having a friends-only API leads to fewer dependencies on the API, > > thus less impact from changes to the API, which makes work easier for > > the developers, of course. > > However, if an API isn't stable, yet, it could also just be flagged as > > "Under Development", thus telling users of those, that it is subject to > > change. Also, as it is possible to use default methods in interfaces > > from Java 8, it should be less of a problem to extend an existing API. > > But You can use the API on Your own risk without any conflicts. > > An exception of course is having APIs only for modularity, if classes > > are spread over different modules and need an API to interact with each > > other. In this case the API's purpose is not to integrate extensions, > > but to split responsibilities - in this case I fully agree these are not > > for public use. > > I'd be interested in comments on this - so, what do You think? > > Kind regards > > Peter > > > 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 --------------------------------------------------------------------- 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
