RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix)

[Peter Levart]

On 04/25/2014 03:32 PM, roger riggs wrote:
> Hi,
>
> I think it is sufficient that the test enables the security manager, 
> adding a java.util as the restricted
> restricted package is not necessary.

I think that too. Is it ok, to fix that as part of UNIXProcess merge fix 
or should there a separate issue be filed?

Regards, Peter

>
> Roger
>
> On 4/25/2014 6:44 AM, Paul Sandoz wrote:
>> On Apr 25, 2014, at 12:04 PM, Peter Levart <peter.levart at gmail.com> 
>> wrote:
>>
>>> This is a ping for any Reviewer and also a question for Vladimir.
>>>
>>> Hello Vladimir,
>>>
>>> What do you think about the classloader issue in the resolving of 
>>> classes in MemberName.getMethodType() described below?
>>>
>> I looked a bit more closely and no longer think the one-liner will is 
>> sufficient, since it will break the behaviour of 
>> MethodType.fromMethodDescriptorString:
>>
>>     public static MethodType fromMethodDescriptorString(String 
>> descriptor, ClassLoader loader)
>>         throws IllegalArgumentException, TypeNotPresentException
>>
>>     /**
>>      * Finds or creates an instance of a method type, given the 
>> spelling of its bytecode descriptor.
>>      * Convenience method for {@link #methodType(java.lang.Class, 
>> java.lang.Class[]) methodType}.
>>      * Any class or interface name embedded in the descriptor string
>>      * will be resolved by calling {@link 
>> ClassLoader#loadClass(java.lang.String)}
>>      * on the given loader (or if it is null, on the system class 
>> loader).
>>
>>
>> The observations do suggest there may be some unexpected future 
>> surprises in store for bootclasspath code in restricted packages when 
>> a SM is enabled. (The more code we can get off the boot classpath the 
>> better off we will be.... hopefully Jigsaw FTW!)
>>
>> It is be better if the jtreg process test did not monkey around with 
>> the restricted package list, it's asking for a poke in the eye!
>>
>> IMHO we should prioritize fixing the test rather than fixing the 
>> lambda code to make that test work.
>>
>> Paul.
>