RFR(S): 8150782: findClass / accessClass throw unexpected exceptions
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 -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
+1 On 3/10/2016 11:16 PM, 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
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
Hi Stanislav, thanks for all of these; see http://cr.openjdk.java.net/~mhaupt/8150782/webrev.01/ for an updated webrev. Best, Michael
Am 11.03.2016 um 14:10 schrieb stanislav lukyanov <stanislav.lukyanov@oracle.com>:
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
-- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
participants (3)
-
Michael Haupt
-
stanislav lukyanov
-
Sundararajan Athijegannathan