<i18n dev>  RFR: 8038092: Re-examine Bidi reflective dependency on java.awt.font
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:
This way they can detect those two possible regressions.
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.
More information about the i18n-dev