[wildfly-dev] About API and leakage

Brian Stansberry brian.stansberry at redhat.com
Fri Oct 18 13:18:41 EDT 2013


On 10/18/13 12:08 PM, David M. Lloyd wrote:
> Guys, when developing an API that is going to be shipped either as part
> of WildFly as a module or for end-user consumption, I want you to
> remember something:
>
> Every public and protected member of that module *IS* API.  That means
> you can't ever change it without considering compatibility.  "Well I
> just made it public because this other module needs access to it" is not
> a valid excuse, nor is "Well I needed access from another package".
> Both are synonyms for "I screwed up my design at an early stage and now
> I want to break the rules to fix my mistake".
>
> The only exception is if you're developing a component specifically and
> exclusively for use in the modular environment, and you put all non-API
> public members into a specific package or package set which is then
> excluded from export in the module.xml descriptor in the shipped
> environment.
>

We've fallen down a lot on this bit. I know there's a lot of code in WF 
that was meant to be excluded from export, but there just was never time 
to do it.

> If you do not fall into this exception then you are volunteering to
> personally maintain these non-public public classes for the next 10
> years come hell or high water, because people are surely going to use
> them, and I sure don't want to be the one to maintain them.
>


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat


More information about the wildfly-dev mailing list