Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of t.p.ellison@gmail.com
 designates 209.85.215.49 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=GxOhyPObGT2w4Kg7b2SyM5oFH25J3PrBBT4QvVocSuJP5pVl7+QL38wpXcwIhfQiwe
         O9roHP8COoWuV4/nRkqZHUn7ZYCRxaJLbi6ty8kvN7hYTXgN8IYEMpoVLQkGxlhXkG6T
         sUJfMAqxmYX6iq5uUv1oBCimePsyqqMC5mfjA=
Message-ID: <4C8F9D6B.5000808@gmail.com>
Date: Tue, 14 Sep 2010 17:06:03 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: questions about Non-bug differences from RI category
References: <AANLkTikbBNRniQDscUXoSQdBp12wrYgLOvc7tmLCq_eL@mail.gmail.com>
In-Reply-To: <AANLkTikbBNRniQDscUXoSQdBp12wrYgLOvc7tmLCq_eL@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 14/Sep/2010 16:39, Robert Muir wrote:
> To what extent is the project interested in non-bug differences from RI?

All are interesting, either as differences we will fix, or as
documentation of decisions not to fix.

> For example, in Lucene we have a test that invokes Character.codePointAt()
> and expects an exception.
> the javadocs state that it will throw IOOBE (which harmony does),
> but the test was written (incorrectly) to expect StringIndexOOBE,
> ArrayIndexOOBE (which sun does)

A quick look at the harmony code, and it seems we are explicitly
throwing IIOBE's from our code, e.g.

  if (index < 0 || index >= len) {
      throw new IndexOutOfBoundsException();
  }

In this case I see no reason why we wouldn't match the RI behavior, even
though it is not required by the spec.

> We also see other non-bug differences that match some changes between RI's
> versus ICU's internationalization support.
> For example, I think the Thai DBBI is different, and there are some
> collation differences (i suspect this relates to
> HARMONY-5406<https://issues.apache.org/jira/browse/HARMONY-5406>
> )

Yes, again I think this beyond the spec.  As you say, Harmony defers to
the ICU project to provide the i18n functionality.  If you consider the
collation or break iterators to be producing a result that is 'wrong'
we'd raise it with ICU and get their opinion.

> I can open issues for anything we find from our unit tests that aren't
> actually bugs in Harmony, if they are of interest.

Yes, please continue to discuss them here.  As you can see, I think it
requires a debate as to which we would fix; e.g. if people agree that
the i18n is not something we want to pursue then having a non-bug
difference is useful as a record of that decision.

Regards,
Tim