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

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: Read-only view of ByteArrayInputStream content

On Tue, Jul 9, 2024 at 10:51 AM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > JDK-22 has modified ByteArrayInputStream.transferTo(OutputStream) > implementation for performing a defensive copy of the byte array when the > destination is not trusted (JDK-8321053). However, I was

Re: Read-only view of ByteArrayInputStream content

Hi Martin, On Tue, Jul 9, 2024 at 12:31 PM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > I was using a custom OutputStream implementation for getting the value of > that field, avoiding any form of copy. > Gotcha - so in other words, you want a way to effectively "unwrap" the o

Re: Read-only view of ByteArrayInputStream content

On Tue, Jul 9, 2024 at 1:42 PM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > > Basically, the BLOB API seems clearly designed to allow the implementation > to stream the data on demand if it wants to (which is good), but as a side > effect it doesn't provide a way for the caller

Re: Read-only view of ByteArrayInputStream content

On Wed, Jul 10, 2024 at 12:05 PM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Le 2024-07-10 à 18 h 00, Archie Cobbs a écrit : > > So would you accept a solution to this problem in the java.sql package > instead? For example by addi

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

On Mon, 15 Jul 2024 13:12:41 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 153: >> >>> 151: */ >>> 152: public GZIPInputStream(InputStream in, int size, >>> 153: boolean allowConcatenation, boolean ignoreExtraBytes) >>> thro

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

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

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: 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: 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 [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 [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 [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]

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 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 [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 [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]

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 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 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 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 [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 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 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: 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: 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: [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: 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: 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

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: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative

On Tue, Apr 11, 2023 at 4:52 PM Glavo wrote: > i'm not sure that the methods lowercase() and uppercase() are a good >> addition. >> Their names are too close to toLowerCase/toUpperCase thus too easy to >> misuse ones for the others. >> > > I'm fine with users having to write toLowerCase(Locale.R

Re: Draft: Deprecate toLowerCase()/toUpperCase() and provide locale insensitive alternative

On Thu, Apr 13, 2023 at 9:14 AM Roger Riggs wrote: > And yes, it is a problem to cause many warnings; it creates an immediate > and pressing need for projects that have tight source requirements and > don't allow warnings, for example, the JDK itself. > Hmm.. I'd agree with this statement if mos

Re: RFR: 8305748: Clarify reentrant behavior of close() in FileInputStream, FileOutputStream, and RandomAccessFile [v3]

On Fri, 7 Apr 2023 18:24:42 GMT, Archie Cobbs wrote: >> IO stream classes like `FileOutputStream` can have assocated NIO channels. >> >> When `close()` is invoked on one of these classes, it in turn invokes >> `close()` on the associated channel (if any). But when the

Integrated: 8305748: Clarify reentrant behavior of close() in FileInputStream, FileOutputStream, and RandomAccessFile

On Thu, 6 Apr 2023 22:36:33 GMT, Archie Cobbs wrote: > IO stream classes like `FileOutputStream` can have assocated NIO channels. > > When `close()` is invoked on one of these classes, it in turn invokes > `close()` on the associated channel (if any). But when the associated

Re: javac to emit static flag for local and anonymous classes in static contexts

Hi Liang, On Sun, May 21, 2023 at 11:29 PM - wrote: > Thus, I suggest emitting static flags for the InnerClasses attribute > of anonymous/local classes in static/pre-initialization contexts, > Related to your question on PR#13656 ... local/anonymous classes in a pre-initialization context (whic

Re: RFR: 8304478: Initial nroff manpage generation for JDK 22

On Wed, 14 Jun 2023 04:53:58 GMT, David Holmes wrote: > The following changes, to javac.1, were never applied to the closed sources > and are "lost" by this update. These changes will need to be re-applied > directly in JDK 21 and JDK 22 Just curious, since you have access to the secret closed

Re: RFR: 8304478: Initial nroff manpage generation for JDK 22

On Wed, 14 Jun 2023 21:28:01 GMT, David Holmes wrote: > > Just curious, since you have access to the secret closed sources, can you > > not backport these changes yourself? Instead of just deleting them and > > expecting someone else to rescue them from oblivion? > > @archiecobbs we (Oracle) w

RFR: 8322027: One XMLStreamException constructor fails to initialize cause

One of the three `XMLStreamException` constructors that takes a `Throwable` fails to pass it to the superclass constructor. This simple patch fixes that omission. - Commit messages: - Propagate cause to superclass constructor in XMLStreamException constructor. Changes: https://git

Re: RFR: 8322027: One XMLStreamException constructor fails to initialize cause

On Wed, 13 Dec 2023 20:06:03 GMT, Archie Cobbs wrote: > One of the three `XMLStreamException` constructors that takes a `Throwable` > fails to pass it to the superclass constructor. > > This simple patch fixes that omission. > > It's worth considering if there is any

Re: [External] : Re: Introduce constructor for PriorityQueue with existing collection and custom comparator

On Thu, Dec 14, 2023 at 4:56 AM Viktor Klang wrote: > I presume that the precondition to have the original collection be > pre-ordered according to the supplied Comparator can be verified by > checking before adding each element in the collection to the PQ that it > compareTo equal-or-greater to

Re: RFR: 8322027: One XMLStreamException constructor fails to initialize cause

On Wed, 13 Dec 2023 20:06:03 GMT, Archie Cobbs wrote: > One of the three `XMLStreamException` constructors that takes a `Throwable` > fails to pass it to the superclass constructor. > > This simple patch fixes that omission. > > It's worth considering if there is any

Re: Bug in GZIPInputStream.read() causing data loss

Hi Louis, On first glance this looks easy to fix. I've filed a draft PR here (pending tests) https://github.com/openjdk/jdk/pull/17113 -Archie On Thu, Dec 14, 2023 at 1:10 PM Louis Bergelson wrote: > Hello. This is my first time posting here so I apologize if this is the > wrong forum. I wan

Re: [External] : Re: Introduce constructor for PriorityQueue with existing collection and custom comparator

existing ticket. It's > now ready for review. > > I would appreciate if you could have a look again. > > Cheers, > Valeh > > On Thu, Dec 14, 2023 at 4:22 PM Archie Cobbs > wrote: > >> On Thu, Dec 14, 2023 at 4:56 AM Viktor Klang >> wrote: >&

RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream

`GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero. The fix is to igno

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v2]

ro. > > The fix is to ignore what's `available()` and just proceed and see what > happens. If fewer bytes are available than required, the attempt to extend to > another stream is canceled just as it was before, e.g., when the next stream > header couldn't be read. Arch

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v2]

On Thu, 14 Dec 2023 21:14:33 GMT, Eirik Bjorsnos wrote: >> Archie Cobbs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Address review comments. > > test/jdk/java/util/zip/GZIP/GZIPInputStreamAvailable.java

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v3]

ro. > > The fix is to ignore what's `available()` and just proceed and see what > happens. If fewer bytes are available than required, the attempt to extend to > another stream is canceled just as it was before, e.g., when the next stream > header couldn't be read. Arch

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v2]

On Fri, 15 Dec 2023 14:09:12 GMT, Eirik Bjorsnos wrote: >> Archie Cobbs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Address review comments. > > test/jdk/java/util/zip/GZIP/GZIPInputStreamAv

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v3]

On Fri, 15 Dec 2023 20:38:19 GMT, Eirik Bjorsnos wrote: > The test is shaping up nicely. Since it's a new test it should use JUnit 5. > > Also included a couple suggestions, I'll stop now, promise! :) No prob - they're all reasonable suggestions :) > test/jdk/java/util/zip/GZIP/GZIPInputStream

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v4]

ro. > > The fix is to ignore what's `available()` and just proceed and see what > happens. If fewer bytes are available than required, the attempt to extend to > another stream is canceled just as it was before, e.g., when the next stream > header couldn't be read. Arch

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v4]

On Sat, 16 Dec 2023 05:53:34 GMT, Bernd wrote: > I wonder: if the stream does no longer depend on this `available()` condition > to be true, does that mean it’s no longer (indirectly) verified? I'm not sure I understand ... what do you mean by "verified"? If what you're saying is "Previously w

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v4]

On Sun, 17 Dec 2023 13:47:00 GMT, Eirik Bjorsnos wrote: > The current behavior of allowing/ignoring trailing malformed data seems to > have a complicated history... Thanks for researching all of that. I agree this should be cleaned up and have created [JDK-8322256](https://bugs.openjdk.org/bro

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v4]

On Tue, 19 Dec 2023 08:11:42 GMT, Bernd wrote: > > If what you're saying is "Previously we were implicitly verifying that the > > data reported by `available()` was actually there, and now we're no longer > > verifying that" then that's not correct. > > I mean it verified the non-zero behavior

Integrated: 8322027: One XMLStreamException constructor fails to initialize cause

On Wed, 13 Dec 2023 20:06:03 GMT, Archie Cobbs wrote: > One of the three `XMLStreamException` constructors that takes a `Throwable` > fails to pass it to the superclass constructor. > > This simple patch fixes that omission. > > It's worth considering if there is any

Re: RFR: 8322027: One XMLStreamException constructor fails to initialize cause

On Tue, 2 Jan 2024 06:47:52 GMT, Jaikiran Pai wrote: >> One of the three `XMLStreamException` constructors that takes a `Throwable` >> fails to pass it to the superclass constructor. >> >> This simple patch fixes that omission. >> >> It's worth considering if there is any code out there that i

Is MessageFormat.toPattern() supposed to be reversible?

Clarification question regarding MessageFormat.toPattern() before I file a bug... Is it supposed to be the case that given a MessageFormat object fmt, new MessageFormat(fmt.toPattern()) is equivalent to the original fmt object? Thanks, -Archie -- Archie L. Cobbs

RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern

Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original. The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit no

Re: Is MessageFormat.toPattern() supposed to be reversible?

Nevermind, I believe now it is and have filed JDK-8323699. Thanks. On Sat, Jan 13, 2024 at 12:45 PM Archie Cobbs wrote: > Clarification question regarding MessageFormat.toPattern() before I file a > bug... > > Is it supposed to be the case that given a MessageFormat obj

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);

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, 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

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: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v5]

ro. > > The fix is to ignore what's `available()` and just proceed and see what > happens. If fewer bytes are available than required, the attempt to extend to > another stream is canceled just as it was before, e.g., when the next stream > header couldn't be read. Arch

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern

On Tue, 16 Jan 2024 22:05:03 GMT, Justin Lu wrote: >> Please consider this fix to ensure that going from `MessageFormat` to >> pattern string via `toPattern()` and then back via `new MessageFormat()` >> results in a format that is equivalent to the original. >> >> The quoting and escaping rule

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v2]

see a trailing `}` only with the second option. > > However, if you then invoke `toPattern()`, the result is > `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the > "extra" closing brace is no longer quoted, it matches the opening brace at >

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern

On Thu, 18 Jan 2024 20:08:27 GMT, Justin Lu wrote: >> Hi @justin-curtis-lu, >> >> Thanks a lot for taking a look, I am glad for any other set of eyes on this >> tricky stuff! >> >>> As it stands, it would be inconsistent to have the closing bracket quoted >>> and the opening bracket not quote

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v2]

On Thu, 18 Jan 2024 23:02:57 GMT, Justin Lu wrote: > Sorry if I'm going over stuff you already know... No apology needed, this stuff is obscure detail madness! > So with this change, although calling `toPattern()` on `new > MessageFormat("{0,choice,0.0#foo {1} {2} {3} }")` would return the Str

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v3]

On Fri, 19 Jan 2024 23:30:43 GMT, Archie Cobbs wrote: >> Please consider this fix to ensure that going from `MessageFormat` to >> pattern string via `toPattern()` and then back via `new MessageFormat()` >> results in a format that is equivalent to the original. >> >

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v3]

see a trailing `}` only with the second option. > > However, if you then invoke `toPattern()`, the result is > `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the > "extra" closing brace is no longer quoted, it matches the opening brace at >

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v3]

On Tue, 23 Jan 2024 22:13:09 GMT, Justin Lu wrote: >> Archie Cobbs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add @implNote to Javadoc for toPattern(). > > src/java.base/share/classes/java/text/Mess

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v3]

On Tue, 23 Jan 2024 23:00:29 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/text/MessageFormat.java line 556: >> >>> 554: * does not necessarily equal the previously applied pattern. >>> 555: * >>> 556: * @implNote The string returned by this method can be used to >>>

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v3]

On Tue, 23 Jan 2024 22:15:40 GMT, Justin Lu wrote: >> Archie Cobbs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add @implNote to Javadoc for toPattern(). > > test/jdk/java/text/Format/MessageFormat/M

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v4]

see a trailing `}` only with the second option. > > However, if you then invoke `toPattern()`, the result is > `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the > "extra" closing brace is no longer quoted, it matches the opening brace at >

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v5]

see a trailing `}` only with the second option. > > However, if you then invoke `toPattern()`, the result is > `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the > "extra" closing brace is no longer quoted, it matches the opening brace at >

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v5]

On Thu, 25 Jan 2024 22:49:39 GMT, Justin Lu wrote: > In terms of the CSR,... Hi Justin, thanks again very much for the comments and careful review. The CSR should be updated accordingly. - PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1911134650

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v5]

On Fri, 26 Jan 2024 18:58:49 GMT, Justin Lu wrote: > I wasn't sure if you were waiting to make additional changes or something > else, but you can go ahead and re-finalize the CSR (when you are ready), now > that it has been reviewed. Thanks - I wasn't sure about that. I've updated it now. --

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v5]

On Fri, 26 Jan 2024 20:30:42 GMT, Roger Riggs wrote: > The "can be used to create" seems conditional. It is conditional - in the sense that you don't _have_ to use it to create a new instance of `MessageFormat`. You can also use it for something else, in other words. But I also understand ho

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v5]

On Fri, 26 Jan 2024 21:28:47 GMT, Justin Lu wrote: >>> The "can be used to create" seems conditional. >> >> It is conditional - in the sense that you don't _have_ to use it to create a >> new instance of `MessageFormat`. You can also use it for something else, in >> other words. >> >> But I

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v6]

see a trailing `}` only with the second option. > > However, if you then invoke `toPattern()`, the result is > `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the > "extra" closing brace is no longer quoted, it matches the opening brace at >

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v7]

see a trailing `}` only with the second option. > > However, if you then invoke `toPattern()`, the result is > `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the > "extra" closing brace is no longer quoted, it matches the opening brace at >

Re: RFR: JDK-8318761: MessageFormat pattern support for CompactNumberFormat, ListFormat, and DateTimeFormatter

On Wed, 31 Jan 2024 22:24:14 GMT, Justin Lu wrote: > Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) > which adds MessageFormat pattern support for the following subformats: > ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is > intended to prov

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v8]

see a trailing `}` only with the second option. > > However, if you then invoke `toPattern()`, the result is > `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the > "extra" closing brace is no longer quoted, it matches the opening brace at >

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v7]

On Thu, 1 Feb 2024 23:57:24 GMT, Naoto Sato wrote: >> Archie Cobbs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix misspelling in comment. > > src/java.base/share/classes/java/text/MessageFor

Re: RFR: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern [v7]

On Thu, 1 Feb 2024 23:02:59 GMT, Justin Lu wrote: >> Archie Cobbs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Fix misspelling in comment. > > test/jdk/java/text/Format/MessageFormat/MessageForma

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v6]

ro. > > The fix is to ignore what's `available()` and just proceed and see what > happens. If fewer bytes are available than required, the attempt to extend to > another stream is canceled just as it was before, e.g., when the next stream > header couldn't be read. Arch

Integrated: 8323699: MessageFormat.toPattern() generates non-equivalent MessageFormat pattern

On Sun, 14 Jan 2024 15:32:12 GMT, Archie Cobbs wrote: > Please consider this fix to ensure that going from `MessageFormat` to pattern > string via `toPattern()` and then back via `new MessageFormat()` results in a > format that is equivalent to the original. > > The quoting and

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v6]

On Mon, 26 Feb 2024 06:51:12 GMT, Jaikiran Pai wrote: >> 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 contains six addi

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v6]

On Wed, 6 Mar 2024 14:14:56 GMT, Jaikiran Pai wrote: >> 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 contains six addi

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v7]

ro. > > The fix is to ignore what's `available()` and just proceed and see what > happens. If fewer bytes are available than required, the attempt to extend to > another stream is canceled just as it was before, e.g., when the next stream > header couldn't be read. Arch

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v6]

On Thu, Mar 7, 2024 at 2:20 PM Louis Bergelson wrote: > >> `GZIPInputStream`, when looking for a concatenated stream, relies on > what the underlying `InputStream` says is how many bytes are `available()`. > But this is inappropriate because `InputStream.available()` is just an > estimate and is

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v8]

ro. > > The fix is to ignore what's `available()` and just proceed and see what > happens. If fewer bytes are available than required, the attempt to extend to > another stream is canceled just as it was before, e.g., when the next stream > header couldn't be read. Arch

Re: RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v9]

ro. > > The fix is to ignore what's `available()` and just proceed and see what > happens. If fewer bytes are available than required, the attempt to extend to > another stream is canceled just as it was before, e.g., when the next stream > header couldn't be read. Arch

Integrated: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream

On Thu, 14 Dec 2023 20:15:39 GMT, Archie Cobbs wrote: > `GZIPInputStream`, when looking for a concatenated stream, relies on what the > underlying `InputStream` says is how many bytes are `available()`. But this > is inappropriate because `InputStream.available()` is just an estima

RFR: 8322256: Define and document GZIPInputStream concatenated stream semantics

`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 to read a GZIP header frame and, if successful, proceeds onward to decompres

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

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 [v3]

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 [v4]

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

  1   2   3   >