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 12:30:31 GMT
I don't like "tests" for obvious reasons that we've discussed before.

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

geir


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

Mime
View raw message