Great work! Thanks for going deep on this issue.
Is it possible to change your manual check into an automatic test? I know
sources might not be available when running a test, but if something like
${test.src}/../../../src/java.base/share/classes/sun/security/util/ exists it
can be a good hint that source codes are available.
Feel free to ignore my suggestion if this is useless. I don’t actually know if
the src directory is there in mach5 and JPRT tests.
--Max
> On Jul 12, 2017, at 2:07 PM, Hamlin Li <[email protected]> wrote:
>
> I manually checked *Resources.java under sun/security and usage of them, my
> investigation shows that overall quality of "static" resource usage is good
> (by "static" I mean it uses hard code resource string like
> rb.getString("xxxx") rather than rb.getString(aStringVariable) ), except of
> this issue and another new issue:
> https://bugs.openjdk.java.net/browse/JDK-8184234, in which similar issue in
> sun.security.provider.AuthPolicyFile$PolicyEntry is reported.
>
> For new issue JDK-8184234, it existed since jdk6 to 10.
>
> Thank you
>
> -Hamlin
>
>
> On 2017/7/12 11:36, Hamlin Li wrote:
>>
>>
>> On 2017/7/12 11:06, Weijun Wang wrote:
>>>> On Jul 12, 2017, at 11:03 AM, Hamlin Li <[email protected]> wrote:
>>>>
>>>> Hi Max,
>>>>
>>>> On 2017/7/12 10:50, Weijun Wang wrote:
>>>>> Change looks fine.
>>>>>
>>>>> Please remember to add a noreg-trivial label.
>>>> Added the label, and will push the change.
>>>>> Also, can you do some more investigation when this starts to happen? The
>>>>> bug says affected versions are 9 and 10 but PolicyFile.java has been
>>>>> there long long ago. Was there a regression?
>>>> The same code is there since jdk6
>>>> (http://hg.openjdk.java.net/jdk6/jdk6/jdk) , I did not check jdk5...
>>>> I don't think it's a regression, it should be just a missing resource, as
>>>> the failure only occurs when accessing very details of
>>>> sun.security.provider.PolicyFile by reflection, I guess people seldom do
>>>> that.
>>> Is it easy to verify?
>>>
>>> I asked if it’s a regression because I remember some time last year there
>>> is some rearrangement of codes in this area.
>> I just checked jdk6, 7, 8. You're right, there is a regression in jdk 8.
>> In summary,
>> in jdk6, the issue exists;
>> in jdk7 some resources were added which I believe fixed this issue; (too
>> many, I can not list it here.)
>> in jdk8 the added resources were totally removed, and another 2 resources
>> are added:
>> > {"duplicate.keystore.domain.name","duplicate keystore domain name:
>> > {0}"},
>> > {"duplicate.keystore.name","duplicate keystore name: {0}"},
>>
>> But currently I don't know how big the change impacts, as there are many
>> resource usage under sun/security which use
>> sun/security/util/[Resources|AuthResources].java
>>
>> sun/security/util/Resources in jdk6,
>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/62df9772b849/src/share/classes/sun/security/util/Resources.java
>> sun/security/util/Resources in jdk7,
>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/9b8c96f96a0f/src/share/classes/sun/security/util/Resources.java
>> sun/security/util/Resources in jdk8,
>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/security/util/Resources.java
>>
>> Thank you
>> -Hamlin
>>>
>>> --Max
>>>
>>>> Thank you
>>>> -Hamlin
>>>>> Thanks
>>>>> Max
>>>>>
>>>>>> On Jul 12, 2017, at 10:28 AM, Hamlin Li <[email protected]> wrote:
>>>>>>
>>>>>> Would you please review the below patch?
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8184165
>>>>>>
>>>>>> webrev: http://cr.openjdk.java.net/~mli/8184165/webrev.00/
>>>>>>
>>>>>>
>>>>>> Thank you
>>>>>>
>>>>>> -Hamlin
>>>>>>
>>
>
