On Fri, 17 Jun 2022 16:33:16 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review this patch for JDK 19 to address a broken link due to PKWare
> moving the location for APPNOTE.txt
>
> Best,
> Lance
I would change to the imperfect
https://urldefense.com/v3/__https://pkware.cachefly.net/webd
On Fri, 17 Jun 2022 16:33:16 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review this patch for JDK 19 to address a broken link due to PKWare
> moving the location for APPNOTE.txt
>
> Best,
> Lance
I've never communicated with pkware, but this might be a good first time to
email zipfor...
On Fri, 17 Jun 2022 16:33:16 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review this patch for JDK 19 to address a broken link due to PKWare
> moving the location for APPNOTE.txt
>
> Best,
> Lance
Marked as reviewed by martin (Reviewer).
I'm pleasantly surprised broken doc links are a re
On Wed, 24 Aug 2022 18:15:17 GMT, Aleksey Shipilev wrote:
> [JDK-8026344](https://bugs.openjdk.org/browse/JDK-8026344) added tests that
> subtly contradict the contract for `{Double,Long}Accumulator`-s, which breaks
> the tests on some platforms even in the single-threaded case.
>
> They use a
On Wed, 7 Sep 2022 12:44:11 GMT, Doug Lea wrote:
> 8292969: This small change in signal propagation rules improves utilization
> when entry queues are resized,
scan's @return needs to be changed to indicate it also now returns a packed int
-
Changes requested by martin (Reviewer).
On Fri, 25 Nov 2022 14:53:57 GMT, Alan Bateman wrote:
> Two (since 19) usages of Unsafe.getAndAddInt to update a static field provide
> the Class object as the base instead of the base object returned by
> Unsafe.staticFieldBase. This doesn't change anything on the HotSpot VM.
The introduction
On Tue, 10 Jan 2023 10:32:34 GMT, Per Minborg wrote:
> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been
> updated to reflect the current state of Java and can be modernized:
>
> * Add `@Serial` annotations
> * Seal classes and restrict subclassing for internal class
On Tue, 10 Jan 2023 10:32:34 GMT, Per Minborg wrote:
> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been
> updated to reflect the current state of Java and can be modernized:
>
> * Add `@Serial` annotations
> * Seal classes and restrict subclassing for internal class
On Tue, 10 Jan 2023 10:32:34 GMT, Per Minborg wrote:
> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been
> updated to reflect the current state of Java and can be modernized:
>
> * Add `@Serial` annotations
> * Seal classes and restrict subclassing for internal class
On Tue, 10 Jan 2023 10:32:34 GMT, Per Minborg wrote:
> `java.util.concurrent.ConcurrentHashMap` is relatively old and has not been
> updated to reflect the current state of Java and can be modernized:
>
> * Add `@Serial` annotations
> * Seal classes and restrict subclassing for internal class
On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 wrote:
>> The enanchment is useful for applications that make heavy use of BitSet
>> objects as sets of integers, and therefore they need to make a lot of calls
>> to cardinality() method, which actually require linear time in the number of
>> wor
On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 wrote:
>> The enanchment is useful for applications that make heavy use of BitSet
>> objects as sets of integers, and therefore they need to make a lot of calls
>> to cardinality() method, which actually require linear time in the number of
>> wor
On Wed, 18 Jan 2023 12:43:31 GMT, fabioromano1 wrote:
>> The enanchment is useful for applications that make heavy use of BitSet
>> objects as sets of integers, and therefore they need to make a lot of calls
>> to cardinality() method, which actually require linear time in the number of
>> wor
On Mon, 20 Feb 2023 18:34:17 GMT, Alan Bateman wrote:
> Executors.newSingleThreadExecutor returns a delegating ExecutorService that
> has finalizer to shutdown the underlying TPE when the wrapper is finalizable.
> It goes back to JDK 6 and JDK-6399443. This is the last non-empty finalizer
> in
On Tue, 21 Feb 2023 18:24:05 GMT, Alan Bateman wrote:
>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that
>> has finalizer to shutdown the underlying TPE when the wrapper is
>> finalizable. It goes back to JDK 6 and JDK-6399443. This is the last
>> non-empty finalize
On Tue, 21 Feb 2023 16:36:26 GMT, Alan Bateman wrote:
>> test/jdk/java/util/concurrent/Executors/AutoShutdown.java line 133:
>>
>>> 131: while (!terminated) {
>>> 132: System.gc();
>>> 133: terminated = executor.awaitTermination(100,
>>> TimeUnit.MILLISECONDS);
>
#x27;ASCII trick' comment in the JDK. I
>> found it in ZipFile.isMetaName, which is also where I first learned about
>> this interesting relationship between ASCII (and also latin1) letters.
>>
>> The comment was first added by Martin Buchholz back in 2016 as part of
>&
On Tue, 21 Feb 2023 20:48:04 GMT, Martin Buchholz wrote:
>> Perhaps @Martin-Buchholz could chime in and also tell us which book he found
>> his ASCII trick in :)
>
> "oldest trick in the book" is a phrase that does not necessarily imply
> existence of an actu
On Wed, 22 Feb 2023 00:06:51 GMT, David Holmes wrote:
>> Thanks Martin, I will from now on envision a stack of dusty punch cards with
>> carefully scribbled notes on the back, barely held together with a dry and
>> cracked rubber band.
>>
>> More to the point: Do you have an opinion on the app
On Wed, 22 Feb 2023 00:45:52 GMT, Martin Buchholz wrote:
>> There are still some books on this :) but from wikipedia:
>>> during May 1963 the CCITT Working Party on the New Telegraph Alphabet
>>> proposed to assign lowercase characters to
>>> sticks[[a]](ht
On Wed, 22 Feb 2023 07:12:35 GMT, Eirik Bjorsnos wrote:
>>> Do you have an opinion on the appropriate level of documentation / comments
>>> for this kind of 'tricky' code?
>>
>> This code is not that tricky! And the proposed level of documentation is
>> excessive! A couple of lines of expla
On Wed, 22 Feb 2023 07:11:16 GMT, Eirik Bjorsnos wrote:
>> This PR suggests we can speed up `StringLatin1.regionMatchesCI` by applying
>> 'the oldest ASCII trick in the book'.
>>
>> The new static method `CharacterDataLatin1.equalsIgnoreCase` compares two
>> latin1 bytes for equality ignoring
On Thu, 23 Feb 2023 08:31:36 GMT, Alan Bateman wrote:
>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that
>> has finalizer to shutdown the underlying TPE when the wrapper is
>> finalizable. It goes back to JDK 6 and JDK-6399443. This is the last
>> non-empty finalize
On Thu, 23 Feb 2023 08:31:36 GMT, Alan Bateman wrote:
>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that
>> has finalizer to shutdown the underlying TPE when the wrapper is
>> finalizable. It goes back to JDK 6 and JDK-6399443. This is the last
>> non-empty finalize
On Thu, 23 Feb 2023 08:31:36 GMT, Alan Bateman wrote:
>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that
>> has finalizer to shutdown the underlying TPE when the wrapper is
>> finalizable. It goes back to JDK 6 and JDK-6399443. This is the last
>> non-empty finalize
On Thu, 23 Feb 2023 15:36:48 GMT, Viktor Klang wrote:
> Clarifies the distinction between expiration of the head of DelayQueue and
> how it relates to `poll`, `take`, and `peek`. See discussion on
> https://bugs.openjdk.org/browse/JDK-8297605
>
> @DougLea If possible, please weigh in on whethe
On Thu, 23 Feb 2023 15:36:48 GMT, Viktor Klang wrote:
> Clarifies the distinction between expiration of the head of DelayQueue and
> how it relates to `poll`, `take`, and `peek`. See discussion on
> https://bugs.openjdk.org/browse/JDK-8297605
>
> @DougLea If possible, please weigh in on whethe
On Thu, 23 Feb 2023 15:36:48 GMT, Viktor Klang wrote:
> Clarifies the distinction between expiration of the head of DelayQueue and
> how it relates to `poll`, `take`, and `peek`. See discussion on
> https://bugs.openjdk.org/browse/JDK-8297605
>
> @DougLea If possible, please weigh in on whethe
On Fri, 24 Feb 2023 13:44:40 GMT, Alan Bateman wrote:
>> Executors.newSingleThreadExecutor returns a delegating ExecutorService that
>> has finalizer to shutdown the underlying TPE when the wrapper is
>> finalizable. It goes back to JDK 6 and JDK-6399443. This is the last
>> non-empty finalize
On Thu, 23 Feb 2023 21:20:27 GMT, Martin Buchholz wrote:
>> Clarifies the distinction between expiration of the head of DelayQueue and
>> how it relates to `poll`, `take`, and `peek`. See discussion on
>> https://bugs.openjdk.org/browse/JDK-8297605
>>
>> @DougLe
On Wed, 1 Mar 2023 00:24:31 GMT, Justin Lu wrote:
> The following typo: `@returnss` was reported on line _482 of Reflection
> Factory.java_.
>
> In addition to fixing that, I have replaced multiple instances of `@returns`
> with `@return` in the same file.
Marked as reviewed by martin (Review
On Mon, 27 Feb 2023 20:09:12 GMT, Martin Buchholz wrote:
> I wonder if there's now a way to override javadoc for remove() without
> creating a new method body.
I thought recent javadoc features might have been useful here, but I scanned
the results from this jql:
subcomponent in
On Thu, 2 Mar 2023 02:03:51 GMT, Martin Buchholz wrote:
>>> @Martin-Buchholz Martin, how would you like to proceed with your proposed
>>> wording, would you prefer a suggested edit to this PR, do a separate PR, or
>>> otherwise? /cc @AlanBateman (any rec
Inviting @DougLea and @viktorklang-ora to review.
As usual, I couldn't resist more fiddling.
- Added missing tests for take, remove(), remove(Object).
- Improved DelayQueueTest's testing infrastructure
- added more test assertions
- linkified new javadoc definitions
-
Commit messag
On Mon, 6 Mar 2023 13:23:59 GMT, Viktor Klang wrote:
> I think the following proposal is very non-invasive and merely draws
> attention to the fact that "witness value" is a specific term related to the
> notion of these atomic methods.
>
> It's a small change which I think provides additional
On Thu, 2 Mar 2023 15:59:33 GMT, Martin Buchholz wrote:
> Right. But remove(Object) unlike remove() doesn't consider the expiration
> time. Confusing!
Actually, confusion extends to **three** methods with the same name:
- `Queue.remove()`
- `Collection.remove(Object)`
- `Iter
On Sun, 12 Mar 2023 10:00:50 GMT, Eirik Bjorsnos wrote:
>> Please review this PR which speeds up TestTooManyEntries and clarifies its
>> purpose:
>>
>> - The name 'TestTooManyEntries' does not clearly convey the purpose of the
>> test. What is tested is the validation that the total CEN size f
On Sun, 12 Mar 2023 21:25:46 GMT, Eirik Bjorsnos wrote:
>> Please review this PR which speeds up TestTooManyEntries and clarifies its
>> purpose:
>>
>> - The name 'TestTooManyEntries' does not clearly convey the purpose of the
>> test. What is tested is the validation that the total CEN size f
> Inviting @DougLea and @viktorklang-ora to review.
>
> As usual, I couldn't resist more fiddling.
> - Added missing tests for take, remove(), remove(Object).
> - Improved DelayQueueTest's testing infrastructure
> - added more test assertions
> - linkified
On Wed, 14 Dec 2022 17:43:08 GMT, nbauma109 wrote:
> I think this is a typo
Marked as reviewed by martin (Reviewer).
No CSR required for typos in code samples.
-
PR Review: https://git.openjdk.org/jdk/pull/11679#pullrequestreview-1314583164
PR Comment: https://git.openjdk.org/jdk/
On Thu, 26 Jan 2023 18:49:47 GMT, Eirik Bjorsnos wrote:
> The TestTooManyEntries test was originally added to validate that ZIP64 files
> with CEN sizes exceeding what ZipFile supports are rejected with a
> ZipException. The test does this by creating a large ZIP file (several
> gigabytes) wi
On Sat, 25 Mar 2023 10:59:36 GMT, Lance Andersen wrote:
>> If by "standard" you mean "APPNOTE.TXT", then that uses "end of central
>> directory record" which is a bit long.
>>
>> The Java implementation seems to use END, like in `ZipFile.ENDHDR`, "END
>> header", etc.
>>
>> It is probably bet
On Sat, 25 Mar 2023 12:12:21 GMT, Eirik Bjorsnos wrote:
>> The TestTooManyEntries test was originally added to validate that ZIP64
>> files with CEN sizes exceeding what ZipFile supports are rejected with a
>> ZipException. The test does this by creating a large ZIP file (several
>> gigabytes
On Sat, 25 Mar 2023 12:18:46 GMT, Eirik Bjorsnos wrote:
>> So I changed the references to this ultimate ZIP structure to read like this:
>>
>> 'End of central directory record' (END header)
>>
>> Example:
>>
>>
>> /**
>> * Validate that an 'End of central directory record' (END header)
>
On Thu, 2 Mar 2023 20:00:56 GMT, Martin Buchholz wrote:
> Inviting @DougLea and @viktorklang-ora to review.
>
> As usual, I couldn't resist more fiddling.
> - Added missing tests for take, remove(), remove(Object).
> - Improved DelayQueueTest's testing infrastru
On Fri, 31 Mar 2023 13:51:22 GMT, Eirik Bjorsnos wrote:
>> CorruptedZipFiles could benefit from some spring cleaning and a conversion
>> to junit:
>>
>> - The actual tests are moved into their own `@Test` methods, given more
>> meaningful names and a Javadoc comment explaining the constraint b
On Thu, 6 Apr 2023 00:49:33 GMT, Tingjun Yuan wrote:
> Fix a typo in the specification of
> `java.util.LinkedHashMap.removeEldestEntry(Map.Entry)`.
>
>> This is the entry that will be removed **it** this method returns `true`.
>
> will become:
>
>> This is the entry that will be removed **if*
On Tue, 13 Jun 2023 23:24:46 GMT, Stuart Marks wrote:
> I reviewed the changes in java.base. They look fine. I support the notion of
> keeping these changes minimal, with the narrow goal of keeping the resulting
> javadoc output the same. There are many opportunities for improving the
> actual
On Tue, 13 Jun 2023 10:11:28 GMT, Pavel Rappo wrote:
>> Please review this long-awaited change to documentation inheritance.
>>
>> This change improves "methods comment algorithm" and introduces directed
>> documentation inheritance. While "methods comment algorithm" -- automatic
>> search for
On Wed, 14 Jun 2023 10:07:05 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java line
>> 1534:
>>
>>> 1532:
>>> 1533: /**
>>> 1534: * {@inheritDoc ConcurrentMap}
>>
>> This clarifies the authors' intent, so is clear progress.
>>
>> Sem
On Thu, 13 Jul 2023 10:50:30 GMT, Pavel Rappo wrote:
> Please review this PR to use modern APIs and language features to simplify
> equals for BitSet.
>
> I couldn't see how to refactor hashCode using Arrays utility methods in a way
> that preserves its specification. So, aside from refactori
On Thu, 13 Jul 2023 10:50:30 GMT, Pavel Rappo wrote:
> Please review this PR to use modern APIs and language features to simplify
> equals for BitSet.
>
> I couldn't see how to refactor hashCode using Arrays utility methods in a way
> that preserves its specification. So, aside from refactori
On Wed, 19 Jul 2023 15:10:45 GMT, Pavel Rappo wrote:
> > BitSet#equals
>
> Did you mean BitSet#hashCode?
No. BitSet#equals uses the private fields and methods of its argument, which OO
purists would never allow.
If the other is a subclass with a different private representation, this code
wou
On Thu, 13 Jul 2023 10:50:30 GMT, Pavel Rappo wrote:
> Please review this PR to use modern APIs and language features to simplify
> equals for BitSet.
>
> I couldn't see how to refactor hashCode using Arrays utility methods in a way
> that preserves its specification. So, aside from refactori
On Thu, 13 Jul 2023 10:50:30 GMT, Pavel Rappo wrote:
> Please review this PR to use modern APIs and language features to simplify
> equals for BitSet.
>
> I couldn't see how to refactor hashCode using Arrays utility methods in a way
> that preserves its specification. So, aside from refactori
On Wed, 19 Jul 2023 22:08:04 GMT, Pavel Rappo wrote:
>> Please review this PR to use modern APIs and language features to simplify
>> equals for BitSet.
>>
>> I couldn't see how to refactor hashCode using Arrays utility methods in a
>> way that preserves its specification. So, aside from refa
The usual tiny improvements, with no guarantee that the intermittent test
failure is actually fixed.
-
Commit messages:
- JDK-8314515
Changes: https://git.openjdk.org/jdk/pull/15337/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15337&range=00
Issue: https://bugs.openjdk
hrowable
>> 40: {
>> 41: int threadCount = ThreadLocalRandom.current().nextInt(2, 8);
>
> @Martin-Buchholz I'm a bit weary about making the number of threads
> random—might make it tricky to get to reproduce if the test fails?
Suppose the test fails only with a sp
fair, i, threadCount, j));
>> 69: }
>> 70: for (Thread t : ts) t.join();
>
> @Martin-Buchholz Makes a lot of sense to make sure that all threads have
> terminated before exiting the test đź‘Ť
There's a lot of infrastructure in JSR16
On Thu, 7 Sep 2023 14:10:20 GMT, Soumadipta Roy wrote:
>> This test is running in tier1, and takes about 400 seconds to complete.
>> Thus, it drags the execution time of tier1 on large machines. The commit
>> includes changing the sequential run of test cases in
>> java/util/concurrent/tck/JSR
On Thu, 7 Sep 2023 14:10:20 GMT, Soumadipta Roy wrote:
>> This test is running in tier1, and takes about 400 seconds to complete.
>> Thus, it drags the execution time of tier1 on large machines. The commit
>> includes changing the sequential run of test cases in
>> java/util/concurrent/tck/JSR
On Fri, 11 Aug 2023 02:33:05 GMT, chenggwang wrote:
> Sorry, my description in Issue JDK-8314194(which I submitted) is ambiguous
> and makes you think of Phaser. My intention is that each generation of
> CyclicBarrier barrierCommand can change. Let me give you a scenario
> For example, the U.S.
On Thu, 7 Sep 2023 16:22:18 GMT, Soumadipta Roy wrote:
>> test/jdk/java/util/concurrent/tck/JSR166TestCase.java line 45:
>>
>>> 43: * @modules java.management
>>> 44: * @run junit/othervm/timeout=1000 JSR166TestCase
>>> 45: * @run junit/othervm/timeout=1000 -Djava.security.manager=allow
>>>
On Wed, 13 Sep 2023 12:27:39 GMT, Soumadipta Roy wrote:
>> This test is running in tier1, and takes about 400 seconds to complete.
>> Thus, it drags the execution time of tier1 on large machines. The commit
>> includes changing the sequential run of test cases in
>> java/util/concurrent/tck/JS
On Thu, 14 Sep 2023 08:08:18 GMT, Soumadipta Roy wrote:
>> This test is running in tier1, and takes about 400 seconds to complete.
>> Thus, it drags the execution time of tier1 on large machines. The commit
>> includes changing the sequential run of test cases in
>> java/util/concurrent/tck/JS
On Thu, 22 Feb 2024 09:49:31 GMT, Jaikiran Pai wrote:
> Can I get a review of this change which proposes to remove the `SystemTest`
> from among the `JSR166TestCase`?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8278527 the
> `SystemTest.nanoTime` test has been intermittently failing si
/util/concurrent/*` tests pass.
>
> Tagging @DougLea and @Martin-Buchholz to verify that this removal is timely.
Thanks for the tidying - I agree the time is right.
-
Marked as reviewed by martin (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/18176#pullrequestreview-1926388276
67 matches
Mail list logo
