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:34:58 GMT
Mikhail Loenko wrote:
> Looks very good!
> I have two comments/questions.
> 1. I thought we agreed that *some* tests should be in the same package as
> implementations. How this fits together with a special package name for tests?

Sure, if you need helpers that reside in the same package to get package
visibility, then so be it -- I was only trying to describe the
org.apache.harmony packages;

i.e. we would have

> 2. Does not it sound too strict: "module developers who modify code that is not
> in an internal package must do so in a manner that ensures Java binary
> compatibility"? How about  "... should avoid breaking Java binary compatibility
> and must check that the change does not break other modules"

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


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

View raw message