RFR(S): 8150782: findClass / accessClass throw unexpected exceptions

[stanislav lukyanov]

Hi Michael,

The comments are mostly about separating "access" and "loading".

In publicLookup():
 > which means it cannot find or access user classes
publicLookup() still can access user classes (i.e. accessClass() can 
succeed), it only can't find them.

In in():
 > Access capabilities are determined by the lookup class' class loader, 
which may change due to this operation.
"Access capabilities" -> "Loading capabilities"? (Does it sound OK, 
"loading capabilitites"? I'm not sure)
"lookup class' class loader" -> "lookup class' loader"?
Actually, I think it would be better to move the assertion below, after 
the list, so as to discuss access first,
and than give a note on loading.

In findClass()/accessClass():
 > The lookup context is determined by the class loader of the {@link 
#lookupClass()}.
I'd rather say lookup context is lookup class + its loader + lookup 
modes...
Maybe just verbose description of what is being done is the best here, like
"First a class is loaded using the lookup class' loader. Then it is 
determined if the loaded class is accessible to this lookup object"
or something like that.
accessClass() probably doesn't need to mention a class loader at all, to 
avoid confusion.

BTW, I've noticed one more thing:
 > @throws ClassNotFoundException if the class does not exist.
Maybe change to "if the class can't be loaded by the lookup class' 
loader."?

Thanks,
Stas

On 10.03.2016 20:46, Michael Haupt wrote:
> Dear all,
>
> please review this change.
> Bug: https://bugs.openjdk.java.net/browse/JDK-8150782
> Webrev: http://cr.openjdk.java.net/~mhaupt/8150782/webrev.00/
>
> The unexpected exceptions turned out to be non-issues; however it was advisable to add some explanations to the API documentation. Also, the change contains some tests that illustrate these cases.
>
> CCC approval is pending.
>
> Thanks,
>
> Michael
>