> The commit in this PR implements the proposal for enhancement that was
> discussed in the core-libs-dev mailing list recently[1], for
> https://bugs.openjdk.java.net/browse/JDK-8231640
>
> At a high level - the `store()` APIs in `Properties` have been modified to
> now look for the
I am trying to give an example of the utility of the @Serial annotation.
But the JDK 17 javac doesn't seem to do anything with it. I tried:
@Serial private void readObject(java.io.ObjectInputStream stream, int
shouldNotHaveThisParam) throws IOException, ClassNotFoundException
@Serial private
> The commit in this PR implements the proposal for enhancement that was
> discussed in the core-libs-dev mailing list recently[1], for
> https://bugs.openjdk.java.net/browse/JDK-8231640
>
> At a high level - the `store()` APIs in `Properties` have been modified to
> now look for the
Relaxing some assertion bounds to allow for small error values that still show
improvement over previous summation method.
-
Commit messages:
- Dropping unnecessary equals case
- Dropping equals zero assert
Changes: https://git.openjdk.java.net/jdk/pull/5430/files
Webrev:
On Mon, 30 Aug 2021 06:26:01 GMT, Wang Huang wrote:
>> Dear all,
>> Can you do me a favor to review this patch. This patch use `ldp` to
>> implement String.compareTo.
>>
>> * We add a JMH test case
>> * Here is the result of this test case
>>
>> Benchmark
On Tue, 7 Sep 2021 01:38:02 GMT, Nick Gasson wrote:
> Please check the Windows tier1 failure:
> https://github.com/Wanghuang-Huawei/jdk/runs/3459332995
>
> Seems unlikely that it's anything to do with this patch so you may just want
> to re-run it or merge from master.
OK, The rerun of
On Wed, 8 Sep 2021 22:00:53 GMT, Brian Burkhalter wrote:
> Modify the class level specification of `java.io.FilterInputStream` to be
> more exact about `java.io.InputStream` methods that it overrides.
CSR filed: [JDK-8273517](https://bugs.openjdk.java.net/browse/JDK-8273517).
-
On Wed, 8 Sep 2021 23:38:38 GMT, David Holmes wrote:
> Pre-existing: The initialization logic in this code is quite odd for the case
> when no conversion is necessary (we call `utfInitialize` on every call to
> `convertUtf8ToPlatformString`!), but I assume we do not call
>
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote:
> The gist of the issue is that the test case now always creates the boot
> classpath with non-ASCII chars appended, because the default encoding is
> fixed to UTF-8 with the fix to JDK-8260265.
>
> On macOS, javaagent tries to load the class
On Wed, 8 Sep 2021 13:25:27 GMT, Aleksey Shipilev wrote:
>> JDK-8179317 rewritten runtime shell tests to Java. There is a little
>> omission in VM variant selection, which makes Zero fail some of the tier1
>> tests, like:
>>
>>
>> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
>>
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote:
> The gist of the issue is that the test case now always creates the boot
> classpath with non-ASCII chars appended, because the default encoding is
> fixed to UTF-8 with the fix to JDK-8260265.
>
> On macOS, javaagent tries to load the class
On Wed, 8 Sep 2021 22:15:12 GMT, Naoto Sato wrote:
> The gist of the issue is that the test case now always creates the boot
> classpath with non-ASCII chars appended, because the default encoding is
> fixed to UTF-8 with the fix to JDK-8260265.
>
> On macOS, javaagent tries to load the class
The gist of the issue is that the test case now always creates the boot
classpath with non-ASCII chars appended, because the default encoding is fixed
to UTF-8 with the fix to JDK-8260265.
On macOS, javaagent tries to load the class with US-ASCII determined by
nl_langinfo() (in
On Wed, 8 Sep 2021 22:00:53 GMT, Brian Burkhalter wrote:
> Modify the class level specification of `java.io.FilterInputStream` to be
> more exact about `java.io.InputStream` methods that it overrides.
Some other incidental modifications are made in passing, principally adding
`@Override`
Modify the class level specification of `java.io.FilterInputStream` to be more
exact about `java.io.InputStream` methods that it overrides.
-
Commit messages:
- 8273513: Make java.io.FilterInputStream specification more precise about
overrides
Changes:
On Fri, 27 Aug 2021 15:23:35 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to
>> replace and mitigate Object.finalize() uses in the JDK libraries; please see
>> https://bugs.openjdk.java.net/browse/JDK-8253568 for more
On Wed, 1 Sep 2021 16:37:24 GMT, Roger Riggs wrote:
> The ExecCommand test of Runtime.exec is difficult to maintain; the parallel
> arrays are hard to keep in sync.
> This cleanup converts to use TestNG DataProviders and other improvements.
This pull request has now been integrated.
On Fri, 3 Sep 2021 22:29:19 GMT, Brian Burkhalter wrote:
> This request proposes to modify `java.io.FilterInputStream` to override
> `readAllBytes()`, `readNBytes(int)`, `skipNBytes(long)`, and
> `transferTo(OutputStream)` in order to leverage any performance advantage
> that the wrapped
On Fri, 3 Sep 2021 23:19:22 GMT, Brian Burkhalter wrote:
>> This request proposes to modify `java.io.FilterInputStream` to override
>> `readAllBytes()`, `readNBytes(int)`, `skipNBytes(long)`, and
>> `transferTo(OutputStream)` in order to leverage any performance advantage
>> that the wrapped
On Wed, 8 Sep 2021 20:24:31 GMT, Ian Graves wrote:
> The duplicate condition in this chain of expressions needs to be shrunk to
> drop a couple of character that are not excluded spacing marks.
The copyright year in Grapheme.java should be 2021, otherwise looks good.
-
Marked as
The duplicate condition in this chain of expressions needs to be shrunk to drop
a couple of character that are not excluded spacing marks.
-
Commit messages:
- 8273430: Suspicious duplicate condition in
java.util.regex.Grapheme#isExcludedSpacingMark
Changes:
Hello.
I found a confusing javadoc of the method java.lang.StringBuilder#readObject:
"readObject is called to restore the state of the StringBuffer from a stream."
I believe there should be "StringBuilder" instead of "StringBuffer".
Andrey Turbanov
On Wed, 8 Sep 2021 19:31:46 GMT, Roger Riggs wrote:
>> The ExecCommand test of Runtime.exec is difficult to maintain; the parallel
>> arrays are hard to keep in sync.
>> This cleanup converts to use TestNG DataProviders and other improvements.
>
> Roger Riggs has updated the pull request with a
On Wed, 8 Sep 2021 19:31:46 GMT, Roger Riggs wrote:
>> The ExecCommand test of Runtime.exec is difficult to maintain; the parallel
>> arrays are hard to keep in sync.
>> This cleanup converts to use TestNG DataProviders and other improvements.
>
> Roger Riggs has updated the pull request with a
On Tue, 7 Sep 2021 22:01:54 GMT, Lance Andersen wrote:
>> Roger Riggs has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains three additional
>>
> The ExecCommand test of Runtime.exec is difficult to maintain; the parallel
> arrays are hard to keep in sync.
> This cleanup converts to use TestNG DataProviders and other improvements.
Roger Riggs has updated the pull request with a new target base due to a merge
or a rebase. The
On Wed, 8 Sep 2021 09:32:55 GMT, Jaikiran Pai wrote:
>> Jaikiran Pai has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - adjust testcases to verify the new semantics
>> - implement review suggestions:
>> - Use doPriveleged instead of
Unless there's an overriding reason, it might be nice to have the output format
match the format used in the Debian patch that adds SOURCE_DATE_EPOCH:
https://salsa.debian.org/openjdk-team/openjdk/-/blob/master/debian/patches/reproducible-properties-timestamp.diff
So the current patch
On Wed, 1 Sep 2021 13:28:34 GMT, Jovan Stevanovic
wrote:
> GraalVM Native Image supports loading classes at runtime if they are known
> during image build (class predefinition). This is achieved by the JVMTI agent
> that registers dynamically generated classes in a regular HotSpot run. The
>
On Wed, 8 Sep 2021 17:40:29 GMT, Naoto Sato wrote:
>> Please review the fix to the issue. Avoiding overflow by not calling
>> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
>> in nano unit.
>
> Naoto Sato has updated the pull request incrementally with one
On Wed, 8 Sep 2021 17:40:29 GMT, Naoto Sato wrote:
>> Please review the fix to the issue. Avoiding overflow by not calling
>> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
>> in nano unit.
>
> Naoto Sato has updated the pull request incrementally with one
On Wed, 8 Sep 2021 15:35:27 GMT, Stephen Colebourne
wrote:
> `toEpochMilli()` overflows at large/small values. Thus any attempt to
> calculate the difference between two very large instants would fail.
Thanks. Fixed.
-
PR: https://git.openjdk.java.net/jdk/pull/5396
> Please review the fix to the issue. Avoiding overflow by not calling
> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
> in nano unit.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last revision:
Corrected the
On Tue, 7 Sep 2021 20:25:25 GMT, Sandhya Viswanathan
wrote:
> Fix the copyright header of SVML files to match others.
>
> This was brought up on jdk-dev mailing list:
> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html
This pull request has now been integrated.
On Wed, 8 Sep 2021 02:03:12 GMT, Paul Sandoz wrote:
>> Fix the copyright header of SVML files to match others.
>>
>> This was brought up on jdk-dev mailing list:
>> https://mail.openjdk.java.net/pipermail/jdk-dev/2021-September/005992.html
>
> Marked as reviewed by psandoz (Reviewer).
Thanks a
On Fri, 3 Sep 2021 13:22:54 GMT, Сергей Цыпанов
wrote:
> Current implementation looks like this:
>
> public byte[] getBytes(String charsetName)
> throws UnsupportedEncodingException {
> if (charsetName == null) throw new NullPointerException();
> return
On Fri, 25 Jun 2021 12:10:18 GMT, Masanori Yano wrote:
> Hi all,
>
> Could you please review the 8269373 bug fixes?
>
> These tests call java.lang.ProcessBuilder in direct, so not used jtreg
> command option. To run non-localized tests, -Duser.language=en and
> -Duser.country=US options
On Wed, 8 Sep 2021 00:36:29 GMT, Naoto Sato wrote:
>> Please review the fix to the issue. Avoiding overflow by not calling
>> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
>> in nano unit.
>
> Naoto Sato has updated the pull request incrementally with one
On Wed, 8 Sep 2021 13:58:59 GMT, Stephen Colebourne
wrote:
> This change looks fine, but I think you also need a `millisUntil` private
> method to fix the identical overflow problem with millis (which might as well
> be fixed now).
`until()` for millis simply subtracts its `toEpochMilli()`
On Wed, 8 Sep 2021 09:17:31 GMT, Aleksey Shipilev wrote:
>> This test runs a lot of configurations, and spends a lot of time serially.
>> This is especially pronounced when run in prospective tier4 runs
>> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We
>> can
On Wed, 8 Sep 2021 11:06:50 GMT, Arno Zeller wrote:
> Probably it could be a better solution to add the stress keyword for slow
> running or high load tests - like it is done in the hotspot part of the
> tests. Then automated test run can exclude or select these test by keyword.
Thought so
On Wed, 8 Sep 2021 00:36:29 GMT, Naoto Sato wrote:
>> Please review the fix to the issue. Avoiding overflow by not calling
>> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
>> in nano unit.
>
> Naoto Sato has updated the pull request incrementally with one
On Wed, 8 Sep 2021 00:36:29 GMT, Naoto Sato wrote:
>> Please review the fix to the issue. Avoiding overflow by not calling
>> nanosUntil() directly, which will overflow beyond Long.MAX_VALUE difference
>> in nano unit.
>
> Naoto Sato has updated the pull request incrementally with one
On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev wrote:
> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission
> in VM variant selection, which makes Zero fail some of the tier1 tests, like:
>
>
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
>
> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission
> in VM variant selection, which makes Zero fail some of the tier1 tests, like:
>
>
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
> TEST=runtime/StackGap/TestStackGap.java
>
> STDERR:
> java.lang.Error:
On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev wrote:
> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission
> in VM variant selection, which makes Zero fail some of the tier1 tests, like:
>
>
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
>
On Wed, 8 Sep 2021 09:54:33 GMT, Jaikiran Pai wrote:
>> The commit in this PR implements the proposal for enhancement that was
>> discussed in the core-libs-dev mailing list recently[1], for
>> https://bugs.openjdk.java.net/browse/JDK-8231640
>>
>> At a high level - the `store()` APIs in
On Tue, 7 Sep 2021 23:48:08 GMT, Joe Wang wrote:
>> GraalVM Native Image supports loading classes at runtime if they are known
>> during image build (class predefinition). This is achieved by the JVMTI
>> agent that registers dynamically generated classes in a regular HotSpot run.
>> The
On Wed, 8 Sep 2021 09:17:31 GMT, Aleksey Shipilev wrote:
>> This test runs a lot of configurations, and spends a lot of time serially.
>> This is especially pronounced when run in prospective tier4 runs
>> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We
>> can
On Wed, 8 Sep 2021 11:34:10 GMT, Maurizio Cimadamore
wrote:
> Changes looks good. Whether we want to use `manual` or `@stress` I'm not
> sure. I guess it depends a lot on which parameters are typically used by CI
> to run those tests.
I note that, for instance, the makefile
On Wed, 8 Sep 2021 09:17:31 GMT, Aleksey Shipilev wrote:
>> This test runs a lot of configurations, and spends a lot of time serially.
>> This is especially pronounced when run in prospective tier4 runs
>> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We
>> can
On Wed, 25 Aug 2021 22:05:24 GMT, Vladimir Ivanov wrote:
> Get rid of WeakReference-based logic in
> DirectMethodHandle::checkInitialized() and reimplement it with
> `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`.
>
> The key observation is that `Unsafe::ensureClassInitialized()`
On Thu, 2 Sep 2021 11:45:01 GMT, Vladimir Ivanov wrote:
>> Get rid of WeakReference-based logic in
>> DirectMethodHandle::checkInitialized() and reimplement it with
>> `Unsafe::ensureClassInitialized()`/`shouldBeInitialized()`.
>>
>> The key observation is that
On Fri, 3 Sep 2021 14:41:45 GMT, Vladimir Ivanov wrote:
>> `MethodHandle.asTypeCache` keeps a strong reference to adapted
>> `MethodHandle` and it can introduce a class loader leak through its
>> `MethodType`.
>>
>> Proposed fix introduces a 2-level cache (1 element each) where 1st level can
On Wed, 25 Aug 2021 09:31:51 GMT, Vladimir Ivanov wrote:
> `MethodHandle.asTypeCache` keeps a strong reference to adapted `MethodHandle`
> and it can introduce a class loader leak through its `MethodType`.
>
> Proposed fix introduces a 2-level cache (1 element each) where 1st level can
> only
On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev wrote:
> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission
> in VM variant selection, which makes Zero fail some of the tier1 tests, like:
>
>
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test
>
On Wed, 8 Sep 2021 09:13:20 GMT, Aleksey Shipilev wrote:
> New commit: marked tests as `manual`, as per Maurizio's request. This forced
> me to drop the `timeout=` clauses, as those are incompatible with `manual`
> (jtreg plainly refuses to run these).
Ok, I am too late, but just for the
JDK-8179317 rewritten runtime shell tests to Java. There is a little omission
in VM variant selection, which makes Zero fail some of the tier1 tests, like:
$ CONF=linux-x86_64-zero-fastdebug make exploded-test
TEST=runtime/StackGap/TestStackGap.java
STDERR:
java.lang.Error: TESTBUG:
Update code checks both non-null and instance of a class in java.naming module
classes.
The checks and explicit casts could also be replaced with pattern matching for
the instanceof operator.
For example:
The following code:
return (obj != null &&
obj instanceof
> The commit in this PR implements the proposal for enhancement that was
> discussed in the core-libs-dev mailing list recently[1], for
> https://bugs.openjdk.java.net/browse/JDK-8231640
>
> At a high level - the `store()` APIs in `Properties` have been modified to
> now look for the
Hello Andrey,
On 07/09/21 7:50 pm, Andrey Turbanov wrote:
On Sun, 5 Sep 2021 12:38:20 GMT, Jaikiran Pai wrote:
Do you mean that converting the keySet() of an
existing Map into an array and then sorting that array and then using
that sorted array to iterate and using these keys to do an
On Wed, 8 Sep 2021 09:26:33 GMT, Jaikiran Pai wrote:
>> The commit in this PR implements the proposal for enhancement that was
>> discussed in the core-libs-dev mailing list recently[1], for
>> https://bugs.openjdk.java.net/browse/JDK-8231640
>>
>> At a high level - the `store()` APIs in
On 07/09/21 9:02 pm, Alan Bateman wrote:
On 07/09/2021 16:05, Roger Riggs wrote:
Hi,
The value of SOURCE_DATE_EPOCH is not so sensitive that it needs the
protections you are applying.
The doPriv only exposes the value of that specific environment
variable and in the usual case, it is
> The commit in this PR implements the proposal for enhancement that was
> discussed in the core-libs-dev mailing list recently[1], for
> https://bugs.openjdk.java.net/browse/JDK-8231640
>
> At a high level - the `store()` APIs in `Properties` have been modified to
> now look for the
On Tue, 7 Sep 2021 16:54:11 GMT, Alan Bateman wrote:
>> you are right about /manual being for GUI - but @AlanBateman pointed me at
>> few tests with libzip using it for similar reasons (e.g. long running tests).
>
> I don't think /manual is strictly UI but its usage is discouraged as manual
>
> This test runs a lot of configurations, and spends a lot of time serially.
> This is especially pronounced when run in prospective tier4 runs
> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can
> parallelize the test configurations for this test to make it hurt
On Fri, 3 Sep 2021 09:53:53 GMT, Aleksey Shipilev wrote:
> This test runs a lot of configurations, and spends a lot of time serially.
> This is especially pronounced when run in prospective tier4 runs
> (JDK-8273314). There are reports of multi-hour runs (see JDK-8271613). We can
>
On Wed, 8 Sep 2021 06:30:34 GMT, wxiang
wrote:
> Create CSR: https://bugs.openjdk.java.net/browse/JDK-8273473
Thanks. I've updated the CSR to make it clearer what this change is about.
There is still some TDB for the JAR file spec.
-
PR:
On Wed, 8 Sep 2021 06:22:38 GMT, wxiang
wrote:
>> There is a bug for URLClassPath.findResources with JarIndex.
>> With some discussions about the bug, the current priority is to remove the
>> JAR index support in URLClassPath,
>> and don’t need to do anything to the jar tool in the short
On Wed, 8 Sep 2021 06:22:38 GMT, wxiang
wrote:
>> There is a bug for URLClassPath.findResources with JarIndex.
>> With some discussions about the bug, the current priority is to remove the
>> JAR index support in URLClassPath,
>> and don’t need to do anything to the jar tool in the short
On Tue, 7 Sep 2021 17:39:20 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/util/jar/JarVerifier.java line 147:
>>
>>> 145:
>>> 146: if (uname.equals(JarFile.MANIFEST_NAME) ||
>>> 147: uname.equals(JarFile.INDEX_NAME)) {
>>
>> It would be
> There is a bug for URLClassPath.findResources with JarIndex.
> With some discussions about the bug, the current priority is to remove the
> JAR index support in URLClassPath,
> and don’t need to do anything to the jar tool in the short term, except just
> to move JarIndex to the jdk.jartool
On Tue, 7 Sep 2021 10:39:01 GMT, Lance Andersen wrote:
>> src/java.base/share/classes/java/util/jar/JarFile.java line 220:
>>
>>> 218: * The index file name.
>>> 219: */
>>> 220: public static final String INDEX_NAME = "META-INF/INDEX.LIST";
>>
>> Adding this as a public field
73 matches
Mail list logo
