On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs wrote:
> This PR adds a new lint warning category `this-escape`.
>
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
> allow the JDK to continue to compile with `-Xlint:all`.
>
> A 'this' escape warning is generated f
Can I please get a review of this change which fixes an issue in the javadoc
text of the internal class IteratorSpliterator? This addresses the issue
reported at https://bugs.openjdk.org/browse/JDK-8297306.
-
Commit messages:
- 8297306: Incorrect brackets in Javadoc for a construc
On Thu, 5 Jan 2023 13:24:08 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc only change which addresses the
>> javadoc issue noted in https://bugs.openjdk.org/browse/JDK-8258776?
>>
>> As noted in that issue, the `ThreadLocal.initialValue()` API javadoc
>> suggests subclassi
On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs wrote:
> This PR adds a new lint warning category `this-escape`.
>
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
> allow the JDK to continue to compile with `-Xlint:all`.
>
> A 'this' escape warning is generated f
This PR adds a new lint warning category `this-escape`.
It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
allow the JDK to continue to compile with `-Xlint:all`.
A 'this' escape warning is generated for a constructor `A()` in a class `A`
when the compiler detects that
On Thu, 5 Jan 2023 20:45:20 GMT, Mandy Chung wrote:
> Trivial fix. Fix `Invokers.checkExactType` to call
> `newWrongMethodTypeException(actual, expected)` with parameters in right
> order.
Hello Mandy, this looks good to me. The copyright year on the file will need an
update.
There's anothe
On Wed, 4 Jan 2023 21:48:26 GMT, Justin Lu wrote:
> Added the missing copyright header
Marked as reviewed by jpai (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/11854
On Wed, 4 Jan 2023 21:48:26 GMT, Justin Lu wrote:
> Added the missing copyright header
Marked as reviewed by naoto (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/11854
On Fri, 23 Dec 2022 22:28:34 GMT, Markus KARG wrote:
> I/O had always been much slower than CPU and memory access, and thanks to
> physical constraints, always will be.
> While CPUs can get shrinked more and more, and can hold more and more memory
> cache on or nearby a CPU core, the distance b
On Thu, 5 Jan 2023 20:45:20 GMT, Mandy Chung wrote:
> Trivial fix. Fix `Invokers.checkExactType` to call
> `newWrongMethodTypeException(actual, expected)` with parameters in right
> order.
Parameter order for method invocation now matches method declaration on line
521.
-
Marke
On Wed, 4 Jan 2023 21:48:26 GMT, Justin Lu wrote:
> Added the missing copyright header
Provided GPL license appear to match the standard template available here:
https://github.com/openjdk/jdk/blob/master/make/data/license-templates/gpl-header
-
Marked as reviewed by iris (Reviewe
On Wed, 4 Jan 2023 23:02:40 GMT, Naoto Sato wrote:
>> Added the missing copyright header
>
> test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 9:
>
>> 7: # published by the Free Software Foundation. Oracle designates this
>> 8: # particular file as subject to the "Classpath
On Wed, 4 Jan 2023 21:48:26 GMT, Justin Lu wrote:
> Added the missing copyright header
Changes requested by naoto (Reviewer).
test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 2:
> 1: #
> 2: # Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
This fil
Added the missing copyright header
-
Commit messages:
- Fix date, remove classpath
- Add copyright header
Changes: https://git.openjdk.org/jdk/pull/11854/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11854&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8299617
St
Trivial fix. Fix `Invokers.checkExactType` to call
`newWrongMethodTypeException(actual, expected)` with parameters in right order.
-
Commit messages:
- 8299183: Invokers.checkExactType passes parameters to create WMTE in
opposite order
Changes: https://git.openjdk.org/jdk/pull/11
8299278: tools/jpackage/share/AddLauncherTest.java#id1 failed
AddLauncherTest.bug8230933
-
Commit messages:
- Comment fixed
- 8299278: tools/jpackage/share/AddLauncherTest.java#id1 failed
AddLauncherTest.bug8230933
Changes: https://git.openjdk.org/jdk/pull/11868/files
Webrev: ht
On Thu, 5 Jan 2023 12:14:05 GMT, Sergey Tsypanov wrote:
>> Use the following methods instead of hand-written code:
>> - Objects.checkFromIndexSize()
>> - Objects.checkFromToIndex()
>
> Sergey Tsypanov has updated the pull request incrementally with two
> additional commits since the last revisio
On Thu, 5 Jan 2023 12:14:05 GMT, Sergey Tsypanov wrote:
>> Use the following methods instead of hand-written code:
>> - Objects.checkFromIndexSize()
>> - Objects.checkFromToIndex()
>
> Sergey Tsypanov has updated the pull request incrementally with two
> additional commits since the last revisio
On Thu, 5 Jan 2023 12:09:46 GMT, Sergey Tsypanov wrote:
>>> Indeed there are at least four regression test failures with this as-is:
>>>
>>> * java/io/InputStream/ReadParams.java
>>> * java/io/OutputStream/WriteParams.java
>>> * java/io/Writer/WriteParams.java
>>> * java/nio/channels/FileChannel
On Wed, 4 Jan 2023 19:57:56 GMT, Naoto Sato wrote:
> This is a pre-requisite fix for upgrading CLDR to v43. The upcoming CLDR
> changed the inheritance mechanism a bit with this change:
> https://unicode-org.atlassian.net/browse/CLDR-15054 where they removed the
> duplication of data. This rev
On Thu, 5 Jan 2023 12:29:20 GMT, Per Minborg wrote:
>> I think the casts are worth it to set `lock` only once during construction,
>> but would be inclined to leave out the addition of `checkSize`.
>
> I have added a new proposal in the hope that the `requireNonNegative` method
> name and param
On Sat, 17 Dec 2022 06:39:48 GMT, Justin King wrote:
>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing
>> the image due to lots of undefined behavior (it invokes the built JVM).
>> Follow up PRs will either replace the undefined behavior with well defined
>> behav
On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Wed, 4 Jan 2023 20:14:14 GMT, Alan Bateman wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review suggestion
>
> src/java.base/share/classes/java/lang/ThreadLocal.java line 128:
>
>> 126: * value other tha
> Can I please get a review of this doc only change which addresses the javadoc
> issue noted in https://bugs.openjdk.org/browse/JDK-8258776?
>
> As noted in that issue, the `ThreadLocal.initialValue()` API javadoc suggests
> subclassing `ThreadLocal` and overriding the `initialValue()` method
On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
Hi Uwe,
you are right! It's confusing because for cases 2-4, *atomic* access is
explicitly mentioned but not for case 1. I overlooked the *atomic
access* in the sentence before and got confused.
Thanks for the clarification!
On 1/5/23 13:37, Uwe Schindler wrote:
Hi,
I answered on the PR on
On Thu, 5 Jan 2023 12:50:25 GMT, Raffaello Giulietti
wrote:
> One reason is that if the `byte[]` contains a non-canonical NaN then `get()`
> would return it. The original code first reads an integer value and then
> converts it to a floating-point value, so for backward compatibility the same
On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Thu, 5 Jan 2023 01:42:15 GMT, Brian Burkhalter wrote:
>> I assume this is done so that "lock" is only set once during construction
>> (StringWriter is a bit unusual in that it uses the SB as the lock object). A
>> downside of the change is that it introduces casts. Another is that the
>> ex
Hi,
I answered on the PR on github. The documentation is misleading:
The copypasted snippet above is misleading, you need to read the
whole statement, so an IllegalStateException can only happen for
unaligned access on access modes other than get/set (so volatile or
opaque reads): "I
On Thu, 5 Jan 2023 12:18:58 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
> Code in java.io contains many legacy constructs and semantics not recommended
> including:
>
> * C-style array declaration
> * Unnecessary visibility
> * Redundant keywords in interfaces (e.g. public, static)
> * Non-standard naming for constants
> * Javadoc typos
> * Missing final declar
The more I think about it, the clearer is that the first line of the
Javadoc is contrary to the other lines:
On 1/5/23 12:59, Michael Kuhlmann wrote:
* read write access modes for all T, with the exception of access modes
get and set for long and double on 32-bit platforms.
So all read write
> Currently, `java.io.Bits` is using explicit logic to read/write various
> primitive types to/from byte arrays. Switching to the use of `VarHandle`
> access would provide better performance and less code.
>
> Also, using a standard API for these conversions means future `VarHandle`
> improvem
> Use the following methods instead of hand-written code:
> - Objects.checkFromIndexSize()
> - Objects.checkFromToIndex()
Sergey Tsypanov has updated the pull request incrementally with two additional
commits since the last revision:
- 8299600: Use checkFromIndexSize in PipedWriter.java
- 8299
On Thu, 5 Jan 2023 07:11:57 GMT, Alan Bateman wrote:
>> Indeed there are at least four regression test failures with this as-is:
>>
>> - java/io/InputStream/ReadParams.java
>> - java/io/OutputStream/WriteParams.java
>> - java/io/Writer/WriteParams.java
>> - java/nio/channels/FileChannel/Transfer
On Wed, 4 Jan 2023 09:15:18 GMT, Aleksey Shipilev wrote:
>> This should help to speed up tests significantly. Currently, if we run "make
>> test" with a subset of tests, JTReg would still read the entirety of test
>> root to report on tests that were not run. Even with current suite of tests
>
On 1/5/23 12:40, Uwe Schindler wrote:
The copypasted snippet above is misleading, you need to read the whole statement, so an
IllegalStateException can only happen for unaligned access on access modes other than
get/set (so volatile or opaque reads): "If access is misaligned then access for
On Thu, 5 Jan 2023 01:02:11 GMT, Sergey Bylokhov wrote:
>> There's no regression test. However, with the current code (prior to this
>> change) a call to `Set.of(zeroLengthArray)` returns the same instance as
>> `Set.of()`, so it's difficult to write a simple functional test for this
>> change
On Wed, 4 Jan 2023 14:37:34 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Wed, 4 Jan 2023 14:37:34 GMT, Per Minborg wrote:
>> Currently, `java.io.Bits` is using explicit logic to read/write various
>> primitive types to/from byte arrays. Switching to the use of `VarHandle`
>> access would provide better performance and less code.
>>
>> Also, using a standard API
On Wed, 4 Jan 2023 10:49:09 GMT, Maurizio Cimadamore
wrote:
> This patch fixes a long-standing conformance issue: `VaList.empty` is
> specified to return a `VaList` associated with the global scope, but in some
> platforms (Aarch64/Linux and x64/Linux) the empty list is associated with an
> i
Some exception/error message changed with 8299470 so we have to adjust the test.
Current error is
Unexpected error 'Successor argument without leading - is expected for 'd' but
we got '-c''
java.lang.RuntimeException: Bad option test 4 failed
at SAGetoptTest.badOptionsTest(SAGetoptTest.java:124)
45 matches
Mail list logo
