Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

On Fri, Apr 11, 2025 at 10:50 AM Engebretson, John wrote: > I would like to see JDK standard "array builders" for primitive types and > reference types that use fixed sized (power-of-two) segments internally. > > > > I want to caution on the power-of-two idea – it leads to large objects > faster

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

d (power-of-two) segments internally. These can be internal classes for now. Then the faster ByteArrayOutputStream becomes just a wrapper around "ByteArrayBuilder" or whatever we call it. This is all just my opinion, I'm curious if others perceive the same gap that I do? -Archie On

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

On Fri, Apr 11, 2025 at 8:11 AM Engebretson, John wrote: > It seems like a good general-purpose list but I wouldn’t recommend it as a > direct replacement for either ArrayList or LinkedList; in the former case > the risk is slower random accesses, and in the latter the risk is to head > modificat

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

At the risk of repeating my previous comment , I agree with Chen. That is to say, there is a separate, more fundamental unsolved problem lurking underneath this discussion, and the two problem "layers" are perhaps better addr

Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v40]

On Thu, 3 Apr 2025 14:00:00 GMT, Per Minborg wrote: >> Implement JEP 502. >> >> The PR passes tier1-tier3 tests. > > Per Minborg has updated the pull request incrementally with one additional > commit since the last revision: > > Make the sqrt example different src/java.base/share/classes/j

Re: RFR: 8066583: DeflaterInput/OutputStream and InflaterInput/OutputStream should explain responsibility for freeing resources [v6]

On Tue, 1 Apr 2025 17:10:08 GMT, Alan Bateman wrote: >> My opinion is that: if it is possible for another implementation to share >> the backing in/deflator (such as via thread-local instances) that does not >> always need to be closed when an in/output stream is closed, then we should >> not

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

lternative. > Just a quick thought, I haven’t looked at any proposed code. > > Scott > > On Mar 28, 2025, at 6:09 PM, Archie Cobbs wrote: > >  > This is just a drive-by, opinion-saturated comment, so feel free to > ignore... > > I think the missing puzzle piece here is

Re: JDK-8352891 Performance improvements to ByteArrayOutputStream

This is just a drive-by, opinion-saturated comment, so feel free to ignore... I think the missing puzzle piece here is slightly different/more general than "OutputStream into memory". IMHO what's really missing from the standard toolbox provided by the JDK is the byte equivalent of StringBuilder+S

Integrated: 8351897: Extra closing curly brace typos in Javadoc

On Thu, 13 Mar 2025 01:21:54 GMT, Archie Cobbs wrote: > This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly > braces have been sneaking in. This pull request has now been integrated. Changeset: fe03e2ec Author:Archie Cobbs URL: https://git.openjdk.o

Re: RFR: 8351897: Extra closing curly brace typos in Javadoc [v3]

> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly > braces have been sneaking in. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Revert accidental file change. - Changes: - all:

Re: RFR: 8351897: Extra closing curly brace typos in Javadoc [v3]

On Mon, 24 Mar 2025 13:56:21 GMT, Chen Liang wrote: >> Archie Cobbs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert accidental file change. > > Looks good, these locations in the JDK 24 docs indeed

Re: RFR: 8351897: Extra closing curly brace typos in Javadoc [v2]

On Mon, 24 Mar 2025 05:23:58 GMT, Chen Liang wrote: > Shouldn't this closing `)` be wrapped in `{@code}` like `{@code )}` to match > with the code format in `{@code (getLocale()}`? Yes it should - thanks. The two rows above also have the same problem, i.e., I was just making this row consisten

Re: RFR: 8351897: Extra closing curly brace typos in Javadoc [v2]

> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly > braces have been sneaking in. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Apply font fixes per review suggestion. - Changes:

Re: RFR: 8351897: Extra closing curly brace typos in Javadoc

On Thu, 13 Mar 2025 01:46:53 GMT, Iris Clark wrote: > Where's the matching `(`? I'm guessing that the IDE thinks it's the one > immediately before the `getLocale()`, but I suspect that javadoc won't agree > with that. You are correct - the matching `(` is the one preceding `getLocale()`. I'm

RFR: 8351897: Extra closing curly brace typos in Javadoc

This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly braces have been sneaking in. - Commit messages: - Fix minor Javadoc typos. Changes: https://git.openjdk.org/jdk/pull/24022/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24022&range=00 Issue: h

Integrated: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs)

On Sat, 2 Nov 2024 15:40:30 GMT, Archie Cobbs wrote: > Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. This pull request has now been integrated. Changeset: 661bd5bf Author:Archie Cobbs URL: https://git.openjdk.org/jdk/

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v12]

On Sat, 15 Feb 2025 21:27:56 GMT, Archie Cobbs wrote: >> Please review this patch which removes unnecessary `@SuppressWarnings` >> annotations. > > Archie Cobbs has updated the pull request with a new target base due to a > merge or a rebase. The pull request no

RFR: 8261669: Add lint warning for widening primitive conversions that lose information

This PR is a prototype to stimulate discussion of [JDK-8261669](https://bugs.openjdk.org/browse/JDK-8261669), which seeks to add more warnings when an implicit cast of a primitive value might lose information. This can possibly happen when converting an `int` to `float`, or when converting a `l

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v12]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Merge branch 'master' into SuppressWarningsCleanup-

Re: RFR: 8315585: Optimization for decimal to string [v4]

On Tue, Feb 4, 2025 at 5:26 PM Shaojin Wen wrote: > I think you are talking about the problem of PR #23420, which is caused by > the use of thread-unsafe StringBuilder in multi-threaded scenarios. This > problem is very obscure and I didn't consider it before. I have started to > solve this probl

Re: RFR: 8315585: Optimization for decimal to string [v4]

On Tue, Feb 4, 2025 at 2:40 PM Joe Darcy wrote: > Can we please have a pause on the sequence of "make XYZ toString faster" > PRs until there is some wider discussion of goals, etc.? Thanks. > I agree with this sentiment... It was surprising to see how easily a VM crash can sneak in. There is al

Re: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater [v3]

On Fri, 24 Jan 2025 20:57:15 GMT, Eirik Bjørsnøs wrote: > A tangential concern when allowing a custom deflater / inflater is to > document the resposibility for resource management. I've added a Javadoc blurb to that effect in 3807de16b70. Something similar (once the verbiage is agreed upon) s

Re: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater [v4]

accepts a custom > `Deflater`, and also adds a basic unit test for it and all of the other > `GZIPOutputStream` constructors, based on the existing test > `BasicGZIPInputStreamTest.java` which does the same thing for > `GZIPInputStream`. Archie Cobbs has updated the pull req

Re: Factory methods for SequencedSet and SequencedMap

On Fri, Jan 17, 2025 at 7:50 PM David Alayachew wrote: > I guess my next question is, there is no bridge method, which is why this > fails. Why not add a bridge method? What is stopping Java from doing this? > In Java class files it's possible to have two methods that differ only in their return

Re: Factory methods for SequencedSet and SequencedMap

On Fri, Jan 17, 2025 at 9:22 AM Ethan McCue wrote: > Just so there are some strawman arguments against: > To pile on... If I go to a restaurant and order a hamburger and they bring me a cheeseburger and also charge me extra for it, I'm going to complain! A Set and a SequencedSet are two differ

Re: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater

On Fri, 19 Jul 2024 15:16:01 GMT, Lance Andersen wrote: >>> I understand the request here, but is there a current use case for needing >>> a custom Deflater? >> >> I think the primary use case is when you want to set a non-default >> compression level, e.g., "best" or "fast". This is a pretty

Re: RFR: 8347334: JimageDiffGenerator code clean-ups [v2]

On Mon, 13 Jan 2025 10:47:41 GMT, Severin Gehwolf wrote: >> (Getting into marginal returns on comments here, so my apologies for >> nitpicking) >> >> The loop could be simplified even further... >> >> while (true) { >> int bytesRead1 = is1.readNBytes(buf1, 0, buf1.length); >> int bytes

Re: RFR: 8347334: JimageDiffGenerator code clean-ups [v2]

On Thu, 9 Jan 2025 18:25:16 GMT, Severin Gehwolf wrote: >> During code review of >> [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments >> were made after the PR integrated. This follow-up patch cleans this up and >> adds a unit test for the `JimageDiffGenerator` class. >

Re: RFR: 8347334: JimageDiffGenerator code clean-ups

On Thu, 9 Jan 2025 17:32:39 GMT, Severin Gehwolf wrote: > During code review of > [JDK-8346239](https://bugs.openjdk.org/browse/JDK-8346239) a few comments > were made after the PR integrated. This follow-up patch cleans this up and > adds a unit test for the `JimageDiffGenerator` class. > >

Re: RFR: 8346239: Improve memory efficiency of JimageDiffGenerator

On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote: > Please review this fairly simple change to improve how the > `JimageDiffGenerator` works. The original implementation is pretty naive and > read all bytes into memory and then compared them. This improved version only > reads bytes on

Re: RFR: 8346239: Improve memory efficiency of JimageDiffGenerator

On Thu, 19 Dec 2024 18:14:39 GMT, Severin Gehwolf wrote: > Please review this fairly simple change to improve how the > `JimageDiffGenerator` works. The original implementation is pretty naive and > read all bytes into memory and then compared them. This improved version only > reads bytes on

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v8]

On Mon, 9 Dec 2024 22:18:30 GMT, Joe Darcy wrote: >> Archie Cobbs has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 15 commits: >> >> - Remove more unnecessary suppressions. >> - Merge branch 'm

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v10]

On Thu, 2 Jan 2025 19:56:16 GMT, Archie Cobbs wrote: >> Please review this patch which removes unnecessary `@SuppressWarnings` >> annotations. > > Archie Cobbs has updated the pull request incrementally with one additional > commit since the last revision: > >

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v11]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Update @LastModified tags. - Changes: - all: https://git.openjdk.org/jd

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v10]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Revert changes under src/java.desktop (to be moved into a separate PR). - C

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v9]

On Thu, 2 Jan 2025 19:16:41 GMT, Naoto Sato wrote: > Looks like some files in java.desktop package are also modified. Just > wondering they may not be seen by client folks as the title mentions > core-libs. Yeah my attempt to split this up was not perfect. I did have a separate, earlier PR (#

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v9]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Bump copyright year to 2025. - Merge branch 'm

Re: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater [v3]

accepts a custom > `Deflater`, and also adds a basic unit test for it and all of the other > `GZIPOutputStream` constructors, based on the existing test > `BasicGZIPInputStreamTest.java` which does the same thing for > `GZIPInputStream`. Archie Cobbs has updated the pull req

Re: RFR: 8345668: ZoneOffset.ofTotalSeconds performance regression [v3]

On Thu, 26 Dec 2024 17:25:55 GMT, Andrey Turbanov wrote: > For sure we should use result of `putIfAbsent` Drive-by comment... >From what i can infer, the performance regression being addressed here is >caused in part by the fact that (for example) >`ConcurrentHashMap.computeIfAbsent()` provid

Re: Proposal: jar option to disable compression for selected file extensions

On Mon, Dec 16, 2024 at 5:39 AM Eirik Bjørsnøs wrote: > I propose that we add a new option, tentatively named "--no-compress-ext", > which would take a colon-separated list of file extensions to disable ZIP > compression for: > > jar --create --file archive.jar --no-compress-ext=.jpg:.png:.gz -C

Re: Copyright update tedium

Hi Thomas, On Tue, Dec 10, 2024 at 4:45 AM Thomas Stüfe wrote: > Note that we have a script for that; see > make/scripts/update_copyright_year.sh . I use it a lot. Sonia recently > enhanced it. It even has an option to update copyrights for foreign > companies. > Awesome - thanks for the pointe

Re: Copyright update tedium

further discussion to have Skara actually get into > the business of whether the copyright header should be updated and what the > copyright year(s) should be. I personally think Skara shouldn't do that, > but it is a topic that might be worth discussing for a future Enhancement. > &g

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v8]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Remove more unnecessary suppressions. - Merge branch 'm

Re: Copyright update tedium

Bleh, ignore my comment. I didn't realize the PR#1702 you referenced is already proposing doing this! -Archie On Mon, Dec 9, 2024 at 10:45 AM Archie Cobbs wrote: > Thanks for working on this... something of a thankless task :) > > I'm sure you've considered this but I

Re: Copyright update tedium

re starting to slowly get there, see > https://github.com/openjdk/skara/pull/1702 for a first step. > > /Magnus > On 2024-12-03 16:45, Archie Cobbs wrote: > > Dumb question... > > It seems like the thing with updating copyright years in source files > could be better automated

Copyright update tedium

Dumb question... It seems like the thing with updating copyright years in source files could be better automated. At least, couldn't there be a test that fails if you forget? FWIW my little updater script says that these files still need to be updated to 2024: .github/actions/config/action.yml .

Re: Deprecate Double.MIN_VALUE?

Having been bitten by this bug myself, I would vote yes on this one. For symmetry's sake, I would think there should be four new constants - for {MIN,MAX}_{POSITIVE,NEGATIVE}_VALUE - and that both of {MIN,MAX}_VALUE should be deprecated. -Archie On Mon, Dec 2, 2024 at 5:18 PM Éamonn McManus wro

Re: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater

On Wed, 17 Jul 2024 21:07:23 GMT, Archie Cobbs wrote: > The class `GZIPOutputStream` extends `DeflaterOutputStream`, which is logical > because the GZIP encoding is based on ZLIB "deflate" encoding. > > However, while `DeflaterOutputStream` provides constructors that take

Re: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater [v2]

accepts a custom > `Deflater`, and also adds a basic unit test for it and all of the other > `GZIPOutputStream` constructors, based on the existing test > `BasicGZIPInputStreamTest.java` which does the same thing for > `GZIPInputStream`. Archie Cobbs has updated the pull req

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v7]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Remove more unnecessary @SuppressWarnings annotations. -

Re: RFR: 8343125: Correct the documentation for TreeMap's getFloorEntry and getCeilingEntry [v3]

On Thu, 14 Nov 2024 03:23:29 GMT, Naman Nigam wrote: >> As the documentation of getCeilingEntry currently reads, the inference is >> misleading as follows: >> >> if no such entry exists, returns the entry for the least key greater than >> the specified key; >> if no such entry exists (i.e., th

Re: RFR: 8343490: Update copyright year for JDK-8341692

On Wed, Nov 13, 2024 at 10:39 PM Phil Race wrote: > On Tue, 5 Nov 2024 01:41:00 GMT, SendaoYan wrote: > > The copyright year of some files which has been changed by > [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692) wasn't update > correctly. This PR update the copyright year of [JDK-8

Re: RFR: 8343125: Correct the documentation for TreeMap's getFloorEntry and getCeilingEntry [v2]

On Thu, 14 Nov 2024 03:19:01 GMT, Naman Nigam wrote: >> src/java.base/share/classes/java/util/TreeMap.java line 424: >> >>> 422: /** >>> 423: * Returns the entry for the least key greater than or equal to >>> the specified key; >>> 424: * if no such entry exists (i.e. the specifie

Re: RFR: 8343125: Correct the documentation for TreeMap's getFloorEntry and getCeilingEntry [v2]

On Thu, 14 Nov 2024 02:29:27 GMT, Naman Nigam wrote: >> As the documentation of getCeilingEntry currently reads, the inference is >> misleading as follows: >> >> if no such entry exists, returns the entry for the least key greater than >> the specified key; >> if no such entry exists (i.e., th

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v6]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Remove more unnecessary warning suppressions. - Changes: - all:

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v5]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'master' into SuppressWarningsCleanup-

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v4]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Put back @SuppressWarnings annotations to be fixed by JDK-8343286. - C

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v3]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs 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 co

Re: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs) [v2]

> Please review this patch which removes unnecessary `@SuppressWarnings` > annotations. Archie Cobbs 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 co

RFR: 8343478: Remove unnecessary @SuppressWarnings annotations (core-libs)

Please review this patch which removes unnecessary `@SuppressWarnings` annotations. - Commit messages: - Remove unnecessary @SuppressWarnings annotations. Changes: https://git.openjdk.org/jdk/pull/21852/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=00 Issue

Re: RFR: 8233451: (fs) Files.newInputStream() cannot be used with character special files

On Tue, 15 Oct 2024 15:13:06 GMT, Alan Bateman wrote: > FileChannel implements SeekableByteChannel. You'll see exactly the same thing > if you use FileChannel.open to open a special file. Ah... thanks. Also (for example) `FileInputStream.getChannel()` returns a `FileChannel`, so we're stuck wi

Re: RFR: 8233451: (fs) Files.newInputStream() cannot be used with character special files

On Mon, 14 Oct 2024 23:30:06 GMT, Brian Burkhalter wrote: > Add `isOther` and `available` methods to `FileChannelImpl` and the interfaces > to native code and use these in `ChannelInputStream` to work around cases > where a wrapped `FileChannelImpl` is not really seekable. Albeit with my very

Re: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]

On Fri, 4 Oct 2024 17:03:38 GMT, fabioromano1 wrote: >> src/java.base/share/classes/java/math/BigDecimal.java line 5238: >> >>> 5236: BigInteger pow = FIVE_TO_2_TO[FIVE_TO_2_TO_LEN - 1]; >>> 5237: for (int i = FIVE_TO_2_TO_LEN; i <= n; i++) >>> 5238: FIVE_

Re: RFR: 8341470: BigDecimal.stripTrailingZeros() optimization [v12]

On Thu, 3 Oct 2024 17:11:09 GMT, fabioromano1 wrote: >> An optimized algorithm for `BigDecimal.stripTrailingZeros()` that uses >> repeated squares trick. > > fabioromano1 has updated the pull request incrementally with one additional > commit since the last revision: > > Code simplification

Re: [External] : Re: Stream Gatherers (JEP 473) feedback

belongs to a new > primary group. But since you're going to sort the group on the secondary, > that'll need to be comparable. > > Cheers, > √ > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > > -

Re: Range API

On Sun, Sep 22, 2024 at 2:03 PM Olexandr Rotan wrote: > Hello everyone! I am writing here today to invite everyone to participate > in the discussion regarding the Range APi proposal I have made into JDK. > A few comments... Guava has addressed this same problem; their approach worth reviewing:

Re: Stream Gatherers (JEP 473) feedback

Hi Viktor, I recently encountered a real-world use case for Stream Gatherers and thought I'd mention it (apologies if you've seen these ideas already). These might even be worth considering including as standard offerings. Motivating example: Suppose you have a large list of people sorted by Last

Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

On Fri, Sep 20, 2024 at 10:16 AM Viktor Klang wrote: > Before we do anything at all, does there exist a reproducer which would > illustrate that the current behavior causes problems? > I believe this is the most recent one: https://mail.openjdk.org/pipermail/core-libs-dev/2024-September/129031.h

Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Hi Kim, Here is a quick summary of my thoughts... Before diving into coding solutions, we need to make sure we're all on the same page. First: (Viktor) Do we all agree that "Interpretation B" accurately describes how things are actually working today? If "No" then we need to stop and understand

Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

to T10.] >7. > >T12 acquires the lock and proceeds to enqueue in ArrayBlockingQueue without >being blocked by while(count==length). >8. > >T12 releases the lock, and the next node in AQS is unparked. > >[Now, AQS holds T1, while ConditionNode holds

Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Hi Kim, On Sat, Sep 7, 2024 at 10:36 AM 김민주 wrote: > Here's a clearer outline of the scenario: > >- Threads T1 to T10 are waiting on Condition::await() because the >queue is full. >- T11 calls take() and holds the lock via lock.lockInterruptibly(). >- T12 calls queue.put() and en

Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Apologies in advance if I'm misunderstanding anything... On Thu, Sep 5, 2024 at 2:05 PM Viktor Klang wrote: > Thread state polling aside, for as long as Condition::await() is allowed > to spuriously wake, FIFO just cannot be "guaranteed". What about this statement in the Javadoc for Reentrant

Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Hi Kim, I think there may be an issue with your test. Specifically, this code is suspect: // Wait for the producer thread to enter BLOCKED state // This ensures that the thread is waiting on the full queue while (thread.getState() == State.RUNNABLE || thread.getState() == State.NEW);

Withdrawn: 8322256: Define and document GZIPInputStream concatenated stream semantics

On Tue, 19 Mar 2024 21:48:14 GMT, Archie Cobbs wrote: > `GZIPInputStream` supports reading data from multiple concatenated GZIP data > streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In > order to do this, after a GZIP trailer frame is read, it attempts

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v10]

On Wed, 28 Aug 2024 21:56:50 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data >> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In >> order to do this, after a GZIP trailer frame is read, it

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v10]

havior is > enabled by setting both to true; otherwise, they do what they sound like. In > particular, when `allowTrailingGarbage` is false, then the underlying input > must contain exactly one (if `allowConcatenation` is false) or exactly N (if > `allowConcatenation` is true) concatenated

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v9]

On Wed, 28 Aug 2024 17:50:36 GMT, Lance Andersen wrote: >> Archie Cobbs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Revert all functional changes, leaving only tests & Javadoc. > > src/jav

Re: [External] : Re: New candidate JEP: 484: Class-File API

e history. > > > > Feel free to report cases where the support is insufficient. > > > > Thank you, > > Adam > > > > *From: *Archie Cobbs > *Date: *Tuesday, 27 August 2024 at 18:49 > *To: *core-libs-dev@openjdk.org > *Cc: *Adam Sotona , jdk-...@o

Re: Namespace Prefix Issue in XML to XSL Transformation

Hi Hempushpa, What you describe appears to be this issue: JDK-8168664 . -Archie On Tue, Aug 27, 2024 at 12:29 AM Hempushpa Sahu wrote: > Problem Description : > > XSLT transformation creating unique namespace prefixes. > > > > Analysis & Observation

Re: New candidate JEP: 484: Class-File API

Question... would it be appropriate for this JEP to mention that support for older-than-current classfile versions is an explicit non-goal? Otherwise I think there could be many repeats of this discussion from the other day

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8]

On Wed, 31 Jul 2024 15:51:48 GMT, Lance Andersen wrote: >> Another (more conservative) possibility is to preserve both 1 ("Trailing >> garbage is ignored") and 3 ("Concatenated streams are automatically >> decoded") in the default configuration. >> >> Then basically all we would be changing is

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8]

On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data >> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In >> order to do this, after a GZIP trailer frame is read, it

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v9]

havior is > enabled by setting both to true; otherwise, they do what they sound like. In > particular, when `allowTrailingGarbage` is false, then the underlying input > must contain exactly one (if `allowConcatenation` is false) or exactly N (if > `allowConcatenation` is true) concatenated

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8]

On Fri, 2 Aug 2024 13:12:00 GMT, Jaikiran Pai wrote: >> Archie Cobbs has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Refactor to eliminate "lenient" mode (still failng test: GZIPInZip.java). >>

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8]

On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data >> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In >> order to do this, after a GZIP trailer frame is read, it

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8]

On Sat, 27 Jul 2024 15:00:51 GMT, Archie Cobbs wrote: >> `GZIPInputStream` supports reading data from multiple concatenated GZIP data >> streams since [JDK-4691425](https://bugs.openjdk.org/browse/JDK-4691425). In >> order to do this, after a GZIP trailer frame is read, it

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8]

On Tue, 30 Jul 2024 17:35:33 GMT, Lance Andersen wrote: > Based on the above, I am reluctant to change the current behavior given it > appears to have been modeled after gzip/gunzip as well as WinZip. That's a reasonable conclusion... and I have no problem with preserving the existing behavior

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8]

On Mon, 29 Jul 2024 14:27:28 GMT, Lance Andersen wrote: > ... we really need more datapoint to better understand the risks/benefits in > order to make an informed decision. Agreed. Here's some what I've come up with after a little bit of research: First, we shouldn't confuse GZIP with ZIP fil

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8]

On Mon, 29 Jul 2024 13:06:24 GMT, Lance Andersen wrote: > So where does that leave us: > >Keep the code as is and document the current behavior >Continue to add additional test coverage for the current API >We probably do not need a new constructor given it probably adds no new > ad

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v8]

havior is > enabled by setting both to true; otherwise, they do what they sound like. In > particular, when `allowTrailingGarbage` is false, then the underlying input > must contain exactly one (if `allowConcatenation` is false) or exactly N (if > `allowConcatenation` is true) concatenated

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v7]

On Fri, 26 Jul 2024 16:46:28 GMT, Archie Cobbs wrote: > With this new proposed change we will throw an IOException (unlike > previously). I think that's fine and in fact the correct thing to do. I've run into a problem. With this change, `GZIPInZip.java` fails; the test is ann

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v7]

On Fri, 26 Jul 2024 16:12:11 GMT, Jaikiran Pai wrote: >> Archie Cobbs has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into JDK-8322256 >> - W

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v7]

On Fri, 26 Jul 2024 13:36:43 GMT, Lance Andersen wrote: >> Archie Cobbs has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 16 commits: >> >> - Merge branch 'master' into JDK-8322256 >> - W

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v7]

havior is > enabled by setting both to true; otherwise, they do what they sound like. In > particular, when `allowTrailingGarbage` is false, then the underlying input > must contain exactly one (if `allowConcatenation` is false) or exactly N (if > `allowConcatenation` is true) concatenated

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v6]

havior is > enabled by setting both to true; otherwise, they do what they sound like. In > particular, when `allowTrailingGarbage` is false, then the underlying input > must contain exactly one (if `allowConcatenation` is false) or exactly N (if > `allowConcatenation` is true) concatenated

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5]

On Mon, 22 Jul 2024 18:08:52 GMT, Eirik Bjørsnøs wrote: >>> The term "extra" here feels somewhat open to interpretation. Specifically, >>> "extra" sounds like something that is out of the ordinary, but not uncommon >>> or wrong. It could be used when describing an optional feature in a format

Re: RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics [v5]

On Fri, 19 Jul 2024 09:56:46 GMT, Eirik Bjørsnøs wrote: > The term "extra" here feels somewhat open to interpretation. Specifically, > "extra" sounds like something that is out of the ordinary, but not uncommon > or wrong. It could be used when describing an optional feature in a format > spec

Re: RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater

On Fri, 19 Jul 2024 10:41:05 GMT, Lance Andersen wrote: > I understand the request here, but is there a current use case for needing a > custom Deflater? I think the primary use case is when you want to set a non-default compression level, e.g., "best" or "fast". This is a pretty normal thing

Re: RFR: 6356745: (coll) Add PriorityQueue(Collection, Comparator) [v6]

On Thu, 28 Dec 2023 00:09:09 GMT, Valeh Hajiyev wrote: >> This commit addresses the current limitation in the `PriorityQueue` >> implementation, which lacks a constructor to efficiently create a priority >> queue with a custom comparator and an existing collection. In order to >> create such a

RFR: 4452735: Add GZIPOutputStream constructor to specify Deflater

The class `GZIPOutputStream` extends `DeflaterOutputStream`, which is logical because the GZIP encoding is based on ZLIB "deflate" encoding. However, while `DeflaterOutputStream` provides constructors that take a custom `Deflator` argument supplied by the caller, `GZIPOutputStream` has no such

  1   2   >