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:47:39 GMT
Anton Avtamonov wrote:
> Hi Tim,
> Lemme join to Mikhail's words: very good! Thank you!
> I'm sure it will simplify the contribution process. Of course, we have
> committers who control the process, no doubts; however for me (and I
> think not for me only) it is much simplier to have the guideline of
> what structure is expected.

I appreciate your efforts to get the code right before contribution.
I'm very pragmatic though, and would rather have functional code that
solves people's problems ahead of pretty layout!  I expect that we will
migrate towards compliance with our own guidelines over a period of time

> Could we call *anything_alse* somehow :-)? Personally I would prefer
> *external* as opposite to *internal*, but I expect nobody will agree.

I disagree ;-) (just to prove you right).

IMHO besides being esthetically pleasing it makes it easy to catch
references to internal code.

> Let's me also support Mikhail in his comments:
> On 2/13/06, Mikhail Loenko <mloenko@gmail.com> 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?
> Yeah, looks like it will cause visibility problems, won't it?

Sorry, I think this is a simple misunderstanding -- the guidelines are
only for the org.apache.harmony packages.

>> 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"
> Also agree. In general, binary compatibility should be supported,
> however it could be very complicated to eastablish proper interfaces
> from the beginning...

If you are unsure what to expose, then make everything internal until
there is a need to make it visible to other module developers.  These
interfaces/dependencies likely already exist within the code so this
only makes them explicit not more difficult.

> Btw, is it right that the module contributor himself can decide what
> to put into functionality available for other modules?

Sure, but if I'm writing jar support in ARCHIVE and I need some
internal-API to help me implement, ooh say, signature verification from
SECURITY then I know where to come :-)



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

View raw message