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 14:03:00 GMT
Geir Magnusson Jr wrote:
> 
> 
> Tim Ellison wrote:
> 
>>
>> The problem is that once you release a module with a particular internal
>> API into the wild you need to ensure that other modules that depend upon
>> it are not broken by your internal API changes.  
> 
> But aren't they internal?

I'm confusing things ;-)  There are two 'internals'.  Internal to a
specific module's implementation (org.apache.harmony.internal.*) and
internal to Harmony i.e. not part of the Java-spec but a useful utility
to share with other modules.

These are the two categories in Anton's original note.

A module can mess with it's internals as much as it pleases; but the
utilities it shares with other module's should be managed.

Regards,
Tim


>> In general, unless you
>> control the make-up of the runtime you will not know whether you are
>> breaking other modules (or to put it another way, you can check that you
>> don't break other modules for a given build but other people may be
>> combining different versions of the modules).  With runtime support you
>> can have multiple versions of a module simultaneously, without runtime
>> support you must retain binary compatibility.  In practice this simply
>> means knowing which changes are allowed, and which require a new
>> internal API.
>>
>> Regards,
>> Tim
>>
>>> On 2/13/06, Tim Ellison <t.p.ellison@gmail.com> 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.
>>>>
>>
> 

-- 

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

Mime
View raw message