Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

> On Jun 8, 2020, at 4:07 PM, Philip Race wrote: > > Hi Kim, > > Can we amend the JEP itself to be not solely about hotspot. > Since it affects other areas I think that > 1) They may need to be compiled with C++14 enabled whether they use new > features or not > 2) They may want - or need - to

Re: RFR(S) : 8183040 : update jdk/test/lib/Platform.java to use NIO file API

Hi Brian, thank you for your review. Cheers, -- Igor > On Jun 9, 2020, at 5:18 PM, Brian Burkhalter > wrote: > > Hi Igor, > >> On Jun 9, 2020, at 4:47 PM, Igor Ignatyev > > wrote: >> >> could you please review this small clean up of testlibrary classes whic

Re: RFR(S) : 8183040 : update jdk/test/lib/Platform.java to use NIO file API

Hi Alex, as far as I can see, the caller just rethrows IOException as RuntimeException, so I don't think throwing IndexOutOfBoundsException would be much different, albeit it will be a bit more cryptic. yet given the content of /proc/sys/kernel/yama/ptrace_scope and /sys/fs/selinux/booleans/den

Re: RFR(S) : 8183040 : update jdk/test/lib/Platform.java to use NIO file API

Hi Igor, In SATestUtils.java you do var bb = ... Files.readAllBytes(...) ... and then use bb[0] if the file has 0 length, old code throws EOFException and new one will throw IndexOutOfBoundsException. And looks like the caller doesn't expect it (it catches IOException). --alex On 06/09/2020

Re: RFR(S) : 8183040 : update jdk/test/lib/Platform.java to use NIO file API

Hi Igor, > On Jun 9, 2020, at 4:47 PM, Igor Ignatyev wrote: > > could you please review this small clean up of testlibrary classes which > updates j.t.lib.Platform and j.t.l.SA.SATestUtils (as it now contains the > methods which 8183040 was about) to use NIO file API? > > testing: test/hotspo

RFR(S) : 8183040 : update jdk/test/lib/Platform.java to use NIO file API

http://cr.openjdk.java.net/~iignatyev//8183040/webrev.00 > > 38 lines changed: 8 ins; 16 del; 14 mod; Hi all, could you please review this small clean up of testlibrary classes which updates j.t.lib.Platform and j.t.l.SA.SATestUtils (as it now contains the methods which 8183040 was about) to

Re: RFR: 8233215: jpackage doesn't allow enough flexibility for file type binding

+1 - Alexey On 6/9/2020 6:33 PM, Andy Herrick wrote: looks good /Andy On 6/9/2020 6:12 PM, alexander.matv...@oracle.com wrote: Hi Andy, http://cr.openjdk.java.net/~almatvee/8233215/webrev.02/ Moved new mac specific parameters to MacAppImageBuilder. Thanks, Alexander On 6/9/20 4:41 AM, An

RFR 8247274: (test) HexPrinter cleanup

Please review cleanup to the test support for jdk.test.lib.hexprinter.HexPrinter. Correct issues with the test support for jdk.test.lib.hexdump.HexPrinter.  - Correct the swapped definitions of Formatters.ASCII and PRINTABLE    Printable should always return a single character,    ASCII provides

Re: RFR: 8233215: jpackage doesn't allow enough flexibility for file type binding

looks good /Andy On 6/9/2020 6:12 PM, alexander.matv...@oracle.com wrote: Hi Andy, http://cr.openjdk.java.net/~almatvee/8233215/webrev.02/ Moved new mac specific parameters to MacAppImageBuilder. Thanks, Alexander On 6/9/20 4:41 AM, Andy Herrick wrote: I would think the new mac specific Bun

Re: Thread leak by LdapLoginModule

Adding core-libs-dev ... --Sean On 6/9/20 5:15 PM, Mkrtchyan, Tigran wrote: Hi all, with Java-11 we have notice a thread leak with ldap module. We use LDAP to authenticate users with username+pasword by directly calling LdapLoginModule. This was ok with java 7 and java 8. With java 11 we see

Re: RFR: 8233215: jpackage doesn't allow enough flexibility for file type binding

Hi Andy, http://cr.openjdk.java.net/~almatvee/8233215/webrev.02/ Moved new mac specific parameters to MacAppImageBuilder. Thanks, Alexander On 6/9/20 4:41 AM, Andy Herrick wrote: I would think the new mac specific BundlerParamInfo would be defined in MacAppImageBuilder instead of StandardBund

ConcurrentSkipListMap design question

Hi all, I’ve been trying to understand ConcurrentSkipListMap’s design, and noticed this comment in the source [1]: “This class implements a tree-like two-dimensionally linked skip list in which the index levels are represented in separate nodes from the base nodes holding data. There are two re

Re: [15] RFR: 8246662: Test java/time/test/java/time/format/TestUnicodeExtension.java failed on japanese locale.

Thanks Roger, Naoto. On 6/9/2020 12:53 PM, Roger Riggs wrote: Hi, All java.time instances are immutable and described as value based. Identity based operations are defined as unpredictable and to be avoided. (That specific text was omitted from DateTimeFormatter) The test uses .equals so it is

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hello Aleks, Thank you very much for review. I’ve fixed missed spaces and removed casting from LdapSasl.java Failure of the SaslMutual test was caused by prop.remove() in the GssKrb5Client This operation is not required any more. GssKrb5Client receives temporary copy of the properties. Fixed Al

Re: RFR [15/java.xml] 8237456: Transform filtered through SAX filter mishandles character entities

Thanks Aleksei, Lance! I'm using NetBeans, but I may get back to Intellij once my new machine arrives :-) -Joe On 6/9/2020 5:41 AM, Lance Andersen wrote: Hi Joe, This looks good. For your test,  Intellij typically suggests using a static import for Assert: —— import static org.testn

Re: [15] RFR: 8246662: Test java/time/test/java/time/format/TestUnicodeExtension.java failed on japanese locale.

Hi, All java.time instances are immutable and described as value based. Identity based operations are defined as unpredictable and to be avoided. (That specific text was omitted from DateTimeFormatter) The test uses .equals so it is not depending on identity. Roger On 6/9/20 3:10 PM, naoto.s.

Re: [15] RFR: 8246662: Test java/time/test/java/time/format/TestUnicodeExtension.java failed on japanese locale.

Hi Joe, On 6/9/20 11:54 AM, Joe Wang wrote: Looks fine to me for the implementation of the method. Thank you for the review! It's interesting to observe that the with methods, as demonstrated in the test, always create a new DateTimeFormatter instance. The Javadoc also said so, e.g. "

Re: [15] RFR: 8246662: Test java/time/test/java/time/format/TestUnicodeExtension.java failed on japanese locale.

On 6/9/2020 10:01 AM, naoto.s...@oracle.com wrote: Hi Roger, Thanks for the review. On 6/9/20 8:52 AM, Roger Riggs wrote: Hi Naoto, Since the default locale is being changed even briefly, the test should be run in /othervm. Add:  @run testng/othervm ... All java/time/test/java/time/for

Re: JPackage with a modular application fails to load record class files even with --enable-preview

Relevant StackOverlow question: https://stackoverflow.com/questions/61504956/records-in-jlinked-application-throws-exception It talks about JLink, but the error message is the same, so I expect the same root cause: The ASM version shipped with JDK 14 doesn't support records yet. It is already

Re: [15] RFR: 8246662: Test java/time/test/java/time/format/TestUnicodeExtension.java failed on japanese locale.

Thanks! On 6/9/20 11:48 AM, Roger Riggs wrote: Hi Naoto, Looks fine. fyi,  Objects.equals(a,b) can replace DateTimeFormatter: 1510-1511. Right. I will replace it before the push. Naoto Thanks, Roger On 6/9/20 1:01 PM, naoto.s...@oracle.com wrote: Hi Roger, Thanks for the review. On 6

Re: [15] RFR: 8246662: Test java/time/test/java/time/format/TestUnicodeExtension.java failed on japanese locale.

Hi Naoto, Looks fine. fyi,  Objects.equals(a,b) can replace DateTimeFormatter: 1510-1511. Thanks, Roger On 6/9/20 1:01 PM, naoto.s...@oracle.com wrote: Hi Roger, Thanks for the review. On 6/9/20 8:52 AM, Roger Riggs wrote: Hi Naoto, Since the default locale is being changed even briefly,

Re: RFR: 8246129: ZIP entries created for DOS epoch include local timezone metadata

Hi Martin, I believe the fix keeps compatibility with the previous fixes in this area(see 4759491 8015666 and 8073497). If you have an alternative suggestion please let us know. > On Jun 9, 2020, at 11:51 AM, Martin Buchholz wrote: > > not really a review, but cautions: > > I was afraid t

Re: [PATCH] 8246633: Improve the performance of ObjectInputStream.resolveClass(ObjectStreamClass)

Hi Peter, This is not a review. I second Roger's observations. On 05/06/2020 00:08, Peter Kessler OS wrote: Tested with `make run-test-tier1` on Linux (CentOS 7) on both aarch64 and x86_64. I had one failure on each of the runs The code you are proposing to change affects RMI and JMX too. F

Re: RFR: 8246129: ZIP entries created for DOS epoch include local timezone metadata

Hi, On 2020-06-09 17:51, Martin Buchholz wrote: not really a review, but cautions: I was afraid that might be hard to fix because DOSTIME_BEFORE_1980 was used as a special value indicating that the real time was < 1980 and stored in an extra field. But I guess we now don't have any code that m

Re: [15] RFR: 8246662: Test java/time/test/java/time/format/TestUnicodeExtension.java failed on japanese locale.

Hi Roger, Thanks for the review. On 6/9/20 8:52 AM, Roger Riggs wrote: Hi Naoto, Since the default locale is being changed even briefly, the test should be run in /othervm. Add:  @run testng/othervm ... All java/time/test/java/time/format tests are run in othervm mode by default, defined

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

On 6/9/20 12:40 PM, Xuelei Fan wrote: About the prefix, it may follow RFC 5056 (See page 7, section 2.1).    o  Specifications of channel bindings for any secure channels MUST   provide for a single, canonical octet string encoding of the   channel bindings.  Under this framework, chan

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

About the prefix, it may follow RFC 5056 (See page 7, section 2.1). o Specifications of channel bindings for any secure channels MUST provide for a single, canonical octet string encoding of the channel bindings. Under this framework, channel bindings MUST start with the cha

Re: RFR [15] 8247115: Fix typos in java.lang.invoke and java.lang

Looks good. Mandy On 6/9/20 3:42 AM, Pavel Rappo wrote: Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8247115 http://cr.openjdk.java.net/~prappo/8247115/webrev.00/ The patch fixes 11 typos in doc comments and 2 typos in code. The typos in code are in except

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hello Sean, Thank you for the link. I’ll follow it to create CSR I could not find any clear document or specification for this Channel Binding format. The only document I found that describes this format is the following: https://docs.microsoft.com/en-us/archive/blogs/openspecification/ntlm-and-

Re: [15] RFR: 8246662: Test java/time/test/java/time/format/TestUnicodeExtension.java failed on japanese locale.

Hi Naoto, Since the default locale is being changed even briefly, the test should be run in /othervm. Add:  @run testng/othervm ... DateTimeFormatter:1498:    Can the optimization be retained in the case where z.equals(zone)?    Move it down to 1508+ and check the zone vs z. Thanks, Roger

Re: RFR: 8246129: ZIP entries created for DOS epoch include local timezone metadata

not really a review, but cautions: I was afraid that might be hard to fix because DOSTIME_BEFORE_1980 was used as a special value indicating that the real time was < 1980 and stored in an extra field. But I guess we now don't have any code that makes assumptions based only on DOSTIME_BEFORE_1980?

Re: Comparator.reversed() type inference issue

Hello! > I don't see how you can fix it even with a lot of dust of magic stars, > you have only the type information of the return value of > Map.Entry.comparingByValue().reversed() > > but they can no travel backward to Map.Entry.comparingByValue() because you > have no idea of the return type

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

On 6/8/20 5:33 PM, Alexey Bakhtin wrote: Hello Sean, Yes, I think we'll need CSR and release notes as soon as this patch adds new property. I do not know exact process for it, so I will be grateful if you could explain me exact steps. The CSR process is documented at https://wiki.openjdk.ja

Re: JPackage with a modular application fails to load record class files even with --enable-preview

I tried a simple testcase with 14.0.2 and with 15, and if failed as indicated with 14.0.2 but worked fine in 15. /Andy On 6/9/2020 10:53 AM, Johannes Kuhn wrote: Relevant StackOverlow question: https://stackoverflow.com/questions/61504956/records-in-jlinked-application-throws-exception It ta

RFR: 8246129: ZIP entries created for DOS epoch include local timezone metadata

Hi, this patch addresses a corner case where extra time stamp information is added when using start of the DOS time epoch (1980-01-01 00:00:00) as a dummy timestamp for entries Bug:https://bugs.openjdk.java.net/browse/JDK-8246129 Webrev: http://cr.openjdk.java.net/~redestad/8246129/open.00/

Re: JPackage with a modular application fails to load record class files even with --enable-preview

So when you use the jpackage option "--java-options --enable-preview" it appears to work with a non-modular jar, but not with a modular jar ? I think I can create a testcase for that. Have you tried it with the jpackage from a preview release of JDK15  (https://jdk.java.net/15/) ? Can you lo

Re: RFR [15] 8247212: Use assistant markup in java.lang.module.ModuleDescriptor

On 09/06/2020 14:33, Pavel Rappo wrote: Thanks, Alan. Here's the updated webrev: http://cr.openjdk.java.net/~prappo/8247212/webrev.01/ Thanks, this looks good to me. -Alan

Re: [PATCH] 8246633: Improve the performance of ObjectInputStream.resolveClass(ObjectStreamClass)

Hi Peter, I'd like to understand the scope and impact of the problem before jumping to a solution. For specific applications, overriding ObjectInputStream.resolveClass to handle the class lookup can handle the case as expeditiously as is necessary. What application uses cases are impacted and

Re: RFR [15] 8247212: Use assistant markup in java.lang.module.ModuleDescriptor

Thanks, Alan. Here's the updated webrev: http://cr.openjdk.java.net/~prappo/8247212/webrev.01/ > On 9 Jun 2020, at 13:33, Alan Bateman wrote: > > On 09/06/2020 13:15, Pavel Rappo wrote: >> Hello, >> >> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8247212 >> >> h

Re: RFR [15] 8247115: Fix typos in java.lang.invoke and java.lang

Thanks, Lance. Testing tiers 1, 2, and 3 has shown no errors. If anyone else wants to chime in, please do so within the next couple of hours. -Pavel > On 9 Jun 2020, at 13:36, Lance Andersen wrote: > > Hi Pavel, > > The changes look good > > Best > Lance > >> On Jun 9, 2020, at 6:42 AM, Pa

Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos

Hi Alexey, Thank you for incorporating LdapCtx and LdapSasl changes. I've reviewed both classes and they look good to me, with few minor comments in LdapSasl.java:   missing spaces in the following lines: 78, 152   With your last changes we can remove explicit cast of 'envProps' on li

Re: RFR [15/java.xml] 8237456: Transform filtered through SAX filter mishandles character entities

Hi Joe, This looks good. For your test, Intellij typically suggests using a static import for Assert: —— import static org.testng.Assert.*; — No need to change but typically which get suggested when you run Inspect Code Best Lance > On Jun 9, 2020, at 1:54 AM, Joe Wang wrote: >

Re: RFR: 8233215: jpackage doesn't allow enough flexibility for file type binding

Looks good. - Alexey On 6/9/2020 2:28 AM, alexander.matv...@oracle.com wrote: Hi Alexey, http://cr.openjdk.java.net/~almatvee/8233215/webrev.01/ - TKit.assertStringListEquals() will be used instead. Did not noticed that we had this method already. I removed my implementation. - Added "mac."

Re: RFR [15] 8247115: Fix typos in java.lang.invoke and java.lang

Hi Pavel, The changes look good Best Lance > On Jun 9, 2020, at 6:42 AM, Pavel Rappo wrote: > > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8247115 > > http://cr.openjdk.java.net/~prappo/8247115/webrev.00/ > > The patch fixes 11 typos in doc comments an

Re: RFR [15] 8247212: Use assistant markup in java.lang.module.ModuleDescriptor

On 09/06/2020 13:15, Pavel Rappo wrote: Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8247212 http://cr.openjdk.java.net/~prappo/8247212/webrev.00/ The patch adds markup that makes it easier to read documentation in cases where code and prose are mixed. The p

Re: RFR [15/java.xml] 8237456: Transform filtered through SAX filter mishandles character entities

Hi Joe, The changes looks good to me. Best, Aleksei On 09/06/2020 06:54, Joe Wang wrote: Hi, Please review a fix to a regression that resulted in invalid output in a transform that contains entity references. The regression was caused by a JDK9 patch [1]. Adding back the conditional checks

RFR [15] 8247212: Use assistant markup in java.lang.module.ModuleDescriptor

Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8247212 http://cr.openjdk.java.net/~prappo/8247212/webrev.00/ The patch adds markup that makes it easier to read documentation in cases where code and prose are mixed. The patch also fixes a few typos. -Pavel

Re: contributing to JDK-8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end

Hi Raffaello, This bug is not currently being worked on so feel free to provide a fix and test Best Lance > On Jun 9, 2020, at 3:20 AM, Raffaello Giulietti > wrote: > > Hi Lance, > > before working on a fix, I just wanted to make sure that I'm not interfering > with existing efforts. Thus,

Re: RFR: 8233215: jpackage doesn't allow enough flexibility for file type binding

I would think the new mac specific BundlerParamInfo would be defined in MacAppImageBuilder instead of StandardBundlerParam*. * Am I missing something ? /Andy ** * * On 6/9/2020 1:12 AM, alexander.matv...@oracle.com wrote: Please review the jpackage fix for bug [1] at [2]. Added support for

RFR [15] 8247115: Fix typos in java.lang.invoke and java.lang

Hello, Please review the change for https://bugs.openjdk.java.net/browse/JDK-8247115 http://cr.openjdk.java.net/~prappo/8247115/webrev.00/ The patch fixes 11 typos in doc comments and 2 typos in code. The typos in code are in exception messages. Testing results are pending. -Pavel

Re: Comparator.reversed() type inference issue

- Mail original - > De: "Tagir Valeev" > À: "Attila Szegedi" > Cc: "core-libs-dev" > Envoyé: Mardi 9 Juin 2020 09:05:42 > Objet: Re: Comparator.reversed() type inference issue > Hello! > > This is more related to Java language specification and implementation > than to core libraries,

Re: Comparator.reversed() type inference issue

yep, the inference is not smart enough. So the way to fix the code is either to explicitly specify the type arguments var rs1 = x.entrySet().stream().sorted( Map.Entry.comparingByValue().reversed() ); or to store the result of comparingByValue() in a variable (so it's a poly express

Re: contributing to JDK-8222187: java.util.Base64.Decoder stream adds unexpected null bytes at the end

Hi Lance, before working on a fix, I just wanted to make sure that I'm not interfering with existing efforts. Thus, I don't have a fix, yet. I'll be using the example provided in the bug report as a basic test. I'll show up here once the fix is ready. Greetings Raffaello On 2020-06-08 22

Re: Comparator.reversed() type inference issue

Hello! This is more related to Java language specification and implementation than to core libraries, so compiler-dev is a more relevant mailing list. The current behavior perfectly follows the specification (JLS, 15.12): A method invocation expression is a poly expression if all of the following