I'll pitch a couple of things in here:
1. Part of the problem with friend apis is your that the term gets
overloaded for two different concerns: A. APIs undergoing stabilization,
where the expectation is that a stable api will emerge, and B. Dependencies
which are never intended to produce an API. Because at the technical level
the module system doesn't need to distinguish those two things, we have a
single term representing both, resulting in confused expectations.
2. That being said, something Jarda and I used to stress in our api design
talks was "you are always writing an api" - if you followed good api design
patterns, opening a friend api should not be sentencing yourself to
code-jail. So I'd suggest splitting out the question of "should existing
apis become public" from "how do we encourage more public apis in the
future".
3. If you don't like the current situation with friend apis, you probably
want to support some proposal other than maintaining the status quo, or you
can expect more of the same.
-Tim
On Thu, Aug 9, 2018 at 2:38 PM Laszlo Kishalmi
wrote:
> Go on People, share your thoughts!
>
> Thanks for Neil who already did that!
> Thanks for Jarda to adding one more option to select from!
>
> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
>
> On 08/08/2018 01:26 AM, Laszlo Kishalmi wrote:
> >
> > Dear all,
> >
> > I'd like to start the second round of discussion on this topic.
> >
> > Oliver Retting was so kind to summarize the opinions presented on our
> > mailing lists.
> >
> > I myself stared a mini analysis on each option, mentioning my attitude
> > to them as well.
> >
> > Please take your time, extend, modify and share your opinions and
> > attitude!
> >
> > Remember I'm just trying to drive this discussion not dictate it. So
> > any idea, opposition, pro and con are welcome!
> >
> >
> https://cwiki.apache.org/confluence/display/NETBEANS/Public+vs+Friend+API
> >
> > Let's give this round another 2 weeks, what can be extended with
> > another two if we feel the need.
> >
>
> --
http://timboudreau.com
