harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: Location for API extensions
Date Mon, 13 Feb 2006 14:13:12 GMT

Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> I don't like "tests" for obvious reasons that we've discussed before.
> remind me

package visibility

>> 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

I see - so you can have public o.a.h.<woogie>.i.Foo that no one should 
touch except for <woogie> classes...


> This 'visibility of packages' is not part of the Java language.
> Regards,
> Tim
>> 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,
>>>>>> such developers can expect the API to be evolved in a compatible
>>>>>> 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
>>>>>> 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

View raw message