Well, I guess all this "friendly"-ness use case shall be re-evaluated.
For me an unstable or incubation flag would be more than sufficient, and
the build might warn me or optionally fail if I'd use an
unstable/incubation level of module.
I can be prepared on my side when I use something unstable and can adopt
the change.
Though we have other type of users, who seriously invested in NetBeans
Platform. Geertjan probably know the most of them, a survey on their
site would be good to have.
Right now there is a possibility to tweak friendliness using Yenta
(search it on Google).
Just a sample set of modules, from my own plugin code. These could be
real public from 8.0 at least:
"org.netbeans.modules.gsf.testrunner",
"org.netbeans.modules.gsf.testrunner.ui",
"org.netbeans.modules.java.testrunner.ui",
"org.netbeans.modules.junit",
"org.netbeans.modules.junit.ui"
On 07/12/2018 04:11 PM, Peter Nabbefeld 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: [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
---------------------------------------------------------------------
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
