Re: [9] RFR 8170769: Provide a simple hexdump facility for binary data

On 8/12/2016 2:32 AM, Vincent Ryan wrote: A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I’m proposing a very simple

Re: RFR: 8170595: Optimize Class.isAnonymousClass

> On Dec 2, 2016, at 6:29 AM, Claes Redestad wrote: > > : > http://cr.openjdk.java.net/~redestad/8170595/webrev.03/ > > This brings significant improvements to some variants: Good to see the significant improvements. I think what isLocalOrAnonymousClass needs

RFR of JDK-7195382: TEST_BUG: java/rmi/activation/CommandEnvironment/SetChildEnv.java can fail

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-7195382 webrev: http://cr.openjdk.java.net/~mli/7195382/webrev.00/ what's changed? * Use createRMIDOnEphemeralPort to avoid "port in use" exception. * Because createRMIDOnEphemeralPort will choose different

RFR 8170890, Problem list tools/javadoc/CheckResourceKeys.java and tools/javadoc/ReleaseOption.java until fix for JDK-8170772

Hi, please review the patch to problem-list two tier1 tests from Linux platform. Bug: https://bugs.openjdk.java.net/browse/JDK-8170890 Thanks, Felix diff -r 586c93260d3b test/ProblemList.txt --- a/test/ProblemList.txt Mon Dec 05 15:08:24 2016 -0800 +++ b/test/ProblemList.txt

Re: RFR: 8170595: Optimize Class.isAnonymousClass

Hello, I think work like this merits some additional test development to make sure the new, faster implementation doesn't introduce any regressions in correctness. From a quick look in the java/lang/Class test directory, I didn't see any existing tests probing the correctness of

Re: RFR 8169389 : Use a bitmap to control StackTraceElement::toString format and save footprint

> On Dec 7, 2016, at 1:56 PM, Brent Christian > wrote: > > Hi, > > Please review my fix for 8169389. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8169389 > Webrev: > http://cr.openjdk.java.net/~bchristi/8169389/webrev.03/ > : Thanks for making this good

Re: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char

Hi Ivan, A few comments... Appendable.appendN default method: I'd expect many time n is small so allocating a new StringBuilder every time seems not optimal. A simple loop with append(c) would have fewer (memory) side effects. And in particular for n=0, it could avoid doing

RFR 8169389 : Use a bitmap to control StackTraceElement::toString format and save footprint

Hi, Please review my fix for 8169389. Bug: https://bugs.openjdk.java.net/browse/JDK-8169389 Webrev: http://cr.openjdk.java.net/~bchristi/8169389/webrev.03/ The addition of classloader names (JDK-6749237) updated the format of StackTraceElement.toString(). A field was added to store the

RFR 9: 8153882 rmid emits warning about security policy with obsolete URL

Please review a change to an warning message from rmid when the security policy is incorrectly configured. There is no reliable link to the rmid documentation that will remain accurate across JDK versions. The direct link is removed and expect the user to find the rmid documentation from the

Re: JDK 9 RFR of JDK-8170875: Problem list LocaleTest.java until JDK-8170840 is fixed

+1 Naoto On 12/7/16 12:36 PM, Joseph D. Darcy wrote: Hello, After the fix for JDK-8071929, the test java/util/Locale/LocaleTest.java has been failing across platforms. Until JDK-8170840 is fixed, the test should be problem listed. Patch below. Thanks, -Joe --- a/test/ProblemList.txt

Re: JDK 9 RFR of JDK-8170875: Problem list LocaleTest.java until JDK-8170840 is fixed

Looks fine Joe. On 12/7/2016 3:36 PM, Joseph D. Darcy wrote: Hello, After the fix for JDK-8071929, the test java/util/Locale/LocaleTest.java has been failing across platforms. Until JDK-8170840 is fixed, the test should be problem listed. Patch below. Thanks, -Joe ---

JDK 9 RFR of JDK-8170875: Problem list LocaleTest.java until JDK-8170840 is fixed

Hello, After the fix for JDK-8071929, the test java/util/Locale/LocaleTest.java has been failing across platforms. Until JDK-8170840 is fixed, the test should be problem listed. Patch below. Thanks, -Joe --- a/test/ProblemList.txtWed Dec 07 11:53:26 2016 -0800 +++

Re: RFR JDK-8169948 [JAXP] Update ServiceProviderTest for newDefaultInstance() methods in JAXP factories

Hi Frank, Looks good to me too. Thanks for adding tests. Best, Joe On 12/7/16, 9:35 AM, Lance Andersen wrote: Hi Frank, Looks fine Best Lance On Dec 6, 2016, at 10:15 PM, Frank Yuan > wrote: Hi all Would you like to review

Re: RFR 9: 8170291 : Unpredictable results of j.i.ObjectInputFilter::createFilter

Looks good Roger! best regards, -- daniel On 07/12/16 19:25, Roger Riggs wrote: Hi Daniel, Webrev updated in place: http://cr.openjdk.java.net/~rriggs/webrev-createfilter-8170287/ Thanks for the suggestion, expanding on the text is a better intro to the more detail spec that follows. I

Re: RFR 9: JDK 8170831: ZipFile implementation no longer caches the last accessed entry/pos

> On 7 Dec 2016, at 11:29, Xueming Shen wrote: > > Hi Paul, > > Thanks for the suggestion. Webrev has been updated accordingly. > > http://cr.openjdk.java.net/~sherman/8170831 > +1 > Sherman >

Re: RFR 9: JDK 8170831: ZipFile implementation no longer caches the last accessed entry/pos

Hi Paul, Thanks for the suggestion. Webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/8170831 Sherman On 12/7/16, 10:19 AM, Paul Sandoz wrote: Hi, 334 if (lastEntryName != null&& lastEntryName == entry.name) { Can you just do: if

Re: RFR 9: 8170291 : Unpredictable results of j.i.ObjectInputFilter::createFilter

Hi Daniel, Webrev updated in place: http://cr.openjdk.java.net/~rriggs/webrev-createfilter-8170287/ Thanks for the suggestion, expanding on the text is a better intro to the more detail spec that follows. I also received a request to give a better description of the depth and references

Re: RFR 9: JDK 8170831: ZipFile implementation no longer caches the last accessed entry/pos

Hi, 334 if (lastEntryName != null && lastEntryName == entry.name) { Can you just do: if (Objects.equals(lastEntryName, entry.name)) { // [*] ? the assumptions being entry.name is never null, which i believe is valid, and one can check the string contents if refs are not equal.

Re: RFR of JDK-8170839: failed test case is not checked in java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java

Hi Hamlin, Looks fine. Roger On 12/7/2016 1:47 AM, Hamlin Li wrote: correct the subject On 2016/12/7 14:46, Hamlin Li wrote: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8170839 webrev: http://cr.openjdk.java.net/~mli/8170839/webrev.00/ Thank

Re: RFR JDK-8169948 [JAXP] Update ServiceProviderTest for newDefaultInstance() methods in JAXP factories

Hi Frank, Looks fine Best Lance > On Dec 6, 2016, at 10:15 PM, Frank Yuan wrote: > > Hi all > > > > Would you like to review http://cr.openjdk.java.net/~fyuan/8169948/webrev.00/? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169948 > > > > This test update is

Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

This changes fdlibm, which has historically been untouched. Don't commit without Joe Darcy's approval. On Wed, Dec 7, 2016 at 7:26 AM, Lindenmaier, Goetz < goetz.lindenma...@sap.com> wrote: > Hi Dmitry, > > yes, new_jvmpath is consistent with the other variables. > I also merged the ifs in

[9] RFR 8170769: Provide a simple hexdump facility for binary data

A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I’m proposing a very simple replacement in a new and supported class:

Re: RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation

> On Dec 7, 2016, at 4:26 AM, Sergei Kovalev wrote: > > Hi Mandy, Daniel, > > Thank you for reviewing this. > > I've made a try to improve naming of variables. Also replaced row Class > declaration. Please take a look. > >

Re: [9] RFR: 8170465, 8170466: JNI exception pending in jni_util.c:190

Thanks for the review, Christoph. I too agree that the null check can be removed, but decided to keep it as a precaution as David mentioned. Naoto On 12/6/16 11:49 PM, Langer, Christoph wrote: Hi Naoto, the new webrev looks ok to me, too. Thanks for fixing. And I agree to the point that

Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

Goetz, This version of serviceability changes looks good to me. -Dmitry On 2016-12-07 18:26, Lindenmaier, Goetz wrote: > Hi Dmitry, > > yes, new_jvmpath is consistent with the other variables. > I also merged the ifs in SDE.c. > > new webrev: >

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

Hi Dmitry, yes, new_jvmpath is consistent with the other variables. I also merged the ifs in SDE.c. new webrev: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ Best regards, Goetz. > -Original Message- > From: Dmitry Samersoff

Re: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly

On 07/12/16 14:50, Chris Hegarty wrote: It is intended, as that is the code path that will be executed when the test invokes itself. Oh - right - I see it now. So looks good to me too :-) -- daniel -Chris. best regards, -- daniel On 07/12/16 14:29, Felix Yang wrote: :-) -Felix On

Re: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly

> On 7 Dec 2016, at 14:48, Daniel Fuchs wrote: > > Hi Felix, > > Looks good in general, but is > 74 return; > intended, or is that a test bug? It is intended, as that is the code path that will be executed when the test invokes itself. -Chris.

Re: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly

Hi Felix, Looks good in general, but is 74 return; intended, or is that a test bug? best regards, -- daniel On 07/12/16 14:29, Felix Yang wrote: :-) -Felix On 6 Dec 2016, at 9:28 AM, Felix Yang wrote: Add core-libs. Thanks, Felix On 2016/12/5

Re: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly

> On 7 Dec 2016, at 14:29, Felix Yang wrote: >>> ... >>> updated webrev. May I have a reviewer to review this >>> >>> http://cr.openjdk.java.net/~xiaofeya/8043838/webrev.01/ I think this is ok Felix. -Chris.

Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly

:-) -Felix > On 6 Dec 2016, at 9:28 AM, Felix Yang wrote: > > Add core-libs. > > Thanks, > Felix > On 2016/12/5 22:14, Felix Yang wrote: >> Hi, >> >> updated webrev. May I have a reviewer to review this >> >> http://cr.openjdk.java.net/~xiaofeya/8043838/webrev.01/ >>

Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

Goetz, SDE.c: You might combine if at ll. 260 and 263 to one but it's just matter of test. if (sti == baseStratumIndex || sti < 0) { return; /* Java stratum - return unchanged */ } > I'm not sure what you mean. I tried to fix it, but please > double-check the new webrev. if cnt is

Re: RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation

Looks good to me Sergei! Thanks for making this change. best regards, -- daniel On 07/12/16 12:26, Sergei Kovalev wrote: Hi Mandy, Daniel, Thank you for reviewing this. I've made a try to improve naming of variables. Also replaced row Class declaration. Please take a look.

Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

Goetz, On 2016-12-07 14:54, Lindenmaier, Goetz wrote: > Ah, you're right, the 'lastslash' assignment! In this case we have to keep strdup. Could we at least change it to something like new_jvmpath = JLI_StringDup(jvmpath); and use new_jvmpath below. And yes, the whole file is a horror.

Re: RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation

Hi Mandy, Daniel, Thank you for reviewing this. I've made a try to improve naming of variables. Also replaced row Class declaration. Please take a look. http://cr.openjdk.java.net/~skovalev/8170664/webrev.02/ -- With best regards, Sergei 07.12.16 01:03, Mandy Chung wrote: On Dec 6, 2016,

Re: RFR JDK-8169948 [JAXP] Update ServiceProviderTest for newDefaultInstance() methods in JAXP factories

Hi Frank, Looks good to me! best regards, -- daniel On 07/12/16 03:15, Frank Yuan wrote: Hi all Would you like to review http://cr.openjdk.java.net/~fyuan/8169948/webrev.00/? Bug: https://bugs.openjdk.java.net/browse/JDK-8169948 This test update is because of JDK-8169778 Add new

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

Ah, you're right, the 'lastslash' assignment! Thanks, Goetz. > -Original Message- > From: David Holmes [mailto:david.hol...@oracle.com] > Sent: Wednesday, December 07, 2016 10:32 AM > To: Lindenmaier, Goetz ; 'Dmitry Samersoff' >

Re: RFR 9: 8170291 : Unpredictable results of j.i.ObjectInputFilter::createFilter

Hi Roger, What about adding a bit of leeway in the reason for which IAE can be thrown. Here is the text from your webrev: 359 * @throws IllegalArgumentException If any of the following is true: 360 * 361 *if a limit is missing the name or the name is not

Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

On 7/12/2016 6:37 PM, Lindenmaier, Goetz wrote: Hi Dmitry, thanks for looking at my change! Updated webrev: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 * src/java.base/unix/native/libjli/java_md_solinux.c Is this line correct? 519 jvmpath =

Re: RFR 8169115, java/net/InetAddress/ptr/lookup.sh failed intermittently

Hi Dmitry, thanks for the comments. My opinions inlined... Updated webrev: http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.01/ -Felix On 2016/12/6 19:16, Dmitry Samersoff wrote: Felix, 1. I'm not sure that javaweb.sfbay.sun.com is the best domain name for this test. Could we use

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

Hi Dmitry, thanks for looking at my change! Updated webrev: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > * src/java.base/unix/native/libjli/java_md_solinux.c > Is this line correct? > 519 jvmpath = JLI_StringDup(jvmpath); It seems pointless. Should I remove