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.lev...@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.
