On Tue, 24 May 2022 20:40:51 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> invert if; refine jav
On Tue, 24 May 2022 20:40:51 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> invert if; refine jav
On Thu, 26 May 2022 15:43:57 GMT, XenoAmess wrote:
> > Is there any practical scenario where the current code (skip buffer
> > allocation on each invocation) creates issues?
>
> @kuksenko Not found any yet :)
In that case, what is the value of this PR? Do we need a code change for the
sake of
On Tue, 24 May 2022 20:40:51 GMT, XenoAmess wrote:
>> @jmehrens what about this then?
>> I think it safe now(actually this mechanism is learned from Reader)
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> invert if; refine jav
On Tue, 17 May 2022 04:40:50 GMT, liach wrote:
> Generic repositories, the implementation detail for generic information in
> core reflection, can be updated to use the `@Stable` annotation to replace
> their `volatile` access. Their existing accessor code is already safe,
> reading the cache
On Mon, 25 Apr 2022 04:35:13 GMT, Sergey Bylokhov wrote:
> The new test added as part of the
> [JDK-8285445](https://bugs.openjdk.java.net/browse/JDK-8285445) cannot
> trigger that bug and pass w/ and w/o fix.
>
> An updated test validates the "default" case when t
On Thu, 28 Apr 2022 15:43:09 GMT, Andrew John Hughes wrote:
>> The new test added as part of the
>> [JDK-8285445](https://bugs.openjdk.java.net/browse/JDK-8285445) cannot
>> trigger that bug and pass w/ and w/o fix.
>>
>> An updated test validates the "default" case when the
>> `jdk.io.File.e
The new test added as part of the
[JDK-8285445](https://bugs.openjdk.java.net/browse/JDK-8285445) cannot trigger
that bug and pass w/ and w/o fix.
An updated test validates the "default" case when the `jdk.io.File.enableADS`
property is not set, in this case the ADS should be
[accepted](https:
On Tue, 8 Mar 2022 13:37:44 GMT, Alexey Ivanov wrote:
>> ??? You want to check and cleanup if NewStringUTF fails. You only want to
>> call SetObjectElementArray if NewStringUTF succeeds.
>
> Can `SetObjectElementArray` raise an exception?
> The index is within the array length and we store a s
On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu wrote:
> Please review this small patch that fixes a potential memory leak that
> exception return fails to release allocated `cacheDirs`
>
> Test:
>
> - [x] jdk_desktop on Linux x86_64
src/java.desktop/unix/native/common/awt/fontpath.c line 938:
>
On Wed, 26 Jan 2022 20:05:07 GMT, Joe Darcy wrote:
> The changes in this PR on top of the out-for-review changes in
> https://git.openjdk.java.net/jdk/pull/7222 allow compile-time doclint
> checking to be enabled in all JDK modules.
>
> Typically, a @SuppressWarnings("doclint:refernce") annota
On Sat, 22 Jan 2022 21:09:03 GMT, Joe Darcy wrote:
> Use presumed syntax that will be introduced by JDK-8280488.
Marked as reviewed by serb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7189
On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote:
> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already
> buffers input stream. Hence wrapping InputStream in BufferedInputStream is
> redundant.
Marked as reviewed by serb (Reviewer).
-
PR: https://g
On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote:
> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already
> buffers input stream. Hence wrapping InputStream in BufferedInputStream is
> redundant.
The code change looks fine, but can you please check the actual perf
On Wed, 22 Dec 2021 09:07:24 GMT, Sergey Bylokhov wrote:
> This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094
>
> Currently, some of the files in the OpenJDK repo have Amazon copyright
> notices which are all slightly different and do not conform to Amazons
ionally without copyright
> year):
>
> "Copyright Amazon.com Inc. or its affiliates. All Rights Reserved."
>
> @simonis @phohensee
Sergey Bylokhov has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated
This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8244094
Currently, some of the files in the OpenJDK repo have Amazon copyright notices
which are all slightly different and do not conform to Amazons preferred
copyright notice which is simply (intentionally without copyright year):
uest to delete the
> usage of AppContext in the LogManager and related tests.
>
> Tested by tier1/tier2/tier3 and jdk_desktop tests.
Sergey Bylokhov has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains four commits:
- Merge bran
On Thu, 2 Dec 2021 10:55:57 GMT, Andrew Leonard wrote:
> This is the case at Adoptium for example, which uses the Mozilla trusted CA
> certs.
But they didn't think skipping this test was too strong a step? For example
validation of the certs expiration is quite useful. I tried to update the te
On Wed, 1 Dec 2021 18:30:06 GMT, Andrew Leonard wrote:
> Addition of a configure option --with-cacerts-src='user cacerts folder' to
> allow developers to specify their own cacerts PEM folder for generation of
> the cacerts store using the deterministic openjdk GenerateCacerts tool.
>
> Signed-
On Sat, 13 Nov 2021 23:16:22 GMT, Sergey Bylokhov wrote:
> The ZipOutputStream class may create bogus zip data which cannot be opened by
> the ZipFile. The root cause is how the comment field is stored by the
> ZipOutputStream. According to the zip specification, the comment fie
On Wed, 17 Nov 2021 10:34:52 GMT, Sergey Bylokhov wrote:
>>> Yes it would be nice to clarify that a null is accepted by setComment. When
>>> null is specified, the comment length is written as 0
>>
>> @mrserb Are you taking the spec clarification or should we jus
On Thu, 18 Nov 2021 21:51:30 GMT, Brent Christian wrote:
> Here are the code changes for the "Deprecate finalizers in the standard Java
> API" portion of JEP 421 ("Deprecate Finalization for Removal") for code
> review.
>
> This change makes the indicated deprecations, and updates the API spec
On Wed, 17 Nov 2021 18:48:00 GMT, Lance Andersen wrote:
> Sorry if my point was not clear. I would prefer to have 1 test to exercise a
> Zip file comment vs have tests in multiple areas. Expanding the existing test
> in this case keeps the primary coverage in one location and makes it easier
>
On Wed, 17 Nov 2021 12:08:37 GMT, Lance Andersen wrote:
> There appears to be a similar test,
> open/test/jdk/java/util/zip/ZipFile/Comment.java, I think we probably want to
> fold your changes into the existing test and possibly convert to use TestNG.
I know that test, and I explicitly create
On Wed, 17 Nov 2021 09:59:43 GMT, Alan Bateman wrote:
>> ZipEntry::setComment indicates that the comment will be truncated if needed
>> and ZipOutputStream takes care of this.
>>
>> Perhaps writeEND() should also be updated to something like:
>> `writeBytes(comment, 0, Math.min(comment.length,
pecified in the method/class/package so we are free
> here to implement it in any way, any thoughts/suggestions on which is better?
Sergey Bylokhov has updated the pull request incrementally with one additional
commit since the last revision:
Update EmptyComment.java
-
Changes:
On Sun, 14 Nov 2021 16:14:54 GMT, Martin Buchholz wrote:
>> Sergey Bylokhov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update EmptyComment.java
>
> test/jdk/java/util/zip/ZipOutputStream/Empty
On Sun, 14 Nov 2021 14:44:08 GMT, Lance Andersen wrote:
>> Sergey Bylokhov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update EmptyComment.java
>
> test/jdk/java/util/zip/ZipOutputStream/Empty
The ZipOutputStream class may create bogus zip data which cannot be opened by
the ZipFile. The root cause is how the comment field is stored by the
ZipOutputStream. According to the zip specification, the comment field should
not be longer than 0x bytes, and we try to validate the length of
On Fri, 29 Oct 2021 16:32:43 GMT, Mandy Chung wrote:
> The change looks okay. My suggestion is to get 1-6 all ready to push around
> the same time. It's okay to have separate JBS issues and PRs.
ok, I'll continue to work using the plan from the description.
-
PR: https://git.openj
On Thu, 28 Oct 2021 14:30:20 GMT, Alan Bateman wrote:
>> Could you please review the 8262297 bug fixes?
>>
>> In this case, ImageIO.write() should throw java.io.IOException rather than
>> java.lang.IndexOutOfBoundsException. IndexOutOfBoundsException is caught and
>> wrapped in IIOException in
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote:
> At the time Java supported applets and webstart, a special mechanism for
> launching various applications in one JVM was used to reduce memory usage and
> each application was isolated from each other.
>
> Thi
On Fri, 15 Oct 2021 07:17:52 GMT, Сергей Цыпанов wrote:
> It looks like we cannot use `Long.hashCode(long)` for
> `java.rmi.server.ObjID.hashCode()` due to specification:
> https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode().
I think this one was m
On Fri, 15 Oct 2021 07:17:52 GMT, Сергей Цыпанов wrote:
> It looks like we cannot use `Long.hashCode(long)` for
> `java.rmi.server.ObjID.hashCode()` due to specification:
> https://docs.oracle.com/en/java/javase/17/docs/api/java.rmi/java/rmi/server/ObjID.html#hashCode().
Just a suggestion, it
On Sat, 23 Oct 2021 22:13:35 GMT, Naoto Sato wrote:
>> During the review of JEP 400, a proposal to provide an overloaded method to
>> `Charset.forName()` was suggested
>> [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This
>> PR is to implement the proposal. A CSR is al
On Sun, 24 Oct 2021 16:45:15 GMT, Phil Race wrote:
> This makes the tests eligible to be run on headful systems. In practice it
> seems like ONLY headful systems actually have the sound devices. The sound
> keyword isn't understood by anything yet, so adding headful is the only way
> we have r
On Fri, 22 Oct 2021 17:33:43 GMT, Naoto Sato wrote:
>> During the review of JEP 400, a proposal to provide an overloaded method to
>> `Charset.forName()` was suggested
>> [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This
>> PR is to implement the proposal. A CSR is al
On Fri, 22 Oct 2021 17:33:43 GMT, Naoto Sato wrote:
>> During the review of JEP 400, a proposal to provide an overloaded method to
>> `Charset.forName()` was suggested
>> [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This
>> PR is to implement the proposal. A CSR is al
On Fri, 22 Oct 2021 19:01:27 GMT, Phil Race wrote:
> This fix adds "headful sound" keywords to a number of javax/sound jtreg tests
>
> The jtreg javax.sound tests are written in such a way that if a needed audio
> device
> or other platform resource is not available, they just exit with a "pass
On Thu, 21 Oct 2021 16:03:29 GMT, Naoto Sato wrote:
>> Apparently `IllegalCharsetNameException` or `IllegalArgumentException` could
>> still be thrown - so removing the `try-catch` would be a change of behaviour
>> in those cases. It all depends on whether there is a chance that these
>> excep
On Wed, 20 Oct 2021 19:02:30 GMT, Naoto Sato wrote:
>> During the review of JEP 400, a proposal to provide an overloaded method to
>> `Charset.forName()` was suggested
>> [[1]](https://github.com/openjdk/jdk/pull/4733#discussion_r669693954). This
>> PR is to implement the proposal. A CSR is al
On Thu, 1 Jul 2021 12:19:53 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) as i
On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote:
> @prrace notices this here:
> https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think
> it is the already open issue that this patch is fixing. While the original
> patch added the test in `jdk_other`, Phil suggest
On Sat, 9 Oct 2021 17:54:16 GMT, Andrey Turbanov
wrote:
> 8275002: Remove unused AbstractStringBuilder.MAX_ARRAY_SIZE
src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 240:
> 238: * OutOfMemoryError: Requested array size exceeds VM limit
> 239: */
> 240: priva
On Tue, 5 Oct 2021 00:25:41 GMT, Phil Race wrote:
>> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set
>> the name of the application in the system menu bar.
>>
>> Because this set shortly after the VM is running, it causes a thread safety
>> issue described in https://bugs
On Fri, 1 Oct 2021 21:10:27 GMT, Phil Race wrote:
>> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set
>> the name of the application in the system menu bar.
>>
>> Because this set shortly after the VM is running, it causes a thread safety
>> issue described in https://bugs
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote:
> At the time Java supported applets and webstart, a special mechanism for
> launching various applications in one JVM was used to reduce memory usage and
> each application was isolated from each other.
>
> Thi
On Mon, 27 Sep 2021 23:50:38 GMT, Phil Race wrote:
>> macOS launcher code sets JAVA_MAIN_CLASS_ which is read by AWT to set
>> the name of the application in the system menu bar.
>>
>> Because this set shortly after the VM is running, it causes a thread safety
>> issue described in https://bug
On Thu, 23 Sep 2021 08:54:48 GMT, Aleksey Shipilev wrote:
> @prrace notices this here:
> https://github.com/openjdk/jdk/pull/5544#issuecomment-925396869. And I think
> it is the already open issue that this patch is fixing. While the original
> patch added the test in `jdk_other`, Phil suggest
On Fri, 17 Sep 2021 06:59:09 GMT, Aleksey Shipilev wrote:
>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups,
>> @iignatev suggested to create tier4 groups that capture all tests not in
>> tiers{1,2,3}.
>>
>> Caveats:
>> - I excluded `applications` from `hotspot:tier4`,
On Mon, 6 Sep 2021 09:39:58 GMT, Alan Bateman wrote:
> No objection to removing this legacy/unused code but I think it would be
> useful to useful to have the JBS issue or the PR summary provide a bit more
> context. As I see it, this is just one piece of the overall cleanup and I
> assume the
On Wed, 1 Sep 2021 06:31:16 GMT, Sergey Bylokhov wrote:
> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing"
> via an AppContext to support "applet logging isolation". The AppContext class
> became useless since the plugin a
On Thu, 9 Sep 2021 20:14:01 GMT, Andy Herrick wrote:
> backport from jdk-18
Is it for jdk17 or for jdk17u?
-
PR: https://git.openjdk.java.net/jdk17/pull/306
On Sat, 4 Sep 2021 02:51:50 GMT, Sergey Bylokhov wrote:
>> During the review of JDK-8272914 that added hotspot:tier{2,3} groups,
>> @iignatev suggested to create tier4 groups that capture all tests not in
>> tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` bec
On Mon, 6 Sep 2021 09:39:58 GMT, Alan Bateman wrote:
> As I see it, this is just one piece of the overall cleanup and I assume there
> are more substantive changes to the java.desktop module coming, is that right?
Yes, you are right.
-
PR: https://git.openjdk.java.net/jdk/pull/532
On Fri, 3 Sep 2021 09:10:20 GMT, Aleksey Shipilev wrote:
> During the review of JDK-8272914 that added hotspot:tier{2,3} groups,
> @iignatev suggested to create tier4 groups that capture all tests not in
> tiers{1,2,3}. I have excluded `vmTestbase` and `hotspot:tier4,` because they
> take 10+
On Thu, 2 Sep 2021 09:59:51 GMT, Daniel Fuchs wrote:
>> The "java.util.logging.LogManager" class uses the "threadgroup sandboxing"
>> via an AppContext to support "applet logging isolation". The AppContext
>> class became useless since the plugin and webstart are no longer supported
>> and rem
On Fri, 3 Sep 2021 17:37:08 GMT, Sergey Bylokhov wrote:
>> Current implementation looks like this:
>>
>> public byte[] getBytes(String charsetName)
>> throws UnsupportedEncodingException {
>> if (charsetName == null) throw new NullPointerExc
On Fri, 3 Sep 2021 17:19:05 GMT, Phil Race wrote:
> Perhaps this isn't the change that requires the CSR but it then leaves an
> inconsistent state where desktop supports AppContext still but other modules
> don't ...
Even java.desktop does not support it fully, since for a couple of years nobo
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 encode(lookupCharset(char
The "java.util.logging.LogManager" class uses the "threadgroup sandboxing" via
an AppContext to support "applet logging isolation". The AppContext class
became useless since the plugin and webstart are no longer supported and
removed in jdk11.
This is the request to delete the usage of AppConte
On Tue, 31 Aug 2021 09:40:14 GMT, xpbob
wrote:
> 8273169: java/util/regex/NegativeArraySize.java failed after JDK-8271302
Marked as reviewed by serb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/5315
On Mon, 30 Aug 2021 15:52:05 GMT, Ian Graves wrote:
>> 8271302: Regex Test Refresh
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Removing some notes re JUnit5
Looks like it was missed that the test fails oi a github action
On Mon, 23 Aug 2021 21:01:48 GMT, Andrey Turbanov
wrote:
> Collections.sort is just a wrapper, so it is better to use an instance method
> directly.
The changes in the src/java.desktop/ looks fine.
Filed: https://bugs.openjdk.java.net/browse/JDK-8272863
-
Marked as reviewed by s
On Mon, 23 Aug 2021 14:34:52 GMT, Andy Herrick wrote:
>> JDK-8272639: jpackaged applications using microphone on mac
>
> Andy Herrick has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8272639: jpackaged applications using microphone on ma
This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
See https://github.com/openjdk/jdk/pull/5063 and
https://github.com/openjdk/jdk/pull/4951
In many places standard charsets are looked up via their names, for example:
absolutePath.getBytes("UTF-8");
This could be done more ef
On Thu, 19 Aug 2021 14:12:00 GMT, Andy Herrick wrote:
> JDK-8272639: jpackaged applications using microphone on mac
src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/Info-lite.plist.template
line 37:
> 35: true
> 36: NSMicrophoneUsageDescription
> 37: The application is req
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884 and JDK-8271456. This change affects
> fewer cases so I fix all "java." modules at once.
>
> In many places standard charsets are looked up via their names, for example:
&
On Tue, 10 Aug 2021 09:18:39 GMT, Alan Bateman wrote:
> It would be useful to get up to date performance data on using Charset vs.
> charset name. At least historically, the charset name versions were faster
> (see [JDK-6764325](https://bugs.openjdk.java.net/browse/JDK-6764325)).
The code in q
This is the continuation of JDK-8233884 and JDK-8271456. This change affects
fewer cases so I fix all "java." modules at once.
In many places standard charsets are looked up via their names, for example:
absolutePath.getBytes("UTF-8");
This could be done more efficiently(up to x20 time faster) w
On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov
wrote:
> I found few places, where code initially perform `Object[]
> Colleciton.toArray()` call and then manually copy array into another array
> with required type.
> This PR cleanups such places to more shorter call `T[]
> Collection.toArra
On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev
wrote:
> Dear colleagues,
>
> Please review the patch that replaces the lambdas with anonymous classes
> which solves the startup time regression as shown below.
>
> I attached the Bytestacks flamegraphs for both origina
On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov
wrote:
> I found few places, where code initially perform `Object[]
> Colleciton.toArray()` call and then manually copy array into another array
> with required type.
> This PR cleanups such places to more shorter call `T[]
> Collection.toArra
On Fri, 23 Jul 2021 18:03:31 GMT, Sergey Chernyshev
wrote:
> Dear colleagues,
>
> Please review the patch that replaces the lambdas with anonymous classes
> which solves the startup time regression as shown below.
>
> I attached the Bytestacks flamegraphs for both origina
Dear colleagues,
Please review the patch that replaces the lambdas with anonymous classes which
solves the startup time regression as shown below.
I attached the Bytestacks flamegraphs for both original (regression) and fixed
versions. The flamegraphs clearly show the lambdas were causing the p
On Wed, 17 Mar 2021 00:57:24 GMT, Henry Jen wrote:
>> This patch ensure launcher won't crash JVM for the new static Methods from
>> local/anonymous class on MacOS.
>>
>> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug
>> when the launcher trying to grab class name to
On Tue, 16 Mar 2021 17:39:34 GMT, Henry Jen wrote:
>> test/jdk/tools/launcher/8261785/CrashTheJVM.java line 1:
>>
>>> 1: import java.io.IOException;
>>
>> Copyright?
>
> This file is mostly based on the bug report as I just adjust static keyword
> to make sure we cover different cases, thus I
On Tue, 16 Mar 2021 01:55:49 GMT, Sergey Bylokhov wrote:
>> This patch ensure launcher won't crash JVM for the new static Methods from
>> local/anonymous class on MacOS.
>>
>> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug
>> whe
On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen wrote:
> This patch ensure launcher won't crash JVM for the new static Methods from
> local/anonymous class on MacOS.
>
> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug
> when the launcher trying to grab class name to be di
On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen wrote:
> This patch ensure launcher won't crash JVM for the new static Methods from
> local/anonymous class on MacOS.
>
> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug
> when the launcher trying to grab class name to be di
On Mon, 15 Mar 2021 18:04:26 GMT, Сергей Цыпанов
wrote:
>> In some cases wrapping of `InputStream` with `BufferedInputStream` is
>> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which
>> does not require any buffer having one within.
>>
>> Other cases are related to readi
On Sun, 14 Mar 2021 19:35:25 GMT, Сергей Цыпанов
wrote:
>> In some cases wrapping of `InputStream` with `BufferedInputStream` is
>> redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which
>> does not require any buffer having one within.
>>
>> Other cases are related to readi
On Fri, 5 Mar 2021 18:53:29 GMT, Claes Redestad wrote:
>> This patch refactors Locale.getDefault(Category) so that the volatile field
>> holding the Locale is typically only read once. This has a small performance
>> advantage, and might be more robust if initialization is racy.
>
> Claes Redes
On Sat, 6 Mar 2021 13:34:14 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/util/Locale.java line 946:
>>
>>> 944: Locale loc = defaultDisplayLocale; // volatile read
>>> 945: if (loc == null) {
>>> 946: loc = getDisplayLocale();
>>
>> Just
On Fri, 5 Mar 2021 18:53:29 GMT, Claes Redestad wrote:
>> This patch refactors Locale.getDefault(Category) so that the volatile field
>> holding the Locale is typically only read once. This has a small performance
>> advantage, and might be more robust if initialization is racy.
>
> Claes Redes
On Wed, 3 Feb 2021 04:01:51 GMT, Sergey Bylokhov wrote:
> Trivial cleanup, the "default" license header is removed in a few components.
This pull request has now been integrated.
Changeset: f279ff9d
Author:Sergey Bylokhov
URL: https://git.openjdk.java.net/jdk/commit/f
Trivial cleanup, the "default" license header is removed in a few components.
-
Commit messages:
- Initial fix
Changes: https://git.openjdk.java.net/jdk/pull/2368/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2368&range=00
Issue: https://bugs.openjdk.java.net/browse
On Sun, 20 Dec 2020 20:33:43 GMT, Phil Race wrote:
>>> One or two of the sources changes should probably uses Files.copy, e.g.
>>> ZipPath, sjavac/CopyFile.java.
>>
>> Good idea! Replaced in few places. But not in ZipPath: it's actually
>> implementation of underlying call from Files.copy:
>>
On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman wrote:
>> This change terminally deprecates the following methods defined by
>> java.lang.ThreadGroup
>>
>> - stop
>> - destroy
>> - isDestroyed
>> - setDaemon
>> - isDaemon
>>
>> The stop method has been deprecated since=1.2 because it is i
On Thu, 19 Nov 2020 18:51:50 GMT, Sergey Bylokhov wrote:
>> This change terminally deprecates the following methods defined by
>> java.lang.ThreadGroup
>>
>> - stop
>> - destroy
>> - isDestroyed
>> - setDaemon
>> - isDaemon
>>
>&
On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman wrote:
> This change terminally deprecates the following methods defined by
> java.lang.ThreadGroup
>
> - stop
> - destroy
> - isDestroyed
> - setDaemon
> - isDaemon
>
> The stop method has been deprecated since=1.2 because it is inherently
On Thu, 19 Nov 2020 19:29:43 GMT, Brian Burkhalter wrote:
> Please review this modification of `java.io.InputStream.skipNBytes(long)` to
> improve its performance when `skip(long)` skips fewer than the requested
> number of bytes. In the current implementation, `skip(long)` is invoked once
> a
On Fri, 13 Nov 2020 18:20:37 GMT, Kevin Rushforth wrote:
>> Andy Herrick has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> src/java.desktop/share/classes/java/applet/package-info.java
On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo wrote:
> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author
> unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`, `0xC`, or `^L`) characters
Marked as reviewed by serb (Reviewer).
On Mon, 2 Nov 2020 11:59:09 GMT, Maurizio Cimadamore
wrote:
>> This patch contains the changes associated with the third incubation round
>> of the foreign memory access API incubation (see JEP 393 [1]). This
>> iteration focus on improving the usability of the API in 3 main ways:
>>
>> * fi
On Wed, 28 Oct 2020 08:40:02 GMT, Сергей Цыпанов
wrote:
>> client changes are fine
>
> Rebased onto master to have the fix introduced in
> https://github.com/openjdk/jdk/pull/778
FYI it is better to use merge, instead of rebase+force push. Rebase breaks
history and all existed code comments.
On Thu, 22 Oct 2020 20:46:15 GMT, Сергей Цыпанов
wrote:
> As discussed in https://github.com/openjdk/jdk/pull/510 there is never a
> reason to explicitly instantiate any instance of `Atomic*` class with its
> default value, i.e. `new AtomicInteger(0)` could be replaced with `new
> AtomicInteg
On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov wrote:
> In some files, the copyright text is styled as a JavaDoc comment.
> Most of the affected files are tests, only one product file is affected:
> src/java.sql/share/classes/javax/sql/package-info.java
>
> The ch
In some files, the copyright text is styled as a JavaDoc comment.
Most of the affected files are tests, only one product file is affected:
src/java.sql/share/classes/javax/sql/package-info.java
The chenge is trivial:
- /**
+ /*
* Copyright (c)
-
Commit messages:
- Initial fix
1 - 100 of 239 matches
Mail list logo