Re: [jdk17] RFR: 8269185: Directories in /opt/runtimepackagetest and /path/to/jdk-17 are different

On Fri, 2 Jul 2021 22:17:09 GMT, Alexey Semenyuk wrote: > Disable stripping to prevent rpmbuild from modifying executables Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/207

Integrated: Merge jdk17

On Fri, 2 Jul 2021 19:34:35 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 17 -> JDK 18 This pull request has now been integrated. Changeset: 17f53f2f Author:Jesper Wilhelmsson URL: https://git.openjdk.java.net/jdk/commit/17f53f2f9c5928395eff9186160924e9a8e9a794 Stats: 341 li

Re: RFR: 8268974: GetJREPath() JLI function fails to locate libjava.so if not standard Java launcher is used

On Sun, 20 Jun 2021 07:25:54 GMT, Alan Bateman wrote: >> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" >> component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() >> looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" >> strin

Re: RFR: 8214761: Bug in parallel Kahan summation implementation

On Fri, 2 Jul 2021 20:30:24 GMT, Andrew Haley wrote: > Crikey, how did we get that wrong? > It'd be nice if we had a regression test for this. Can you provide one, > please? I found this: https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057239.html Ivan Gerasimov already tac

[jdk17] RFR: 8269185: Directories in /opt/runtimepackagetest and /path/to/jdk-17 are different

Disable stripping to prevent rpmbuild from modifying executables - Commit messages: - Disable executables stripping Changes: https://git.openjdk.java.net/jdk17/pull/207/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17&pr=207&range=00 Issue: https://bugs.openjdk.java.net

Re: RFR: 8214761: Bug in parallel Kahan summation implementation

On Fri, 2 Jul 2021 20:12:39 GMT, Ian Graves wrote: > 8214761: Bug in parallel Kahan summation implementation What about `Collectors.computeFinalSum()` - should this be `double tmp = summands[0] + summands[1];` or `double tmp = summands[0] - summands[1];` ? - PR: https://git.openjd

Re: RFR: 8214761: Bug in parallel Kahan summation implementation

On Fri, 2 Jul 2021 20:12:39 GMT, Ian Graves wrote: > 8214761: Bug in parallel Kahan summation implementation src/java.base/share/classes/java/util/DoubleSummaryStatistics.java line 161: > 159: > 160: //Negating this value because low-order bits are in negated form > 161: sumWit

Re: [jdk17] RFR: 8269281: java/foreign/TestUpcall.java times out

On Thu, 1 Jul 2021 21:11:44 GMT, Maurizio Cimadamore wrote: > The previous fix to this test which used removed the `VerifyDependency` flag > worked well, but we're still observing rare timeouts. Looking at the test > reports, it seems likely that slightly increasing the timeout would do the >

[jdk17] Withdrawn: 8269281: java/foreign/TestUpcall.java times out

On Thu, 1 Jul 2021 21:11:44 GMT, Maurizio Cimadamore wrote: > The previous fix to this test which used removed the `VerifyDependency` flag > worked well, but we're still observing rare timeouts. Looking at the test > reports, it seems likely that slightly increasing the timeout would do the >

Re: RFR: 8214761: Bug in parallel Kahan summation implementation

On Fri, 2 Jul 2021 20:12:39 GMT, Ian Graves wrote: > 8214761: Bug in parallel Kahan summation implementation Crikey, how did we get that wrong? It'd be nice if we had a regression test for this. Can you provide one, please? - PR: https://git.openjdk.java.net/jdk/pull/4674

RFR: 8214761: Bug in parallel Kahan summation implementation

8214761: Bug in parallel Kahan summation implementation - Commit messages: - 8214761: Bug in parallel Kahan summation implementation Changes: https://git.openjdk.java.net/jdk/pull/4674/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4674&range=00 Issue: https://bugs.o

Integrated: 8268664: The documentation of the Scanner.hasNextLine is incorrect

On Tue, 22 Jun 2021 04:22:34 GMT, Ian Graves wrote: > 8268664: The documentation of the Scanner.hasNextLine is incorrect This pull request has now been integrated. Changeset: 0d0f6a4b Author:Ian Graves URL: https://git.openjdk.java.net/jdk/commit/0d0f6a4becfb14304f6cea9d3a1d113f0492

RFR: Merge jdk17

Forwardport JDK 17 -> JDK 18 - Commit messages: - Merge - 8269768: JFR Terminology Refresh - 8269775: compiler/codegen/ClearArrayTest.java failed with "assert(false) failed: bad AD file" - 8269543: The warning for System::setSecurityManager should only appear once for each calle

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

On Fri, 2 Jul 2021 19:08:09 GMT, Brian Burkhalter wrote: >> Right. I understand. The intention was, unlike the overridden method that >> returns 0 if len == 0 and -1 if at the end of the stream, this method >> returns -1 in both cases. A careful reader, after comparing both methods, >> would u

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter wrote: >> Modify the specification of >> `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is >> returned instead of `0` when the stream is at its end and the third >> parameter, `len`, is zero. > > Brian Burkhalter has

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

On Fri, 2 Jul 2021 18:43:36 GMT, Joe Wang wrote: >> Both conditions of the statement are intended to be met. If the stream is at >> its end then >> >> if (pos >= count) { >> return -1; >> } >> >> will cause `-1` to be returned because at end of stream the condition

RE: Methods removeFirstIf in Collection and skipFirst in Stream

Hi, In my case, I have a list of entities related to another entity. In that list obviously there weren't repeated entities (entities with the same id). And I have the id of an entity to be removed from that list. So, I have the following alternatives which are pretty inefficient: 1) entityLis

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

On Fri, 2 Jul 2021 17:40:08 GMT, Brian Burkhalter wrote: >> src/java.base/share/classes/java/io/ByteArrayInputStream.java line 161: >> >>> 159: * Unlike the {@link InputStream#read(byte[],int,int) overridden >>> method} >>> 160: * of {@code InputStream}, this method returns {@code -1}

Re: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside [v4]

On 02/07/2021 18:16, Lance Andersen wrote: : That being said, if we want to follow Alan’s suggestion and throw an Exception, I am OK with that as well. Either way, we currently cannot access the file via Zip FS due to the call to ZipPath::getResolvedPath() for all access and the path is only

Integrated: 8188046: java.lang.Math.mutliplyHigh does not run in constant time

On Thu, 1 Jul 2021 23:46:00 GMT, Brian Burkhalter wrote: > Please consider this proposal to remove the fast path in > `java.lang.Math.multiplyHigh()` the small performance improvement of which is > eclipsed by the branch penalty. This pull request has now been integrated. Changeset: cb795893

Integrated: 8188044: We need Math.unsignedMultiplyHigh

On Wed, 30 Jun 2021 23:13:06 GMT, Brian Burkhalter wrote: > Please consider this proposal to add a method > `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and > `java.lang.StrictMath`. This pull request has now been integrated. Changeset: ca4bea46 Author:Brian Burkhalter U

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v4]

On Fri, 2 Jul 2021 16:41:16 GMT, Brian Burkhalter wrote: >> Please consider this proposal to add a method >> `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and >> `java.lang.StrictMath`. > > Brian Burkhalter has refreshed the contents of this pull request, and > previous commits

Re: Methods removeFirstIf in Collection and skipFirst in Stream

Hello! It's unclear why one might need methods like this. Could you please provide any real life use cases when such methods could be useful? Thanks. With best regards, Tagir Valeev. пт, 2 июл. 2021 г., 21:28 Alberto Otero Rodríguez : > Sorry for the links, the methods would be: > > 1) In Colle

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

On Fri, 2 Jul 2021 17:27:34 GMT, Joe Wang wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 6766844: Correct error messages in test > > src/java.base/share/classes/java/io/ByteArrayInputStream.java line 161: > >

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter wrote: >> Modify the specification of >> `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is >> returned instead of `0` when the stream is at its end and the third >> parameter, `len`, is zero. > > Brian Burkhalter has

Re: RFR: 8188046: java.lang.Math.mutliplyHigh does not run in constant time

On Thu, 1 Jul 2021 23:46:00 GMT, Brian Burkhalter wrote: > Please consider this proposal to remove the fast path in > `java.lang.Math.multiplyHigh()` the small performance improvement of which is > eclipsed by the branch penalty. Marked as reviewed by darcy (Reviewer). - PR: http

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter wrote: >> Modify the specification of >> `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is >> returned instead of `0` when the stream is at its end and the third >> parameter, `len`, is zero. > > Brian Burkhalter has

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

On Fri, 2 Jul 2021 16:58:18 GMT, Brian Burkhalter wrote: >> Modify the specification of >> `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is >> returned instead of `0` when the stream is at its end and the third >> parameter, `len`, is zero. > > Brian Burkhalter has

Re: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside [v4]

On Jul 2, 2021, at 12:13 PM, Lance Andersen mailto:lance.ander...@oracle.com>> wrote: On Jul 2, 2021, at 8:08 AM, Jaikiran Pai mailto:jai.forums2...@gmail.com>> wrote: Hello Lance, On 02/07/21 4:42 pm, Lance Andersen wrote: Hi Jaikiran, Consider: try (var os = Files.newOutputStr

Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]

On Fri, 2 Jul 2021 08:58:35 GMT, Peter Levart wrote: >> Well, "determine" seems to have both meanings: >> https://www.google.com/search?q=determine >> So by the 2nd meaning, it is good. > > ... and considering the "Schrödinger's cat", even the 1st interpretation is > correct. You can't know whet

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

On Fri, 2 Jul 2021 16:50:11 GMT, Naoto Sato wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 6766844: Correct error messages in test > > test/jdk/java/io/ByteArrayInputStream/ReadAllReadNTransferTo.java line 57:

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

On Fri, 2 Jul 2021 16:55:18 GMT, Brian Burkhalter wrote: >> Modify the specification of >> `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is >> returned instead of `0` when the stream is at its end and the third >> parameter, `len`, is zero. > > Brian Burkhalter has

Re: [jdk17] RFR: 6766844: ByteArrayInputStream#read with a byte array of length 0 not consistent with InputStream when at EOF [v2]

> Modify the specification of > `java.io.ByteArrayInputStream#read(byte[],int,int)` to indicate that `-1` is > returned instead of `0` when the stream is at its end and the third > parameter, `len`, is zero. Brian Burkhalter has updated the pull request incrementally with one additional commit

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v4]

> Please consider this proposal to add a method > `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and > `java.lang.StrictMath`. Brian Burkhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences com

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v4]

On Fri, 2 Jul 2021 16:37:21 GMT, Brian Burkhalter wrote: >> Please consider this proposal to add a method >> `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and >> `java.lang.StrictMath`. > > Brian Burkhalter has refreshed the contents of this pull request, and > previous commits

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v3]

> Please consider this proposal to add a method > `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and > `java.lang.StrictMath`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8188044: Use multiplyHigh() to glevera

Re: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside [v4]

On Jul 2, 2021, at 8:08 AM, Jaikiran Pai mailto:jai.forums2...@gmail.com>> wrote: Hello Lance, On 02/07/21 4:42 pm, Lance Andersen wrote: Hi Jaikiran, Consider: try (var os = Files.newOutputStream(ZIPFILE); ZipOutputStream zos = new ZipOutputStream(os)) { zo

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]

On 7/2/21 4:30 PM, Raffaello Giulietti wrote: > FWIW, adinn's branchless code together with > PR https://git.openjdk.java.net/jdk/pull/4660 > make both methods less vulnerable to timing attacks. I doubt it, because HotSpot generates conditional select instructions for the popular systems, at least

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]

On 02/07/2021 16:30, Raffaello Giulietti wrote: FWIW, adinn's branchless code together with PR https://git.openjdk.java.net/jdk/pull/4660 make both methods less vulnerable to timing attacks. That was indeed the point of the change. However, I doubt the difference in timing is going to be signifi

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]

FWIW, adinn's branchless code together with PR https://git.openjdk.java.net/jdk/pull/4660 make both methods less vulnerable to timing attacks. Greetings Raffaello On 2021-07-02 15:50, Andrew Haley wrote: On Fri, 2 Jul 2021 11:06:06 GMT, Andrew Dinn wrote: You can also do that branchlessly

Re: RFR: 8269124: Update java.time to use switch expressions (part II) [v6]

> Hi, > > Could someone please review the second half of my update for the `java.time` > package to make use of switch expressions? > > This PR was split into two parts due to the large number of files affected. > > Kind regards, > > Patrick Patrick Concannon has updated the pull request with

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]

On 7/2/21 12:26 PM, Raffaello Giulietti wrote: > ... or even as a one liner, like in the test > > return Math.multiplyHigh(x, y) + ((x >> (Long.SIZE - 1)) & y) + ((y >> > (Long.SIZE - 1)) & x); It was hard to write, so it should be hard to read too! :-)

[jdk17] Integrated: 8269543: The warning for System::setSecurityManager should only appear once for each caller

On Mon, 28 Jun 2021 21:09:43 GMT, Weijun Wang wrote: > Add a cache to record which sources have called `System::setSecurityManager` > and only print out warning lines once for each. This pull request has now been integrated. Changeset: c4ea13ed Author:Weijun Wang URL: https://git.o

RE: Methods removeFirstIf in Collection and skipFirst in Stream

Sorry for the links, the methods would be: 1) In Collection: default boolean removeFirstIf​(Predicatehttps://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/Collection.html>> filter) 2) In Stream: Stream skipFirst(Predicatehttps://docs.oracle.com/en/java/java

Methods removeFirstIf in Collection and skipFirst in Stream

Hi, I think it would be interesting adding the following methods: 1) In Collection: default boolean removeFirstIf​(Predicatehttps://docs.oracle.com/en/java/javase/16/docs/api/java.base/java

Re: RFR: 8188046: java.lang.Math.mutliplyHigh does not run in constant time

On Thu, 1 Jul 2021 23:46:00 GMT, Brian Burkhalter wrote: > Please consider this proposal to remove the fast path in > `java.lang.Math.multiplyHigh()` the small performance improvement of which is > eclipsed by the branch penalty. Marked as reviewed by rriggs (Reviewer). - PR: htt

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]

On Fri, 2 Jul 2021 13:47:40 GMT, Andrew Haley wrote: >> You can also do that branchlessly which might prove better >> >> long result = Math.multiplyHigh(x, y); >> result += (y & (x >> 63)); >> result += (x & (y >> 63)); >> return result; > >> You can also do t

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]

On Fri, 2 Jul 2021 11:06:06 GMT, Andrew Dinn wrote: > You can also do that branchlessly which might prove better > > ``` > long result = Math.multiplyHigh(x, y); > result += (y & (x >> 63)); > result += (x & (y >> 63)); > return result; > ``` I doubt very much that it would b

Re: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside [v4]

On 02/07/2021 13:08, Jaikiran Pai wrote: Thank you for noticing this issue in my change and bringing this up. I have a question around this use case. Please consider a small variation to your example as below: try (var os = Files.newOutputStream(ZIPFILE); ZipOutputStream zos = n

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller [v2]

On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang wrote: >> Add a cache to record which sources have called `System::setSecurityManager` >> and only print out warning lines once for each. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision

Re: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside [v4]

Hello Lance, On 02/07/21 4:42 pm, Lance Andersen wrote: Hi Jaikiran, Consider: try (var os = Files.newOutputStream(ZIPFILE); ZipOutputStream zos = new ZipOutputStream(os)) { zos.putNextEntry(new ZipEntry("../Hello.txt")); zos.write("Hello World

Re: [jdk17] RFR: 8269543: The warning for System::setSecurityManager should only appear once for each caller [v2]

On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang wrote: >> Add a cache to record which sources have called `System::setSecurityManager` >> and only print out warning lines once for each. > > Weijun Wang has updated the pull request incrementally with one additional > commit since the last revision

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]

... or even as a one liner, like in the test return Math.multiplyHigh(x, y) + ((x >> (Long.SIZE - 1)) & y) + ((y >> (Long.SIZE - 1)) & x); On 2021-07-02 13:08, Andrew Dinn wrote: On Fri, 2 Jul 2021 09:39:46 GMT, Andrew Haley wrote: src/java.base/share/classes/java/lang/Math.java line 12

Re: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside [v4]

On Fri, 2 Jul 2021 11:06:40 GMT, Jaikiran Pai wrote: >> Can I please get a review of this proposed fix for >> https://bugs.openjdk.java.net/browse/JDK-8251329? >> >> As noted in that issue, if a zip filesystem created on top of a jar >> containing a "./" entry is "walked" using the `Files.walk

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]

On Fri, 2 Jul 2021 09:39:46 GMT, Andrew Haley wrote: >> src/java.base/share/classes/java/lang/Math.java line 1211: >> >>> 1209: long z1 = t >>> 32; >>> 1210: >>> 1211: return x1 * y1 + z1 + (z0 >>> 32); >> >> Suggestion: >> >> long result = Math.multiplyHigh(x, y); >>

Re: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside [v4]

> Can I please get a review of this proposed fix for > https://bugs.openjdk.java.net/browse/JDK-8251329? > > As noted in that issue, if a zip filesystem created on top of a jar > containing a "./" entry is "walked" using the `Files.walkFileTree`, it leads > to a infinite never ending iteration

Re: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside [v3]

On Fri, 2 Jul 2021 10:25:29 GMT, Jaikiran Pai wrote: >> Can I please get a review of this proposed fix for >> https://bugs.openjdk.java.net/browse/JDK-8251329? >> >> As noted in that issue, if a zip filesystem created on top of a jar >> containing a "./" entry is "walked" using the `Files.walk

Re: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside [v3]

> Can I please get a review of this proposed fix for > https://bugs.openjdk.java.net/browse/JDK-8251329? > > As noted in that issue, if a zip filesystem created on top of a jar > containing a "./" entry is "walked" using the `Files.walkFileTree`, it leads > to a infinite never ending iteration

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]

On Fri, 2 Jul 2021 09:37:47 GMT, Andrew Haley wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8188044: Add @see links between multiplyHigh() and unsignedMultiplyHigh(). > > src/java.base/share/classes/java/lang

Re: RFR: 8188044: We need Math.unsignedMultiplyHigh [v2]

On Thu, 1 Jul 2021 18:08:22 GMT, Brian Burkhalter wrote: >> Please consider this proposal to add a method >> `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and >> `java.lang.StrictMath`. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit

Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]

On Fri, 2 Jul 2021 08:52:28 GMT, Peter Levart wrote: >> src/java.base/share/classes/java/lang/Runtime.java line 662: >> >>> 660: * or that any particular number of {@link java.lang.ref.Reference >>> Reference} >>> 661: * objects will be cleared and enqueued. >>> 662: * >> >> Hi

Re: RFR: 8251329: (zipfs) Files.walkFileTree walks infinitely if zip has dir named "." inside [v2]

On Thu, 1 Jul 2021 13:25:32 GMT, Jaikiran Pai wrote: >> Can I please get a review of this proposed fix for >> https://bugs.openjdk.java.net/browse/JDK-8251329? >> >> As noted in that issue, if a zip filesystem created on top of a jar >> containing a "./" entry is "walked" using the `Files.walk

Re: RFR: 8266972: Use String.concat() in j.l.Class where invokedynamic-based String concatenation is not available [v4]

> Hello, from discussion in https://github.com/openjdk/jdk/pull/3464 I've found > out, that in a few of JDK core classes, e.g. in `j.l.Class` expressions like > `baseName.replace('.', '/') + '/' + name` are not compiled into > `invokedynamic`-based code, but into one using `StringBuilder`. This

Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]

On Fri, 2 Jul 2021 08:40:42 GMT, Peter Levart wrote: >> Mandy Chung has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Kim's suggestion on the wording > > src/java.base/share/classes/java/lang/Runtime.java line 662: > >> 660: * or tha

Re: [jdk17] RFR: JDK-8225667: Clarify the behavior of System::gc w.r.t. reference processing [v2]

On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung wrote: >> This spec clarification is a follow-up to >> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320) >> w.r.t. refer