On Fri, 16 Dec 2022 16:10:10 GMT, Magnus Ihse Bursie wrote:
>> Justin King has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Simplify logic for including __ubsan_default_options
>>
>> Signed-off-by: Justin King
>
> I much also check:
On Thu, 5 Jan 2023 01:36:51 GMT, Brian Burkhalter 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/Transfer2G
On Wed, 4 Jan 2023 16:35:57 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/io/StringWriter.java line 244:
>>
>>> 242:
>>> 243: private static int checkSize(int initialSize) {
>>> 244: if (initialSize < 0) {
>>
>> Similar checks exist e.g. in `ByteArrayOutputStream` an
On Wed, 4 Jan 2023 22:16:37 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/io/CharArrayWriter.java line 101:
>>
>>> 99: */
>>> 100: public void write(char[] c, int off, int len) {
>>> 101: Objects.checkFromToIndex(off, len, c.length);
>>
>> shouldn't that be O
On Wed, 4 Jan 2023 21:04:08 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
On Wed, 4 Jan 2023 19:39:23 GMT, Stuart Marks wrote:
> so it's difficult to write a simple functional test for this change.
It is possible to track that for some "custom" and empty collection the only
method will be called is `isEmpty` and nothing else. Not sure how it is useful
or not.
-
On Wed, 4 Jan 2023 21:04:08 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
On Wed, 4 Jan 2023 01:19:52 GMT, Jaikiran Pai wrote:
>> Michael Ernst has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains seven commits:
>>
>> - Merge ../jdk-openjdk into typos-typos
>> - Reinstate typos in Apache code that is copie
On Wed, 4 Jan 2023 19:52:07 GMT, Scott Palmer wrote:
>> Use the following methods instead of hand-written code:
>> - Objects.checkFromIndexSize()
>> - Objects.checkFromToIndex()
>
> src/java.base/share/classes/java/io/CharArrayWriter.java line 101:
>
>> 99: */
>> 100: public void write(
On Tue, 3 Jan 2023 17:40:42 GMT, Justin Lu wrote:
> Regression caused by the fix to
> [JDK-8296239](https://bugs.openjdk.org/browse/JDK-8296239). The ISO 4217
> Amendment 174 Update changes went into effect starting in 2023.
>
> _java/text/Format/NumberFormat/CurrencyFormat.java_ fails as
>
On Sat, 3 Dec 2022 08:23:34 GMT, Tagir F. Valeev wrote:
>> Tagir F. Valeev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fixes according to review
>>
>> 1. Reduce duplication in tests
>> 2. Use JumpableGenerator#copy() instead o
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
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 Wed, 12 Oct 2022 13:26:29 GMT, Tagir F. Valeev wrote:
>> Java 17 added RandomGenerator interface. However, existing method
>> Collections.shuffle accepts old java.util.Random class. While since Java 19,
>> it's possible to use Random.from(RandomGenerator) wrapper, it would be more
>> conven
> 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 revealed an issue in CLDRConverter buildtool that
> it
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 Wed, 4 Jan 2023 14:37:13 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
> subclassing `T
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 revealed an issue in CLDRConverter buildtool that it
was not ca
On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote:
> 8299563: Fix typos
This pull request has now been integrated.
Changeset: 7dcc6899
Author:Michael Ernst
Committer: Alexey Ivanov
URL:
https://git.openjdk.org/jdk/commit/7dcc689932ea276586282e0917f2efc10a598eb7
Stats: 5 lin
On Wed, 4 Jan 2023 15:50:35 GMT, Sergey Tsypanov wrote:
> Use the following methods instead of hand-written code:
> - Objects.checkFromIndexSize()
> - Objects.checkFromToIndex()
src/java.base/share/classes/java/io/CharArrayWriter.java line 101:
> 99: */
> 100: public void write(char[]
On Wed, 4 Jan 2023 16:35:41 GMT, Michael Ernst wrote:
>> 8299563: Fix typos
>
> Michael Ernst has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains ten commits:
>
> - Address review feedback
> - Merge ../jdk-openjdk into typos-typos
>
On Wed, 4 Jan 2023 14:41:20 GMT, Viktor Klang wrote:
> Currently Set.copyOf allocates both a HashSet and a new empty array when the
> input collection is empty.
>
> This patch avoids allocating anything for the case where the parameter
> collection's isEmpty returns true.
There's no regressio
On 12/12/22 7:26 AM, Alan Bateman wrote:
On 03/12/2022 18:15, Matej Turcel wrote:
:
So far, jdeps with the --api-only flag seems like the perfect tool,
except
there is a little problem -- we have packages (dozens of them) which
exist in multiple modules. For example, package `com.foo` exist
On Wed, 4 Jan 2023 16:35:41 GMT, Michael Ernst wrote:
>> 8299563: Fix typos
>
> Michael Ernst has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains ten commits:
>
> - Address review feedback
> - Merge ../jdk-openjdk into typos-typos
>
On Wed, 4 Jan 2023 15:54:29 GMT, Sergey Tsypanov wrote:
>> 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
> 8299563: Fix typos
Michael Ernst has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains ten commits:
- Address review feedback
- Merge ../jdk-openjdk into typos-typos
- Merge ../jdk-openjdk into typos-typos
- Reinstate typos in Apache
On Wed, 4 Jan 2023 14:38:34 GMT, Alan Bateman wrote:
>> …fails for hr_HR after 1.1.2023 and 8296239
>>
>> Hi,
>>
>> this fixes the issue with the currency test.
>
> Should this be closed as dup of pull/11833 ?
@AlanBateman, sorry, I missed that other PR.
-
PR: https://git.openjdk
On Wed, 4 Jan 2023 14:21:53 GMT, Goetz Lindenmaier wrote:
> …fails for hr_HR after 1.1.2023 and 8296239
>
> Hi,
>
> this fixes the issue with the currency test.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/11844
On Wed, 4 Jan 2023 14:41:20 GMT, Viktor Klang wrote:
> Currently Set.copyOf allocates both a HashSet and a new empty array when the
> input collection is empty.
>
> This patch avoids allocating anything for the case where the parameter
> collection's isEmpty returns true.
Looks okay. This rel
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
>
Use the following methods instead of hand-written code:
- Objects.checkFromIndexSize()
- Objects.checkFromToIndex()
-
Commit messages:
- 8299600: Use Objects.check*() where appropriate in java.io
- Merge branch 'master' into index-io
- Fix
- Check from-to in java.io
Changes: http
On Wed, 4 Jan 2023 15:37:23 GMT, Per Minborg wrote:
> 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
On Wed, 4 Jan 2023 15:20:10 GMT, Pavel Rappo wrote:
>> Currently Set.copyOf allocates both a HashSet and a new empty array when the
>> input collection is empty.
>>
>> This patch avoids allocating anything for the case where the parameter
>> collection's isEmpty returns true.
>
> Curious: how
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 declaration
These shou
On Wed, 4 Jan 2023 14:41:20 GMT, Viktor Klang wrote:
> Currently Set.copyOf allocates both a HashSet and a new empty array when the
> input collection is empty.
>
> This patch avoids allocating anything for the case where the parameter
> collection's isEmpty returns true.
Curious: how bad was
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:41:20 GMT, Viktor Klang wrote:
> Currently Set.copyOf allocates both a HashSet and a new empty array when the
> input collection is empty.
>
> This patch avoids allocating anything for the case where the parameter
> collection's isEmpty returns true.
LGTM
-
Currently Set.copyOf allocates both a HashSet and a new empty array when the
input collection is empty.
This patch avoids allocating anything for the case where the parameter
collection's isEmpty returns true.
-
Commit messages:
- 8299444: java.util.Set.copyOf allocates needlessly
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 instead of
On Wed, 4 Jan 2023 14:21:53 GMT, Goetz Lindenmaier wrote:
> …fails for hr_HR after 1.1.2023 and 8296239
>
> Hi,
>
> this fixes the issue with the currency test.
Should this be closed as dup of JDK-8299439 ?
-
PR: https://git.openjdk.org/jdk/pull/11844
> 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
…fails for hr_HR after 1.1.2023 and 8296239
Hi,
this fixes the issue with the currency test.
-
Commit messages:
- 8299439: [testbug] java/text/Format/NumberFormat/CurrencyFormat.java fails
for hr_HR after 1.1.2023 and 8296239
Changes: https://git.openjdk.org/jdk/pull/11844/files
On Tue, 3 Jan 2023 13:35:32 GMT, Daniel Jeliński wrote:
> This patch introduces a time limit for establishing a secure connection to a
> RMI server.
>
> The existing implementation uses the configured
> `sun.rmi.transport.tcp.handshakeTimeout` during RMI handshake only; there's
> no time limi
On Wed, 4 Jan 2023 12:40:43 GMT, Per Minborg wrote:
> > @minborg Amazing piece!
> > Will `java.lang.invoke.VarHandle` instances be shared in JDK to reuse in
> > other places?
> > The
> > [jsoniter-scala-coreJVM](https://github.com/plokhotnyuk/jsoniter-scala/tree/master/jsoniter-scala-core/jvm/s
On Wed, 4 Jan 2023 12:20:28 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:18 GMT, Per Minborg wrote:
>> Do we need this test at all, because this code is tested to extense through
>> RandomAccessFile? We had no test before, so why add a new one here?
>>
>> Otherwise: PR looks good.
>
>> Do we need this test at all, because this code is tested
On Wed, 4 Jan 2023 12:20:28 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
> 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
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 Wed, 4 Jan 2023 10:49:24 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:24 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 1/4/23 09:56, 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.
Hmh, Javadoc for MethodHandels::byteArrayViewVarHandle sa
On Wed, 4 Jan 2023 10:49:18 GMT, Per Minborg wrote:
>> Do we need this test at all, because this code is tested to extense through
>> RandomAccessFile? We had no test before, so why add a new one here?
>>
>> Otherwise: PR looks good.
>
>> Do we need this test at all, because this code is tested
Add experimental Foreign Function & Memory API support for RISC-V.
Details of FFM API RISC-V port please refer to [JBS
issue](https://bugs.openjdk.org/browse/JDK-8293841)
-
Commit messages:
- sync with JDK-8296477
- sync with JDK-8295044
- JDK-8293841: RISC-V: Implementation of F
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
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 implicit
scope instead.
This doesn't make a lot of difference, given th
> 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
On Wed, 4 Jan 2023 09:25:40 GMT, Uwe Schindler wrote:
> Do we need this test at all, because this code is tested to extense through
> RandomAccessFile? We had no test before, so why add a new one here?
>
> Otherwise: PR looks good.
There are overlaps of the RAF and Bits tests but the latter te
On Wed, 4 Jan 2023 09:01:06 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 09:01:06 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 09:10:01 GMT, Aleksey Shipilev wrote:
> > I see that in the additional testing section you note, running tests with
> > RETRY_COUNT. Is that intentional? Does retry count play a role in the
> > report generation?
>
> The logic for REPEAT/RETRY_COUNT merges the jtreg reports
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 Wed, 4 Jan 2023 01:40:36 GMT, Jaikiran Pai wrote:
> Please update the copyright years on the files before integrating.
Updated.
> I see that in the additional testing section you note, running tests with
> RETRY_COUNT. Is that intentional? Does retry count play a role in the report
> gener
> 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
> it gets expensive. If you add more tests to suite -- for exam
On Wed, 4 Jan 2023 08:57:25 GMT, Per Minborg wrote:
> Is there a better way to test packet-private methods in Bits without
> resorting to reflection?
Yes, looking for directories named java.base in the test tree and you'll see
test classes that are compiled into java.base/java.net,
java.base/
> 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
On Wed, 4 Jan 2023 08:48:56 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 for
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`
improvements will be
68 matches
Mail list logo
