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 Mon, 13 Feb 2006 13:58:53 GMT
Geir Magnusson Jr wrote:
> I don't like "tests" for obvious reasons that we've discussed before.

remind me

> I do like "examples" as that's clear to people.
> "internal" is interesting, because we already have mechanisms in Java to
> do this, so I don't see the point.

huh?  what?

> It's also really unnatural to me to
> do this in a  package scheme.  I wish I could be clearer on why this
> sets my teeth on edge, but I can't, so I'll think about it a bit more...

just so we understand one another...

- our end users may use:
	java.<whatever> and friends (as defined by spec.) from
	any module

- developers of a given module may use:
	java.<whatever> and friends from any module
	org.apache.harmony.*  (but not 'internal') from any module
	org.apache.harmony.internal.* from this module

This 'visibility of packages' is not part of the Java language.


> Tim Ellison wrote:
>> I've put a first cut of the proposed package naming convention on the
>> website:
>> http://incubator.apache.org/harmony/subcomponents/classlibrary/pkgnaming.html
>> Regards,
>> Tim
>> Leo Simons wrote:
>>> On Fri, Feb 10, 2006 at 12:52:09PM +0300, Anton Avtamonov wrote:
>>>>> As I wrote elsewhere, I propose that packages whose naming
>>>>> convention is:
>>>>>        org.apache.harmony.<modulename>.<something>
>>>>> represent internal APIs.  All visible (public/protected) types in
>>>>> those
>>>>> packages can be used by class library developers from any module, and
>>>>> such developers can expect the API to be evolved in a compatible way.
>>>>> Module developers should not rely on the stability of anything
>>>>> starting:
>>>>>        org.apache.harmony.<modulename>.internal
>>>>> and are strongly discouraged from referencing visible types in such
>>>>> packages since these are type internal module implementation code (and
>>>>> when we turn on OSGi runtime checks the imports from other modules
>>>>> will
>>>>> fail).
>>>>>> From other hand if we are talking about using these useful classes
>>>>>> only
>>>>>> inside Harmony then it's probably a good idea. But we need some
>>>>>> procedure
>>>>>> for moving a class to utilities package and we need to notify
>>>>>> developers
>>>>>> about class capabilities.
>>>>> Moving it to a 'utilities' package should be as simple as making it a
>>>>> non-internal package name; and the notification is javadoc of those
>>>>> non-internal types.
>>>>> If people agree I'll write something for the website along these
>>>>> lines,
>>>>> if not we can continue to debate it on the list.
>>> +1 (to the website thing, though debate obviously is fine too :-D).
>>> I personally think that it is a good idea to seperate out
>>> non-J2SE-specific
>>> non-Harmony-specific stuff as much as possible. I also think it is a
>>> good idea
>>> to evaluate very carefully on a case-by-case basis whether it makes
>>> sense to
>>> have that kind of code live under the "harmony" banner -- experience
>>> has shown
>>> that breaking out "true" utility stuff can help result in wider usage
>>> of that
>>> stuff which tends to result in more bugfixes, better code, etc.
>>> For example (and I'm being really naive here) I can imagine that
>>> java.util
>>> could be built on top of jakarta-commons-collections, or that
>>> java.util.logging
>>> could be built on top of log4j (now that'd be cool).
>>> But this is just me imagining stuff that might be possible in the
>>> future. For
>>> now it doesn't make sense to worry or think about this too much -
>>> we'll see
>>> what kind of ties between harmony and something like jakarta-commons (or
>>> whatever other part of the open source java space we're on about
>>> here) is
>>> possible as the issue comes up.
>>> cheers!
>>> Leo


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

View raw message