Re: [9] RFR: 8169715: jimage fails with IAE when attempts to inspect an empty file

+1 > On Feb 13, 2017, at 1:58 PM, Denis Kononenko > wrote: > > > Hi, > > Optimized buffer's capacity checks. > > WEBREV: http://cr.openjdk.java.net/~dkononenko/8169715/webrev.02 > > >> >> Could please someone review the fix for

Re: [9] RFR: 8170120: Several new jimage testcases should be excluded due to their failures

+1 > On Nov 22, 2016, at 8:51 AM, Denis Kononenko > wrote: > > > Hi, > > Could someone please review this small fix. > > Recently several failing test cases were delivered into jdk9-dev by my > mistake (https://bugs.openjdk.java.net/browse/JDK-8167240). I've just renamed > these test case

RFR: JDK-8168256 - Plugin alias options in jlink --help output seems to be in an arbitrary order

Sorts options by full name http://cr.openjdk.java.net/~jlaskey/8168256/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8168256

RFR: JDK-8169505 - Update changes by JDK-8159393 to reflect CCC review

http://cr.openjdk.java.net/~jlaskey/8169505/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8169505

Re: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options

+1 Really nice, thank you. > On Nov 15, 2016, at 11:16 AM, Denis Kononenko > wrote: > > > Hi, > > Please do re-review for these changes. > > 1) tests for list --include were rewritten accordingly to > https://bugs.openjdk.java.net/browse/JDK-8167384; > 2) removed tests for '@filename', see

Re: [9] RFR: 8167240: Write new tests to cover functionality of existing 'jimage' options

Nice work. +1 > On Nov 3, 2016, at 10:29 AM, Denis Kononenko > wrote: > > Hi, > > I've done some rework accordingly to Alan's and Shura's comments: > > 1) removed overlapped tests from JImageToolTest.java; > > 2) added new tests JImageVerifyTest.java for jimage verify; > > 3) reorganized

Re: RFR 8071678: javax.script.ScriptContext setAttribute method should clarify behavior when GLOBAL_SCOPE is used and global scope object is null

+1 > On Oct 18, 2016, at 8:36 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8071678/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8071678 > > Thanks, > > -Sundar >

Re: RFR 8165772: fix for 8165595 results in failure of jdk/test/tools/launcher/VersionCheck.java

+1 > On Sep 12, 2016, at 9:32 AM, Sundararajan Athijegannathan > wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8165772 > > This VersionCheck.java test failed after main class was added to nashorn > modules. VersionCheck expects all jdk/bin tools to be derived from the > standard lau

RFR: JDK-8161000 - GPL header incorrect - classfile/classpath

On behalf of Swamy http://cr.openjdk.java.net/~jlaskey/8161000/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8161000

Re: RFR 8159487: Add JAVA_VERSION, OS_NAME, OS_ARCH properties in release file

+1 > On Aug 2, 2016, at 8:39 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8159487/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8159487 > > OS_NAME, OS_ARCH, OS_VERSION properties are already added due to another > fix. Just adding

RFR: JDK-8158407 - jimage: verify should do more extensive test

http://cr.openjdk.java.net/~jlaskey/8158407/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8158407

Re: [9] RFR: 8159214: jlink --include-locales problems

+1 > On Jul 18, 2016, at 12:54 PM, Naoto Sato wrote: > > Ping. > > On 7/14/16 5:42 AM, Naoto Sato wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8159214 >> >> The fix is located at: >> >> http://cr.openjdk.java.net/~naoto/

Re: RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup

rote: >> >> >>> On 11 Jul 2016, at 14:17, Jim Laskey (Oracle) >>> wrote: >>> >>> I’m not sure if we can determine supplied classes vs others unless we >>> provide a flag or the set of supplied modules. At any rate, the rules for >&

Re: RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup

h functionality is much clearer regarding > the scope of resolution. > > Paul. > > >> On 8 Jul 2016, at 17:53, Jim Laskey (Oracle) wrote: >> >> http://cr.openjdk.java.net/~jlaskey/8161067/webrev/index.html >> https://bugs.openjdk.java.net/browse/JDK-8161067 >> >

RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup

http://cr.openjdk.java.net/~jlaskey/8161067/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8161067

Re: RFR 8161055: Remove plugin ordering by isAfter, isBefore.

+1 > On Jul 8, 2016, at 8:19 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8161055/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8161055 > > Thanks > > -Sundar >

RFR: JDK-8160829 - Remove ASMPool support from jlink

Much of the removed code seems unnecessary since the same functionality can be accomplished with much simpler code. An example is provided with ClassForNamePlugin.java (temporary.) A shipping byte code optimizer plugin will be supplied later. Additional changes to the plugin API will supply a

RFR: JDK-8160459 - jlink minor code clean up

http://cr.openjdk.java.net/~jlaskey/8160459/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8160459

Re: RFR: JDK-8160348 - jlink should use System.out for usage messages

Thank you > On Jun 27, 2016, at 9:23 AM, Sundararajan Athijegannathan > wrote: > > +1 > > -Sundar > > > On 6/27/2016 5:46 PM, Jim Laskey (Oracle) wrote: >> Trivial patch >> >> http://cr.openjdk.java.net/~jlaskey/8160348/webrev/index.html &g

RFR: JDK-8160348 - jlink should use System.out for usage messages

Trivial patch http://cr.openjdk.java.net/~jlaskey/8160348/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8160348

Re: RFR 8154192: Deprivilege java.scripting module

+1 > On May 17, 2016, at 9:04 AM, Sundararajan Athijegannathan > wrote: > > Please review fix for https://bugs.openjdk.java.net/browse/JDK-8154192 > > java.scripting module is assigned to platform class loader (instead of > boot loader). And java.scripting module is given AllPermission > [prev

Re: RFR: JDK-8147460: Clean-up jrtfs implementation

+1 > On Apr 14, 2016, at 2:47 PM, Xueming Shen wrote: > > > [re-post, including jigsaw list] > > Hi, > > Please hep review the cleanup changes for jrtfs implementation. > > issue: https://bugs.openjdk.java.net/browse/JDK-8147460 > webrev: http://cr.openjdk.java.net/~sherman/8147460/webrev >

Re: Please review 8148491: Revisit jlink --genbom

+1 > On Mar 29, 2016, at 12:38 PM, Sundararajan Athijegannathan > wrote: > > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8148491/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8148491 > > Thanks, > -Sundar

Re: [9] RFR: 8146249: libjimage should use delete[] with new[]

+1 Note that these changes will be superceded (thrown out) by the Jake merge. — Jim > On Feb 2, 2016, at 3:48 PM, Artem Smotrakov > wrote: > > Hello, > > Please review this small fix for jdk9/dev repo. > > It updates a couple of files in libjimage to use delete[] operator together > with n

Re: [9] RFR: 8140649: imageFile should use delete[] with new[]

+1 > On Nov 2, 2015, at 9:30 AM, Artem Smotrakov > wrote: > > Hello, > > Please review this small fix for jdk9/dev repo. > > It updates imageFile.cpp to use delete[] operator together with new[]. It > also adds a check to ImageLocation::set_data(u1*) method to prevent a > possible null-dere

Re: RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate

I’m still missing something. How does the jrtfs code ‘know’ it’s in a jar vs part of the jdk9 runtime? > On Oct 9, 2015, at 4:37 PM, Alan Bateman wrote: > > > On 09/10/2015 20:33, Chris Hegarty wrote: >> On 9 Oct 2015, at 20:26, Alan Bateman wrote: >> >>> I looked more closely at this and

Re: RFR [9] 8139297: java.lang.NoClassDefFoundError: Could not initialize class jdk.internal.jimage.ImageNativeSubstrate

"it should never attempt to use the native implementation” This is confusing. It’s attempting to see if a native library is present otherwise use java. Is this the wrong approach? > On Oct 9, 2015, at 4:18 PM, Alan Bateman wrote: > > On 09/10/2015 19:59, Chris Hegarty wrote: >> This is a

Re: RFR: 8076090: jimage extract + recreate broken again

} } Running jprt - okay to push after that? Cheers, -- Jim > On Apr 8, 2015, at 3:37 PM, Mandy Chung wrote: > > Forwarding to core-libs-dev for review (bcc jdk9-dev) > > On 4/8/2015 11:02 AM, Jim Laskey (Oracle) wrote: >> The fix addresses probl

Re: RFR 8068462: javax.script.ScriptEngineFactory.getParameter spec is not completely consistent with the rest of the API

+1 On Jan 6, 2015, at 3:58 AM, A. Sundararajan wrote: > > > > Forwarded Message > Subject: RFR 8068462: javax.script.ScriptEngineFactory.getParameter spec > is not completely consistent with the rest of the API > Date: Tue, 06 Jan 2015 13:27:40 +0530 > From: A. Sundar

Re: RFR 8068279: (typo in the spec) javax.script.ScriptEngineFactory.getLanguageName

+1 On Jan 5, 2015, at 12:19 PM, A. Sundararajan wrote: > > > > Forwarded Message > Subject: RFR 8068279: (typo in the spec) > javax.script.ScriptEngineFactory.getLanguageName > Date: Mon, 05 Jan 2015 21:40:56 +0530 > From: A. Sundararajan > To: core-libs-dev@openjd

Re: RFR 8044647: sun/tools/jrunscript/jrunscriptTest.sh start failing: Output of jrunscript -l nashorn differ from expected output

+1 On Jun 3, 2014, at 12:26 PM, A. Sundararajan wrote: > Hi, > > Please review http://cr.openjdk.java.net/~sundar/8044647/ > > Thanks, > -Sundar

Re: Review request for 7187144: JavaDoc for ScriptEngineFactory.getProgram() contains an error

+1 On 2013-07-11, at 9:13 AM, A. Sundararajan wrote: > Bug: http://bugs.sun.com/view_bug.do?bug_id=7187144 > > Please review http://cr.openjdk.java.net/~sundar/7187144/ > > Thanks > -Sundar