I like the way Eclipse it does for years:
1) Everything inside **/internal/ packages is non API by definition
2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published" packages
3) Javadoc @noextend tag for classes not intended to be extended
4) Javadoc @noimplement tag for interfaces
A bonus for libraries with correct MANIFEST.MF is that they can be directly
used as bundles inside any OSGI container (also Eclipse).
Example:
/**
* An observable value whose changes can be vetoed by listeners.
*
* @param <T>
* the type of value being observed
*
* @noextend This interface is not intended to be extended by clients.
* @noimplement This interface is not intended to be implemented by clients.
* Clients should instead subclass one of the classes that
* implement this interface. Note that direct implementers of this
* interface outside of the framework will be broken in future
* releases when methods are added to this interface.
*
* @since 1.0
*
*/
public interface IVetoableValue<T> extends IObservableValue<T> {
Kind regards,
Andrey Loskutov
http://google.com/+AndreyLoskutov
> Gesendet: Dienstag, 14. Juni 2016 um 09:03 Uhr
> Von: "Jörg Schaible" <joerg.schai...@bpm-inspire.com>
> An: dev@commons.apache.org
> Betreff: Re: [ALL] About binary compatibility
>
> Hi,
>
> James Carman wrote:
>
> > Agree we should have a "source of truth". Is there something wrong with
> > using an "internal" or "impl" package name? The bundle plugin for OSGi
> > doesn't export these by default, which would be a nice side effect! :).
>
> While it is a step in the right direction, a package scoped solution does
> not solve the problem of a public interface that should not be implemented
> directly (as we've seen with the BCEL visitor). Time for Java 8 and its
> default implementations ...
>
> Cheers,
> Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
