Well the whole commons stack now has support for OSGi and OSGi provides
a mechanism to not export a package so I'd say one should use the
internal package (e.g. org.apache.commons.lang.internal) for all classes
that have to be public but are not part of the public API.
This is better than using the _ IMHO and in conjunction with a big
comment this makes it as clear as possible.
Another problem are interfaces that are not designed get implemented by
client code. They should be flag as that in a common way (as a side note
eclipse 3.4 provides special javadoc comments for such
classes/interfaces and other helpers to ensure that one does break
binary/source compatility when evolving the API of modules [1] which is
very tricky thing to get right but this doesn't apply to commons I guess
because its not bound to an IDE).
Tom
[1]http://wiki.eclipse.org/Evolving_Java-based_APIs_2
[EMAIL PROTECTED] schrieb:
Emmanuel Bourg schrieb:
sebb a écrit :
BTW, perhaps Commons should have a similar naming convention for
packages that need to contain public methods, but which are only
intended to be used in Commons libraries.
Or a big "DO NOT USE THIS CLASS, RESERVED FOR INTERNAL USE" in the
Javadoc ?
In the MyFaces project, the convention is to use a leading underscore on
the names of classes that are not intended to be part of the stable
public API (but cannot be package-scoped for technical reasons), eg
public class _WidgetUtils {....}
A javadoc comment like the above is also attached, but the leading
underscore makes these classes really stand out.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
