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
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
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"
>>
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
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=207=00
Issue:
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:
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:
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
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
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
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=4674=00
Issue:
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:
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
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
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
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
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)
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
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
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
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
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
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
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:
>
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
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:
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
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
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 =
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
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
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
> 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
> 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
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
> 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
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)) {
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
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
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
> 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
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! :-)
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:
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
Hi,
I think it would be interesting adding the following methods:
1) In Collection:
default boolean
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:
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
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
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 =
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
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
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
... 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
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
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);
>>
> 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
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
> 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
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().
>
>
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
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: *
>>
>>
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
> 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
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
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=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320)
>> w.r.t. reference
On Thu, 1 Jul 2021 21:59:33 GMT, Markus KARG
wrote:
>> This PR-*draft* is **work in progress** and an invitation to discuss a
>> possible solution for issue
>> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
>> yet* intended for a final review.
>>
>> As proposed
> This PR-*draft* is **work in progress** and an invitation to discuss a
> possible solution for issue
> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
> yet* intended for a final review.
>
> As proposed in JDK-8265891, this PR provides an implementation for
>
67 matches
Mail list logo
