On 04/25/2014 12:44 PM, 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).
Ah, yes - I missed that part. MethodType.fromMethodDescriptorString() is
public API with defined specification, so we can't change that. It is
sensible for public API to use null as the system class loader. But all
internal usages would be more correct, I think, if null meant the
bootstrap class loader. So perhaps the right fix for this is to create a
package-private variant of this method (say
parseMethodDescriptorString()) which would work as expected for internal
usage...
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.
Agreed.
Regards, Peter
