This idea might work if developers are employees and they will be paid to stabilise friend APIs. But... this is the reason we got where we are: Sun/Oracle didn't put enough money on the table for this kind of work.
But under Apache... who's going to do the work? All I understand is that when somebody introduces a new friend API they might break NetBeans builds in about 2 releases. So, will I +1 that friend API? I might be more inclined not to. Which means in practice we just stop using friends APIs. But... the need friend APIs cover is still there. What will we use then? It might be something even worse (like reflection, etc). --emi ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On 24 July 2018 10:49 PM, Tim Boudreau <[email protected]> wrote: > > I agree with Emilians comments (have a look at the end of this mail) and > > I want to add that I > > like it to start with Friend-only API because then a potential user must > > become active to use > > it. The user asks me to be added on the friend-list and I get his e-mail > > and I can ask him for > > feedback in my answer. That is great. The main problem in the context of > > netbeans maybe is > > that it needs additional time that the netbeans repository is updated with > > the information of > > the list-change. Maybe other people are involved etc. But I am not sure if > > this is really a > > problem. > > Historically, the problem has been: > > - Developer develops some modules with a friend API between them > - Developer goes away / moves on to another project / loses access to the > repo > > - The modules stay in the distro, but other than someone updating them in > the case of API changes, nobody is touching the code > > - Somebody wants friend access to it > - There is nobody to ask > > > > I am afraid, that an automatism which makes friend APIs public after some > > versions will > > produce more public APIs but with less quality. > > Oh, it's definitely a kind of social engineering. But so is making it okay > to have "unstable" APIs that remain that way for years with no code > changes. > > We know what kind of results the current situation gets. If we want > something different, we should do something different. > > > I like the situation that all public netbeans APIs are very stable and > > have good quality. > > I like it too. I appreciate it every time I maintain a NodeJS project, > where any library update almost invariably means rewriting a ton of code. > > > And > > thats more important for me than having more APIs. But of course to have > > more APIs I will > > like too. > > The point is to create a forcing function to stabilize friend APIs. As in, > either it needs to become a stable API by release X, or you have to use > implementation dependencies and your module won't be usable across NetBeans > releases. That provides some motivation to stabilize an API. > > The Idee Peter presents: > > > https://stackoverflow.com/q/32555597/2999563 > > I like too. It can be a nice additional feature to be used in the friend > > APIs. The more and > > more stable the friend API will be, as less usage of @unstable annotation > > is used and if the > > last position of the @unstable annotation is deleted than it is time to > > make the API public. > > The endgame of that approach is the same mess NodeJS has - there won't be > stable APIs. If you can just mark something unstable permanently (which is > the situation we already have), there's no reason to choose to commit to > backward compatibility. The only thing that changes is it becomes > module-developer-beware. > > Whereas actually making friend APIs into stable APIs if some set of > conditions is met (say, has stayed compatible for two releases) like it or > not actually pushes the developer to stabilize the API. > > One gets you friend modules that are just called "unstable" which you can > use, and when they break it sucks to be you. The other approach actually > creates a process that forces APIs to be stabilized. > > Which is better for everyone in the long term? > > -Tim --------------------------------------------------------------------- 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
