On Wed, 19 Jan 2022 22:18:32 GMT, Weijun Wang wrote:
> Two edits.
src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java
line 727:
> 725: Handler handler;
> 726: /**
> 727: * Constructs a {@code DoubleClickListener}.
This change is under review
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:
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
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
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
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
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:
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.
>
>
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
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.
>
>
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
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 plug
On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov
wrote:
> Using `ByteArrayOutputStream.toString` to convert it's content to a String is
> cleaner than `new String(out.toByteArray())`. Also it's a bit faster because
> of one less array copy.
BTW If it is not urgent I suggest to wait 24 hours
On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov
wrote:
> Using `ByteArrayOutputStream.toString` to convert it's content to a String is
> cleaner than `new String(out.toByteArray())`. Also it's a bit faster because
> of one less array copy.
Marked as reviewed by serb (Reviewer).
On Thu, 2 Sep 2021 20:19:40 GMT, Andrey Turbanov
wrote:
> Using `ByteArrayOutputStream.toString` to convert it's content to a String is
> cleaner than `new String(out.toByteArray())`. Also it's a bit faster because
> of one less array copy.
Looks fine
-
PR:
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:
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
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
On Sun, 22 Aug 2021 02:53:44 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>
> In many places standard charsets are looked up via their names, for example:
> absolutePath.getBytes("UTF-8");
>
> This could be don
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
n this fix: the Xerces library(should be fixed upstream),
> J2DBench(should be compatible to 1.4), some code in the network(the change
> there are not straightforward, will do it later).
>
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
Sergey Bylokhov has updated the
n this fix: the Xerces library(should be fixed upstream),
> J2DBench(should be compatible to 1.4), some code in the network(the change
> there are not straightforward, will do it later).
>
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
Sergey Bylokhov has updated the
On Thu, 26 Aug 2021 17:39:36 GMT, Sergey Bylokhov wrote:
>> 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 changes
>> brought in by the merge/rebase. The pull request cont
On Sun, 22 Aug 2021 23:02:06 GMT, Sergey Bylokhov wrote:
>> This is the continuation of JDK-8233884, JDK-8271456, and JDK-8272120.
>>
>> In many places standard charsets are looked up via their names, for example:
>> absolutePath.getBytes("UTF-8");
>>
&
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
On Sun, 22 Aug 2021 15:09:26 GMT, Alan Bateman wrote:
>> 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 changes
>> brought in by the merge/rebase. The pull request cont
On Sun, 22 Aug 2021 18:31:02 GMT, Andrey Turbanov
wrote:
> I think it's worth to update _static_ initializer in
> `sun.datatransfer.DataFlavorUtil.CharsetComparator` too.
Updated as suggested.
-
PR: https://git.openjdk.java.net/jdk/pull/5210
n this fix: the Xerces library(should be fixed upstream),
> J2DBench(should be compatible to 1.4), some code in the network(the change
> there are not straightforward, will do it later).
>
> Tested by the tier1/tier2/tier3 tests on Linux/Windows/macOS.
Sergey Bylokhov has updated the
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
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
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)
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[]
>
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[]
>
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 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:
>>
>> *
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
>
On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy
wrote:
> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could
> be found
>
> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
Hi, Sean.
One question related to SecurityManager and performance, is it possible
to provide a special version of AccessController.doPrivileged which will
be noop if SecurityManager is not present?
On 03/10/2018 13:12, Sean Mullan wrote:
For those of you that are not also subscribed to
Hi, Joe.
On 06/08/2018 14:30, joe darcy wrote:
Even if currently less commonly used, I think "ineffectual" better
captures the intention of what I want to convey in the comment than
"ineffective."
Can you please clarify this: what does it mean "ineffectual" in this
context? why we need to
cc 2d-dev.
On 30.11.16 18:41, Lindenmaier, Goetz wrote:
Hi Vincent,
thanks for the quit review!
Good catch that I lost the change to p11_mutex.c ... I had to change
it and it fell out of my patches.
I edited the Last Modified Date, and also updated the copyright messages.
New webrev:
The fix looks fine to me. can you please clarify what "enabling better
reporting" from the bug description means? Where this information will
be reported?
On 31.03.16 2:48, Joseph D. Darcy wrote:
Hi Mandy,
Hopefully the third time will be the charm for this changeset after your
correction to
Looks fine.
On 12.03.16 6:28, joe darcy wrote:
Hello,
As Jon Gibbons has noted off-list, the problem list entries can directly
include the bug number associated with the test in question, enabling
better reporting. This format should be used rather than the current
convention of putting the
the Thread.sleep. It doesn't appear to be needed.
Pete
On 7/14/15 5:00 AM, Sergey Bylokhov wrote:
Hi, Pete.
The fix looks fine, but you should tweak the test a little bit.
- You access the swing components on non-EDT thread.
- You should not use System.exit in the test.
- The JFrame should
Hi, Pete.
The fix looks fine, but you should tweak the test a little bit.
- You access the swing components on non-EDT thread.
- You should not use System.exit in the test.
- The JFrame should be disposed before the end of the test.
On 14.07.15 1:34, Pete Brunet wrote:
Please review the
49 matches
Mail list logo
