> Forwardport JDK 17 -> JDK 18
Jesper Wilhelmsson has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 125 commits:
- Merge
- 8268637: Update --release 17 symbol information for JDK 17 build 28
Reviewed-by: iris
- 8269678:
On Thu, 1 Jul 2021 00:08:51 GMT, Jesper Wilhelmsson
wrote:
> Forwardport JDK 17 -> JDK 18
This pull request has now been integrated.
Changeset: 9def3b06
Author:Jesper Wilhelmsson
URL:
https://git.openjdk.java.net/jdk/commit/9def3b068e9ee065e2e545bb35f8dc56ccfe5955
Stats: 394
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
Forwardport JDK 17 -> JDK 18
-
Commit messages:
- Merge
- 8262841: Clarify the behavior of PhantomReference::refersTo
- 8269703: ProblemList
vmTestbase/nsk/jvmti/scenarios/sampling/SP07/sp07t002/TestDescription.java on
Windows-X64 with -Xcomp
- 8269513: Clarify the spec wrt
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 PR does not address intrinsics for the proposed method; that aspect can be
handled
Please consider this proposal to add a method `unsignedMultiplyHigh(long,long)`
to each of `java.lang.Math` and `java.lang.StrictMath`.
-
Commit messages:
- 8188044: We need Math.unsignedMultiplyHigh
Changes: https://git.openjdk.java.net/jdk/pull/4644/files
Webrev:
On Fri, 25 Jun 2021 00:04:48 GMT, Brian Burkhalter wrote:
> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and
> `read(byte[],int,int)` to return zero per the `InputStream` specification
> when the byte array actual or specified length is zero.
This pull request has been closed
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.
-
Commit messages:
- 6766844: ByteArrayInputStream#read with a byte array of
On Wed, 30 Jun 2021 23:00:24 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.
This PR supersedes PR
On Mon, 28 Jun 2021 17:48:37 GMT, Brian Burkhalter wrote:
>> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and
>> `read(byte[],int,int)` to return zero per the `InputStream` specification
>> when the byte array actual or specified length is zero.
>
> Brian Burkhalter has updated
On Wed, 30 Jun 2021 21:38:43 GMT, Naoto Sato wrote:
> A trivial typo fix.
Marked as reviewed by iris (Reviewer).
-
PR: https://git.openjdk.java.net/jdk17/pull/187
> 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 processing. Since there is no guarantee for any memory
On Wed, 30 Jun 2021 21:29:17 GMT, Kim Barrett 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 661:
>
>> 659: * the
On Wed, 30 Jun 2021 16:49:44 GMT, Mandy Chung wrote:
> `Reference::refersTo` behaves the same for soft, weak, and phantom references
> whereas `PhantomReference::get` always returns `null` which is different than
> soft and weak references.
>
> This patch clarifies the specification of
On Wed, 30 Jun 2021 21:38:43 GMT, Naoto Sato wrote:
> A trivial typo fix.
Marked as reviewed by prappo (Reviewer).
-
PR: https://git.openjdk.java.net/jdk17/pull/187
On Wed, 30 Jun 2021 21:38:43 GMT, Naoto Sato wrote:
> A trivial typo fix.
Marked as reviewed by joehw (Reviewer).
-
PR: https://git.openjdk.java.net/jdk17/pull/187
On Mon, 28 Jun 2021 16:57:15 GMT, Naoto Sato wrote:
> Please review this small doc change to the system property. Accompanying CSR
> has also been created.
This pull request has now been integrated.
Changeset: 3e022247
Author:Naoto Sato
URL:
A trivial typo fix.
-
Commit messages:
- 8269704: Typo in j.t.Normalizer.normalize()
Changes: https://git.openjdk.java.net/jdk17/pull/187/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=187=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8269704
Stats: 1 line in
On Wed, 30 Jun 2021 18:24:24 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
Hi Jaikiran
On Jun 30, 2021, at 12:15 PM, Jaikiran Pai
mailto:jai.forums2...@gmail.com>> wrote:
Hello Lance,
On 29/06/21 11:31 pm, Lance Andersen wrote:
I ran your current test 150 times and the max runtime was 25 seconds, most
cases were in the 18-20 second range on our slower test boxes.
Change #3294 helps to avoid `AnnotaionFormatException` in
`sun.reflect.annotation.AnnotationInvocationHandler.validateAnnotationMethods`.
While it fixes the case with e.g. `Runnable` that generates the synthetic
method without parameters, validation still fails on synthetic methods that
have
On Wed, 30 Jun 2021 16:49:44 GMT, Mandy Chung wrote:
> `Reference::refersTo` behaves the same for soft, weak, and phantom references
> whereas `PhantomReference::get` always returns `null` which is different than
> soft and weak references.
>
> This patch clarifies the specification of
On Wed, 30 Jun 2021 18:24:24 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
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 processing. Since there is no guarantee for any memory
On Mon, 28 Jun 2021 13:14:51 GMT, Christoph Göttschkes wrote:
> Hi,
>
> please review this small fix. The test case uses a custom launcher and before
> launching the JVM, it adds the "lib" and "lib/server" directories to the
> environment variable which controls the native library search
On Wed, 30 Jun 2021 16:49:44 GMT, Mandy Chung wrote:
> `Reference::refersTo` behaves the same for soft, weak, and phantom references
> whereas `PhantomReference::get` always returns `null` which is different than
> soft and weak references.
>
> This patch clarifies the specification of
`Reference::refersTo` behaves the same for soft, weak, and phantom references
whereas `PhantomReference::get` always returns `null` which is different than
soft and weak references.
This patch clarifies the specification of `PhantomReference` to make it clear
that `refersTo` can be used for
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
On Fri, 11 Jun 2021 12:42:35 GMT, Masanori Yano wrote:
> Hi all,
>
> Could you please review the 8268457 bug fixes?
>
> The problem is that ToHTMLStream applies processing for non-surrogate pairs
> to the surrogate pair.
> This fix changes the processing for non-surrogate pairs to the else
On Wed, 30 Jun 2021 10:23:32 GMT, Jan Lahoda wrote:
>> Currently, an enum switch with patterns is desugared in a very non-standard,
>> and potentially slow, way. It would be better to use the standard
>> `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs
>> to accept
Hello Lance,
On 29/06/21 11:31 pm, Lance Andersen wrote:
I ran your current test 150 times and the max runtime was 25 seconds, most
cases were in the 18-20 second range on our slower test boxes.
Thank you for running those tests. Do you think those timings are good
enough to let that test
> Can I please get a review for this proposed fix for the issue reported in
> https://bugs.openjdk.java.net/browse/JDK-8190753?
>
> The commit here checks for the size of the zip entry before trying to create
> a `ByteArrayOutputStream` for that entry's content. A new jtreg test has been
>
On Wed, 30 Jun 2021 06:32:04 GMT, Alan Bateman wrote:
>> I hope this is uncommon but if that class is loaded by a `ClassLoader` again
>> and again then it will be different each time. I'll investigate more.
>
> WeakHashMap, Boolean>, where the key is the caller, should be okay
> (assume
> 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:
update cache key from String to Class
-
On Wed, 30 Jun 2021 11:49:51 GMT, Сергей Цыпанов
wrote:
>> In some JDK classes there's still the following hashCode() implementation:
>>
>> long objNum;
>>
>> public int hashCode() {
>> return (int) objNum;
>> }
>>
>> This outdated expression should be replaced with Long.hashCode(long)
> 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
> After I've renamed remove branch GitHub for some reason has closed original
> https://github.com/openjdk/jdk/pull/2744, so I've decided to recreate it.
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains eight commits:
> There is a few JDK classes duplicating the contents of Long.hashCode() for
> hash code calculation. They should explicitly delegate to Long.hashCode().
Сергей Цыпанов has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated
> In some JDK classes there's still the following hashCode() implementation:
>
> long objNum;
>
> public int hashCode() {
> return (int) objNum;
> }
>
> This outdated expression should be replaced with Long.hashCode(long) as it
>
> - uses all bits of the original value, does not discard
> Current VectorAPI Java side implementation expresses rotateLeft and
> rotateRight operation using following operations:-
>
> vec1 = lanewise(VectorOperators.LSHL, n)
> vec2 = lanewise(VectorOperators.LSHR, n)
> res = lanewise(VectorOperations.OR, vec1 , vec2)
>
> This patch moves
> Currently, an enum switch with patterns is desugared in a very non-standard,
> and potentially slow, way. It would be better to use the standard
> `typeSwitch` bootstrap to classify the enum constants. The bootstrap needs to
> accept enum constants as labels in order to allow this. A
As of JDK 17 some of primitive wrappers, e.g. `Long`, `Integer`, `Double` and
`Float` in their implementations of `Object.toString()` delegate to own utility
`toString(primitive)` methods.
Unlike those, `Boolean`, `Byte`, `Character` and `Short` just duplicate the
contents of utility methods
On Mon, 28 Jun 2021 14:52:41 GMT, Christoph Göttschkes wrote:
>> Hi,
>>
>> please review this small fix. The test case uses a custom launcher and
>> before launching the JVM, it adds the "lib" and "lib/server" directories to
>> the environment variable which controls the native library search
On 30/06/2021 08:19, Bernd Eckenfels wrote:
Hello, sorry for being unpopular, but I just hate it to waste
developer resources,
I realy think this deprecation message should be re-considered, it
broke a lot of things, the amount of work to implement a caching
solution feels like a waste of
Hello, sorry for being unpopular, but I just hate it to waste developer
resources,
I realy think this deprecation message should be re-considered, it broke a lot
of things, the amount of work to implement a caching solution feels like a
waste of time and on top of it, there is no clear
On Tue, 29 Jun 2021 21:18:35 GMT, Weijun Wang wrote:
>> Using a synchronized WeakHashMap with the class as the key would not prevent
>> class unloading.
>> Using a non-weak set or map to strings would keep the strings around for the
>> life of the runtime.
>
> I hope this is uncommon but if
46 matches
Mail list logo
