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

roger riggs roger.riggs at oracle.com
Fri Apr 25 13:32:55 UTC 2014


I think it is sufficient that the test enables the security manager, 
adding a java.util as the restricted
restricted package is not necessary.


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.

More information about the core-libs-dev mailing list