This looks good to me. I’m wondering: what would be the consequences of class loader inheritance not reflecting module layer inheritance?
Hannes > Am 01.06.2016 um 11:14 schrieb Sundararajan Athijegannathan > <sundararajan.athijegannat...@oracle.com>: > > I had to update webrev to handle the case of appLoader being null in > ScriptLoader. I had used Class.forName(String, boolean, ClassLoader). > But that methods introduces a security check when caller is not > bootstrap (like nashorn) and ClassLoader is null! In any case, > bootloader delegation has already happened via parent delegation. So, > I'm checking and handling appLoader null case by throwing > ClassNotFoundException. > > Updated webrev: http://cr.openjdk.java.net/~sundar/8158338/webrev.01/ > > -Sundar > > On 6/1/2016 12:59 PM, Sundararajan Athijegannathan wrote: >> Hi, >> >> Thanks for the review. >> >> We have an existing test that depends on "split" delegation implemented >> in the ScriptLoader. >> >> http://hg.openjdk.java.net/jdk9/dev/nashorn/file/7fb2bf00347b/test/script/basic/JDK-8024619.js >> >> The current code adjustment is about which loader is "parent" and which >> one "side" delegatee. Previously, parent was Context's appLoader and >> side-delegatee was the structure loader. >> Now, it is other way around. But, the behavior seen from scripts should >> remain same in either case. The aforementioned test (along with other >> nashorn tests) passes with the adjusted >> delegation setup as well. >> >> -Sundar >> >> On 6/1/2016 12:49 PM, Marcus Lagergren wrote: >>> This looks good. Is it possible to test it? >>> >>> /M >>> >>>> On 01 Jun 2016, at 08:46, Sundararajan Athijegannathan >>>> <sundararajan.athijegannat...@oracle.com> wrote: >>>> >>>> Please review http://cr.openjdk.java.net/~sundar/8158338/webrev.00/ for >>>> https://bugs.openjdk.java.net/browse/JDK-8158338 >>>> >>>> Thanks, >>>> >>>> -Sundar >>>> >
