RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java

[Valerie Peng]

Ok, please send me your putback comment. Otherwise, I will just use my 
own wording. ;)
Should get it done either later today or tomorrow...
Thanks,
Valerie

On 7/6/2016 11:31 AM, Alexandre (Shura) Iline wrote:
> Valerie, could you sponsor the patch for me?
>
> Shura
>
>> On Jul 6, 2016, at 10:08 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>
>>
>> Changes look fine to me.
>> Thanks,
>> Valerie
>>
>> On 7/5/2016 2:31 PM, Mandy Chung wrote:
>>>> On Jul 5, 2016, at 1:53 PM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>>>>
>>>>
>>>>> On Jul 5, 2016, at 1:36 PM, Mandy Chung <mandy.chung at oracle.com> wrote:
>>>>>
>>>>>
>>>>>> On Jul 5, 2016, at 12:42 PM, Alexandre (Shura) Iline <alexandre.iline at oracle.com> wrote:
>>>>>>
>>>>>> This made sense, than you, Mandy.
>>>>>>
>>>>>> Please review new version:
>>>>>> http://cr.openjdk.java.net/~shurailine/8158670/webrev.02/
>>>>> You can use Layer::findModule instead of Configuration::findModule.
>>>> That is correct. Changed in place.
>>>>
>>>>> You can also use List::equals.
>>>> I am assuming you are suggesting to use List::equals in the bottom part of the test where the expected result is compared with the actual list of providers. The whole reason I redid that section to provide more information in the jtr file, both for a case of a failure and to find out what providers were actually expected for given configuration. I do not see how List:equals help me with that. Information on size mismatch is useful, and also the information on unexpected provider name.
>>> What you have is fine.  The information is useful to help diagnosis.  The alternative I was thinking is to check List::equals and if not equals, do line-108-117.  It’s a minor thing and up to you.
>>>
>>> Mandy