commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Loskutov" <losku...@gmx.de>
Subject Re: Re: [ALL] About binary compatibility
Date Tue, 14 Jun 2016 07:14:18 GMT
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.schaible@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message