On Mon, 30 Jun 2025 06:01:44 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this doc-only change which proposes to clarify
>> the current implementation of the `java.util.Properties.list(...)` methods?
>>
>> As noted in https://bugs.openjdk.org/browse/JDK-8360575, the current
>> impl
On Wed, 30 Apr 2025 23:38:02 GMT, Brian Burkhalter wrote:
> This change proposes to modify `java.io.File.delete()` so that regular files
> on Windows will not be deleted by default if their read-only attribute is
> set. A boolean-valued system compatibility property
> `jdk.io.File.deleteReadOn
On Fri, 28 Feb 2025 12:29:04 GMT, David Beaumont wrote:
>The former is, in my opinion, a pretty awful user experience...
Specifically, I'm referring to this, with awareness of the above described
limitations:
//String.format is var-arg
logger.log(Level.SEVERE, () -> { return String.format("foo
On Fri, 28 Feb 2025 14:23:49 GMT, David Beaumont wrote:
>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
>> publish() method.
>>
>> 1. Remove synchronization of calls to publish() in Handlers in
>> java.util.logging package.
>> 2. Add explanatory comments to various affe
On Thu, 27 Feb 2025 12:46:36 GMT, David Beaumont wrote:
>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
>> publish() method.
>>
>> 1. Remove synchronization of calls to publish() in Handlers in
>> java.util.logging package.
>> 2. Add explanatory comments to various affe
On Tue, 25 Feb 2025 01:24:54 GMT, Stuart Marks wrote:
>> As for the example you gave there, that is interesting. Keeping an
>> unformatted log record around for any time after the log statement that
>> created it has exited would be quite problematic (it prevents GC of
>> arbitrary things).
>>
On Tue, 18 Feb 2025 09:56:21 GMT, David Beaumont wrote:
>I'm afraid I don't see how the double-check idea would work...
Yep. I missed that case.
>The other option is to just allow the lock to be dropped.
The other options are many. Leader-follower pattern would allow FileHandler to
not hold
On Mon, 17 Feb 2025 13:52:33 GMT, David Beaumont wrote:
>>>I've looked through a lot of github logging properties files and see no
>>>evidence that the pattern of use...
>>
>> Closed source GOTS/COTS products that require troubleshooting require using
>> all of the logging API features when ot
On Fri, 14 Feb 2025 10:46:08 GMT, David Beaumont wrote:
>> I've looked through a lot of github logging properties files and see no
>> evidence that the pattern of use you're suggesting is ever actually done,
>> and any such attempt to force one-log-per-file is entirely unsupported by
>> the ex
On Thu, 6 Feb 2025 12:07:57 GMT, David Beaumont wrote:
> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
> publish() method.
>
> 1. Remove synchronization of calls to publish() in Handlers in
> java.util.logging package.
> 2. Add explanatory comments to various affected me
On Thu, 13 Feb 2025 22:43:59 GMT, David Beaumont wrote:
>Yes, it's certainly something you can deliberately provoke in a way that
>wasn't possible before.
Setting limit to 1 byte with a large count is a way to make sure each log file
contains 0 or 1 log record. I think this patch breaks that
On Thu, 13 Feb 2025 09:32:29 GMT, David Beaumont wrote:
>> hmmm... Thanks for chiming in Jason. Good point. So what can happen here is
>> that if multiple threads log concurrently to the same FileHandler then log
>> records might continue to get written to the file after the limit has been
>>
On Thu, 6 Feb 2025 12:07:57 GMT, David Beaumont wrote:
> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
> publish() method.
>
> 1. Remove synchronization of calls to publish() in Handlers in
> java.util.logging package.
> 2. Add explanatory comments to various affected me
For store method, I wish it was:
1. Null comment, meant no comment and no date.
2. Empty comment, meant date only.
3. Not blank comment, meant comment line and date.
However, too late to change that behavior.
It would be nice if the JDK had a FilterWriter implementation that decorated a
Writer t
On Mon, 21 Oct 2024 15:44:58 GMT, Markus KARG wrote:
>> This Pull Requests proposes an implementation for
>> [JDK-8341566](https://bugs.openjdk.org/browse/JDK-8341566): Adding the new
>> method `public static Reader Reader.of(CharSequence)` will return an
>> anonymous, non-synchronized impleme
On Tue, 23 Apr 2024 16:08:13 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 164:
>>
>>> 162: public void writeTo(OutputStream out) throws IOException {
>>> 163: if (Thread.currentThread().isVirtual()) {
>>> 164: out.write(t
On Mon, 22 Apr 2024 19:49:44 GMT, Brian Burkhalter wrote:
>> Prevent blocking due to a carrier thread not being released when
>> `ByteArrayOutputStream.writeTo` is invoked from a virtual thread.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since t
See: https://bugs.openjdk.org/browse/JDK-8193128
Jason
From: core-libs-dev on behalf of Ryan Ernst
Sent: Friday, February 2, 2024 1:42 PM
To: core-libs-dev@openjdk.org
Subject: Object creation from iterating Map.of()/Set.of()/List.of()
The newer “of” methods i
ethod to perform a shuffle
without having to use asList.
Jason
From: Tagir Valeev
Sent: Saturday, October 1, 2022 2:24 AM
To: Jason Mehrens
Cc: Paul Sandoz; core-libs-dev@openjdk.org
Subject: Re: Collections.shuffle to accept RandomGenerator
Thanks,
JDK20 has Random.from(RandomGenerator) which could be used to do something like
Collections.shuffle(List, Random.from(rg)).
List.shuffle(RandomGenerator ) would allow for more efficient
CopyOnWriteArrayList shuffle.
Jason
From: core-libs-dev on behalf
have the same problem.
Jason
From: Zelva Lia
Sent: Wednesday, August 24, 2022 5:46 PM
To: Jason Mehrens
Cc: core-libs-dev@openjdk.org
Subject: Re: CopyOnWriteArrayList Collection.shuffle
Well, yes, this is a solvable problem, albeit with additional copying,
CopyOnWriteArrayList implements an efficient List::replaceAll so you could do
something like:
public static void main(String[] args) {
List cowl = new CopyOnWriteArrayList<>(new
String[]{"1","2","3"});
List copy = Arrays.asList(cowl.toArray(new String[0]));
Collectio
22 matches
Mail list logo
