[RFR} [8u] JDK-8228440: TestAESCiphers tests fail with "access denied" trying to access ArrayUtil

[Andrew John Hughes]

On 19/07/2019 19:01, Aleksey Shipilev wrote:
> On 7/19/19 7:53 PM, Andrew John Hughes wrote:
>> On 19/07/2019 18:46, Aleksey Shipilev wrote:
>>> On 7/19/19 6:16 PM, Andrew John Hughes wrote:
>>>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8228440/webrev.01/
>>>
>>> *) It looks that test/java/util/Objects/CheckIndex.java is not in proper location now, should be
>>> somewhere in com/sun/... as well?
>>>
>>> *) I do wonder if Preconditions is now the special-cased utility class, we could eliminate some
>>> unused methods and/or their extensive Javadocs.
>>>
>>> Otherwise looks good. Let's hear what others think.
>>
>> On both points, I'm trying to minimise divergence from later versions.
>> While both may be appropriate for 8u independently (and I did consider
>> the first of these myself), they don't make any real function difference
>> and I think they'd just create unnecessary headaches if any future
>> patches touch these classes.
> 
> I understand, but once we forked those implementations, there are no "later version" anymore. These
> are private implementations now, and the simpler they are, the better.
> 

I disagree. At present, they are as close to upstream as possible, with
only the necessary changes to make them work in 8u. The changes you
suggest would be additional cosmetic changes that only serve to make the
code diverge further.

On the first point, this is also true for 11u, following JDK-8155794,
which moved the vast majority of Objects.checkIndex code into the
Preconditions class. So really, such a change to be a testcase for
Preconditions would make sense there too.

On the second point, it may be that a future backport needs such code
and we'd only have to reintroduce it. Also, looking at the JDK 11
codebase, I only see Preconditions.checkFromToIndex being used by
Objects and not ArrayUtil. So you seem to be suggesting to just remove a
couple of methods AFAICS.

Either way, I think such additional changes should be part of a separate
changeset and not thrown into this unrelated one.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew