harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Location for API extensions
Date Thu, 09 Feb 2006 11:40:33 GMT
Anton Avtamonov wrote:
> We have agreed on org.apache.harmony package as a root package for
> private implementation stuff. As I understand the major part of the
> functionality located there is some kind of utility stuff used from
> different places (packages) and therefore moved out from the API tree.
> Besides, it also can contain some 'default' implementations when
> public API represents interfaces only.


> It looks for me that in general we can divide all such stuff into 2 categories:
>  - utility methods appeared due to package visibility or other
> reasons, 'default' implementations, etc. This category (in general) is
> not likely to be interesting for the users of harmony platform

Yes, as you say, these are typically impl classes behind public API.

>  - classes, which are referenced from API, but have stand-alone value,
> which is not accessible from public API. Such classes, in fact, extend
> the standard API and may be useful for the harmony users. I believe
> such functionality exists in almost any module; their authors know
> what is valuable.

Yes, I would call these 'internal' APIs.  There are a few sub-systems
that are generally useful to class library implementers.

> What I propose is to identify such functionlity and separate it from
> the 'hidden' utility stuff. Let's have some additinal root
> (harmony.extensions say) specially intended to keep 'java-harmony'
> improvements. What do you think?

I think having a package naming convention for it is good, it gives a
clear indication of the expected 'scope' of API users which is necessary
to understand when you migrate internal APIs.  (I'm not keen on the name
'extensions' tho')

Eclipse has quite a simple and intuitive package naming convention:

If we do a similar thing that would produce:

	root of all package names

	separates module namespaces

	types whose API will be carefully managed.  Other modules
	can use these types in their impl.

	types reserved for use only within the module impl.  Other
	modules should not use these types as they may change.

	module's tests

	module's examples (if we have any!)

The componentization runtime can enforce the package visibility rules
through the JAR manifest, even allowing 'friend' relationships etc.  See
an example of this in the NIO manifest, who only allows LUNI to see the
com.ibm.io.nio package [1].




Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message