<i18n dev> [9] RFR: 8038092: Re-examine Bidi reflective dependency on java.awt.font
Naoto Sato
naoto.sato at oracle.com
Thu Jul 3 16:59:09 UTC 2014
Ok, now I think I got what you mean. So it could regress in two ways,
one is what you wrote below, and the other I am seeing. So instead of
modifying the existing test case, I just add a new one which basically
is the same one in the previous webrev as follows:
http://cr.openjdk.java.net/~naoto/8038092/webrev.3/
This way they can detect those two possible regressions.
Naoto
On 7/3/14, 9:37 AM, Alan Bateman wrote:
> On 03/07/2014 17:16, Naoto Sato wrote:
>> With the original test case, webrev.1 and webrev.2 both succeed. With
>> the modified test case (in webrev.2), webrev.1 fails but webrev.2
>> succeeds. The reason I changed the test case is to catch possible
>> regression where someone makes changes to the SharedSecret being
>> initialized at BidiBase class loading time (as in webrev.1).
> I'm not sure that I get this, it actually looks to me that this change
> to the test could mask a problem with a future change that would break
> the shared secrets setup.
>
> -Alan
More information about the i18n-dev
mailing list