On Fri, 8 Mar 2024 09:34:05 GMT, Eirik Bjørsnøs wrote:
>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes`
>> to `ZipEntry.externalFileAttributes`.
>>
>> This field was introduced in
>> [JDK-8218021](https://bugs.openjdk.org/browse/
On Sun, 10 Mar 2024 05:50:33 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which removes the 19 deprecated `xxObject*` alias
> methods from `jdk.internal.misc.Unsafe`.
>
> These methods were added in JDK-8213043 (JDK 12), presumably to allow
> `jsr166.jar` to be used acro
On Sun, 10 Mar 2024 13:47:06 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which removes the 19 deprecated `xxObject*` alias
>> methods from `jdk.internal.misc.Unsafe`.
>>
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow
>> `jsr
On Sun, 10 Mar 2024 13:47:43 GMT, Eirik Bjørsnøs wrote:
> Yes, you'll need to run all tests to make sure that there aren't any others,
> e.g. test/hotspot/jtreg/compiler/stable/TestUnstableStable.java.
Alan,
With @jaikiran running Oracle CI tier1, tier2, tier3 and observing only th
On Sun, 10 Mar 2024 12:18:02 GMT, Alan Bateman wrote:
> Yes, you'll need to run all tests to make sure that there aren't any others,
> e.g. test/hotspot/jtreg/compiler/stable/TestUnstableStable.java.
I've updated `TestUnstableStable` to use `putReference` and also fixed a stray
code comment
@Martin-Buchholz to verify that this removal is timely.
Eirik Bjørsnøs has updated the pull request incrementally with two additional
commits since the last revision:
- Replace calls to Unsafe.putObject with Unsafe.putReference
- Update a code comment referencing Unsafe.compareAndSetObje
On Sun, 10 Mar 2024 08:14:02 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which removes the 19 deprecated `xxObject*` alias
>> methods from `jdk.internal.misc.Unsafe`.
>>
>> These methods were added in JDK-8213043 (JDK 12), presumably to allow
>> `jsr
@Martin-Buchholz to verify that this removal is timely.
Eirik Bjørsnøs has updated the pull request incrementally with one additional
commit since the last revision:
Use getAndSetReference instead of getAndSetObject in
test/hotspot/jtreg/gc/shenandoah/compiler/TestUnsafeLoadStoreMergedHeapSt
Please review this PR which removes the 19 deprecated `xxObject*` alias methods
from `jdk.internal.misc.Unsafe`.
These methods were added in JDK-8213043 (JDK 12), presumably to allow
`jsr166.jar` to be used across JDK versions. This was a follow-up fix after
JDK-8207146 had renamed these
On Mon, 19 Feb 2024 18:35:58 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which proposes that we officially deprecate the
> following four methods in the `java.util.zip` package:
>
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `D
On Sat, 2 Mar 2024 18:51:16 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which proposes that we officially deprecate the
>> following four methods in the `java.util.zip` package:
>>
>> * `Inflater.getTotalIn()`
>> * `Inflater.getTotalOu
fter
> these updates, and found nothing related to zip/jar. The `zip` and `jar`
> tests run clean:
>
>
> make test TEST="test/jdk/java/util/jar"
> make test TEST="test/jdk/java/util/zip"
Eirik Bjørsnøs has updated the pull request incrementally with one add
On Wed, Mar 6, 2024 at 5:41 PM Alan Bateman wrote:
This discussion is about the JDK's internal Unsafe, not sun.misc.Unsafe.
>
Thanks Alan, I guess I should have made this more clear from the beginning.
I'll await a response from the wise men on Mandy's JDK-8207146 comment
before proposing a
Hi,
Now that the JDK repo is the single source of truth for
java.util.concurrent [1], I'm wondering if time has come to remove the
deprecated *Object* methods introduced in JDK-8213043 [2]
These alias methods were introduced because jsr166 used them, but there no
longer seems to be any use
On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which suggests we remove the package-private,
> unused and deprecated method `java.util.jar.Manifest.make72Safe`.
>
> This method was marked deprecated after a cleanup/refactoring in
> [JDK
On Mon, 4 Mar 2024 09:55:09 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which suggests we remove the package-private,
> unused and deprecated method `java.util.jar.Manifest.make72Safe`.
>
> This method was marked deprecated after a cleanup/refactoring in
> [JDK
Please review this cleanup PR which suggests we remove the package-private,
unused and deprecated method `java.util.jar.Manifest.make72Safe`.
This method was marked deprecated after a cleanup/refactoring in
[JDK-8066619](https://bugs.openjdk.org/browse/JDK-8066619) caused it to fall
out of
This PR aims to clarify
> this in the API specification.
Eirik Bjørsnøs has updated the pull request incrementally with one additional
commit since the last revision:
Make the new specification text an @implSpec
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17919
Hi,
The non-public method java.util.jar.Manifest.make72Safe is marked
@Deprecated(since="13").
However, the Javadoc comment has a '@deprecation' tag which presumably
should have been `@deprecated`.
I first thought of proposing a PR to fix the invalid tag, but then I
noticed that the method is
On Tue, 27 Feb 2024 20:14:27 GMT, Lance Andersen wrote:
> Yes please move forward and thank you
I have updated javadocs for the remaining methods.
The CSR has been proposed and is ready for the initial round of review:
https://bugs.openjdk.org/browse/JDK-8326326
-
PR Comment:
This PR aims to clarify
> this in the API specification.
>
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three
> methods will be updated once the wordsmithing for this method stabilizes.
Eirik Bjørsnøs has updated the pull request incrementally with one add
On Tue, 27 Feb 2024 19:59:08 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which proposes that we officially deprecate the
>> following four methods in the `java.util.zip` package:
>>
>> * `Inflater.getTotalIn()`
>> * `Inflater.getTotalOu
This PR aims to clarify
> this in the API specification.
>
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three
> methods will be updated once the wordsmithing for this method stabilizes.
Eirik Bjørsnøs has updated the pull request incrementally with one addit
On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen wrote:
> This PR updates the javadoc and comments within java.util.zip/jar and zipfs
> module summary so that it is consistent with the use of "ZIP".
>
> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java
> has been
On Mon, 26 Feb 2024 19:55:47 GMT, Lance Andersen wrote:
> This PR updates the javadoc and comments within java.util.zip/jar and zipfs
> module summary so that it is consistent with the use of "ZIP".
>
> In addition, open/src/java.base/share/classes/java/util/zip/package-info.java
> has been
On Mon, 26 Feb 2024 19:54:11 GMT, Alan Bateman wrote:
> > I'm wondering if the somewhat tedious "number of compressed bytes input so
> > far" could be further simplified. Besides being a long repetition from the
> > leading sentence, when used in this sentence, we actually mean to refer to
>
On Mon, 26 Feb 2024 19:35:26 GMT, Lance Andersen wrote:
> This sentence to me seems a bit hard to digest and you basically get the
> point across in the `@deprecated` message
This new text was added after a discussion with Alan (see above) concluded that
the method should specify its behavior
This PR aims to clarify
> this in the API specification.
>
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three
> methods will be updated once the wordsmithing for this method stabilizes.
Eirik Bjørsnøs has updated the pull request with a new target base due t
On Sun, 25 Feb 2024 15:19:59 GMT, Alan Bateman wrote:
> For the class description then it might be simpler to reduce the new text
> down to one sentence, e.g.
@AlanBateman Thanks for the condensed text, that's indeed much better! I've
pushed your suggestion, only adding a link around
This PR aims to clarify
> this in the API specification.
>
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three
> methods will be updated once the wordsmithing for this method stabilizes.
Eirik Bjørsnøs has updated the pull request incrementally with one additio
On Sat, 17 Feb 2024 12:08:38 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR in preparation for deprecating
> `Deflater.getTotalIn()` in JDK-8326096.
>
> This PR replaces `GZIPOutputStream.writeTrailer`'s call to
> `Deflater.getTotalIn()` with a call to `Deflat
On Sat, 24 Feb 2024 18:54:07 GMT, Lance Andersen wrote:
>> Please review this PR which addresses the handling of invalid UTF-8 byte
>> sequences in the entry name of a LOC file header and a Zip file comment
>> which is returned via ZipFile::getComment.
>>
>> As part of the change,
On Sat, 24 Feb 2024 14:56:01 GMT, Lance Andersen wrote:
> Please review this PR which addresses the handling of invalid UTF-8 byte
> sequences in the entry name of a LOC file header and a Zip file comment which
> is returned via ZipFile::getComment.
>
> As part of the change,
On Sat, 24 Feb 2024 14:56:01 GMT, Lance Andersen wrote:
> Please review this PR which addresses the handling of invalid UTF-8 byte
> sequences in the entry name of a LOC file header and a Zip file comment which
> is returned via ZipFile::getComment.
>
> As part of the change,
This PR aims to clarify
> this in the API specification.
>
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three
> methods will be updated once the wordsmithing for this method stabilizes.
Eirik Bjørsnøs has updated the pull request incrementally with one additiona
This PR aims to clarify
> this in the API specification.
>
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three
> methods will be updated once the wordsmithing for this method stabilizes.
Eirik Bjørsnøs has updated the pull request incrementally with one a
On Tue, 20 Feb 2024 14:23:35 GMT, Alan Bateman wrote:
> > Should these methods specify return values when the number of processed
> > bytes exceed Integer.MAX_VALUE?
>
> I think they should, otherwise it's not clear if the return value is clamped
> at Integer.MAX_VALUE. The wording can make
This PR aims to clarify
> this in the API specification.
>
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three
> methods will be updated once the wordsmithing for this method stabilizes.
Eirik Bjørsnøs has updated the pull request incrementally with two additiona
On Tue, 20 Feb 2024 11:28:08 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which proposes that we officially deprecate the
>> following four methods in the `java.util.zip` package:
>>
>> * `Inflater.getTotalIn()`
>> * `Inflater.getTotalOu
On Tue, 20 Feb 2024 07:17:53 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix {@link #getBytesRead}
>
> src/java.base/share/classes/java/util/zip/Inf
This PR aims to clarify
> this in the API specification.
>
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three
> methods will be updated once the wordsmithing for this method stabilizes.
Eirik Bjørsnøs has updated the pull request incrementally with two additi
On Tue, 20 Feb 2024 07:13:41 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix {@link #getBytesRead}
>
> src/java.base/share/classes/java/util/zip/Inf
This PR aims to clarify
> this in the API specification.
>
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three
> methods will be updated once the wordsmithing for this method stabilizes.
Eirik Bjørsnøs has updated the pull request incrementally with one additio
On Tue, 20 Feb 2024 07:12:41 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix {@link #getBytesRead}
>
> src/java.base/share/classes/java/util/zip/Inf
This PR aims to clarify
> this in the API specification.
>
> Initally, this PR handles only `Inflater.getTotalIn()`. The other three
> methods will be updated once the wordsmithing for this method stabilizes.
Eirik Bjørsnøs has updated the pull request incrementally with one ad
On Mon, 19 Feb 2024 18:35:58 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which proposes that we officially deprecate the
> following four methods in the `java.util.zip` package:
>
> * `Inflater.getTotalIn()`
> * `Inflater.getTotalOut()`
> * `D
Please review this PR which proposes that we officially deprecate the following
four methods in the `java.util.zip` package:
* `Inflater.getTotalIn()`
* `Inflater.getTotalOut()`
* `Deflater.getTotalIn()`
* `Deflater.getTotalOut()`
Since these legacy methods return `int`, they cannot safely
On Mon, 19 Feb 2024 09:34:12 GMT, Jaikiran Pai wrote:
> Can I get a review of this change which fixes the copyright header on
> `DeflaterDictionaryTests.java`?
Thanks for spotting this, looks good to me! Would be nice if jcheck could check
simple formatting issues like this.
-
On Mon, 19 Feb 2024 07:18:53 GMT, Jaikiran Pai wrote:
> Hello Eirik, the change looks OK to me.
Thanks for veryfying and adding helpful context!
I'll let this linger just a bit before integrating in case there is any
non-correctness feedback, like about the added comment to clarify the modulo
On Sat, 17 Feb 2024 13:00:08 GMT, Eirik Bjørsnøs wrote:
> Please review this test-only cleanup PR in preparation for deprecating
> `Deflater.getTotalOut()` in JDK-8326096.
>
> This PR replaces various calls
> in`test/jdk/java/util/zip/DeflaterDictionaryTests.java` to
> `De
On Sun, 18 Feb 2024 10:56:03 GMT, Eirik Bjørsnøs wrote:
>> Please review this test-only cleanup PR in preparation for deprecating
>> `Deflater.getTotalOut()` in JDK-8326096.
>>
>> This PR replaces various calls
>> in`test/jdk/java/util/zi
ad.
>
> Testing and verification: This is a test-only fix affecting only debug
> output. I have added the `noreg-self` label to the issue.
Eirik Bjørsnøs has updated the pull request incrementally with one additional
commit since the last revision:
Use more specific format specifier %d inst
Please review this test-only cleanup PR in preparation for deprecating
`Deflater.getTotalOut()` in JDK-8326096.
This PR replaces various calls
in`test/jdk/java/util/zip/DeflaterDictionaryTests.java` to
`Deflater.getTotalOut()` when formatting some debugging output lines.
Additionally,
Please review this cleanup PR in preparation for deprecating
`Deflater.getTotalIn()` in JDK-8326096.
This PR replaces `GZIPOutputStream.writeTrailer`'s call to
`Deflater.getTotalIn()` with a call to `Deflater.getBytesRead()` followed by an
explicit conversion to "modulo 2^32" (a cast to int)
On Sat, Feb 17, 2024 at 9:09 AM Alan Bateman
wrote:
> So I think there is good case for deprecating the old methods.
>
Thanks Alan, I'll take this task on and have filed the following task to
track it: https://bugs.openjdk.org/browse/JDK-8326096
Cheers,
Eirik.
Hi,
Initially, the Deflater and Inflater classes in java.util.zip only
supported up to 2GB of inflated or deflated data, the reason being that
their getTotalIn and getTotalOut methods returns an int.
Around 2004, this limitation was remedied by introducing the new methods
getBytesRead and
On Fri, 26 Jan 2024 20:49:57 GMT, Lance Andersen wrote:
>> To help make progress here, I have relaxed the validation such that we now
>> check:
>>
>> - That the "streaming mode" bit 3 flag is set
>> - That at least one of the LOC's size fields are marked 0x.
>> - That the LOC extra
On Sun, 12 Feb 2023 15:41:55 GMT, Eirik Bjørsnøs wrote:
> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
> number of compressed or uncompressed bytes read from the inflater is larger
> than the Zip64 magic value.
>
> While the ZIP format mandate
On Thu, 9 Mar 2023 12:06:52 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which suggests we speed up the `Zip64SizeTest` using a
> small-sized ZIP64 ZIP file specifically created to reproduce the issue being
> tested.
>
> The disk space requirement of this test is known to
JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
>
> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes
> and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
>
> The PR also fixes the `@summary` tag, which seems to have been copied
On Fri, 9 Feb 2024 11:59:13 GMT, Lance Andersen wrote:
> Again minor but perhaps articulate that after this call, the extra data will
> be(obvious to you and I but probably not to others...)
Added `zipdetails` describing the resulting ZIP64 structure to the
`updateCENHeaderToZip64` method
On Fri, 9 Feb 2024 11:55:16 GMT, Lance Andersen wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Spell fix for "Contents"
>> - Add comments to explain how we temporar
On Fri, 9 Feb 2024 12:17:17 GMT, Eirik Bjørsnøs wrote:
>> test/jdk/java/util/zip/ZipFile/Zip64SizeTest.java line 114:
>>
>>> 112:
>>> 113: // Make an extra field with the correct size for an 8-byte
>>> 'uncompressed size'
>>>
JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
>
> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes
> and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
>
> The PR also fixes the `@summary` tag, which seems to have been copied
On Fri, 9 Feb 2024 06:39:31 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs 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 13 addi
JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
>
> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes
> and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
>
> The PR also fixes the `@summary` tag, which seems to have been copied
On Thu, 8 Feb 2024 14:09:35 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which suggests we speed up the `Zip64SizeTest` using a
>> small-sized ZIP64 ZIP file specifically created to reproduce the issue being
>> tested.
>>
>> The disk space requirement
JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
>
> By using a sparse file, we reduce consumed disk space from 5GB to 266 bytes
> and also reduce the runtime from ~35 seconds to ~1 seconds on my Macbook Pro.
>
> The PR also fixes the `@summary` tag, which seems to have been copied
On Mon, 5 Feb 2024 12:31:37 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 228 commits:
>>
>> - Merge branch 'master' into data-descrip
the Info-ZIP command line
> `-fd` flag:
>
> `echo hello | zip -fd > hello.zip`
>
> The PR also adds a test verifying that such a small Zip64 file can be parsed
> by ZipInputStream.
Eirik Bjørsnøs has updated the pull request with a new target base due to a
m
On Fri, 2 Feb 2024 20:43:54 GMT, Lance Andersen wrote:
> I think the proposed change above makes things clearer. Perhaps also make the
> same change in zipfs as well while you are at it?
I have pushed the rename to "ZipEntry.externalFileAttributes". Also renamed
If the resource file changes should be dropped and instead handled via
> `msgdop` updates, let me know and I can revert the non-default files.
>
> I did a search across the code base to find 'extraAttrs', 'extra.attr' after
> these updates, and found nothing related to zip/jar. The
On Wed, 24 Jan 2024 14:34:03 GMT, Eirik Bjørsnøs wrote:
> Please review this PR to fix to a regression in ZipFileSystem, introduced by
> JDK-8322565 in PR #17170.
>
> When `Files.setPosixFilePermissions` is called on an existing MSDOS entry,
> then `Entry.posixPerms` field wil
On Fri, 2 Feb 2024 20:01:06 GMT, Lance Andersen wrote:
> It might be helpful to show the before/after output of the CEN fields here
> just for extra clarity
Thanks! Can you take a look at 4bb77e1 which shows the `zipdetails` output for
relevant fields before/after calling
ich reproduces the regression. While
> visiting this test, I also fixed an incorrect spelling of
> `setPosixFilePermissions` (also introduced by #17170).
Eirik Bjørsnøs has updated the pull request incrementally with one additional
commit since the last revision:
For clarity, add commen
On Fri, 2 Feb 2024 19:55:51 GMT, Lance Andersen wrote:
> I think the change is OK, any reason to not make it `externalFileAttributes`?
None other than length / verbosity. But since this refers to the _attributes
of the external file_, dropping any name element also loses some semantics,
On Wed, 31 Jan 2024 13:16:08 GMT, Eirik Bjørsnøs wrote:
>> Thank you for the update. This test-only change looks OK to me.
>>
>> Hello Sundar @sundararajana, given your past work on this test, do you have
>> any thoughts on this change?
>
>> Hello Sundar @su
On Mon, 27 Nov 2023 17:44:24 GMT, Eirik Bjørsnøs wrote:
> Please review this PR which rewrites the BadFactoryTest to pure Java/JUnit.
> The test is currently implemented using a mix of shell script and a Java main
> method.
>
> Reviewers may notice the following changes:
&
On Wed, 24 Jan 2024 07:08:11 GMT, Jaikiran Pai wrote:
> Hello Sundar @sundararajana, given your past work on this test, do you have
> any thoughts on this change?
@jaikiran We have not heard back from @sundararajana in the last week. It would
be nice to see this low-risk change integrated.
On Tue, 30 Jan 2024 19:57:01 GMT, Eirik Bjørsnøs wrote:
> Please review this test-only PR which improves test coverage of
> `String.regionMatches` when comparing the Turkic "dotted I" and "dotless i"
> characters with their latin cousins.
>
> The test
Please review this test-only PR which improves test coverage of
`String.regionMatches` when comparing the Turkic "dotted I" and "dotless i"
characters with their latin cousins.
The test `CompactStrings/RegionMatches.java` currently includes cases comparing
these characters against the
If the resource file changes should be dropped and instead handled via
> `msgdop` updates, let me know and I can revert the non-default files.
>
> I did a search across the code base to find 'extraAttrs', 'extra.attr' after
> these updates, and found nothing related to zip/jar. The
On Fri, 26 Jan 2024 14:32:58 GMT, Eirik Bjørsnøs wrote:
>> ZipInputStream.readEnd currently assumes a Zip64 data descriptor if the
>> number of compressed or uncompressed bytes read from the inflater is larger
>> than the Zip64 magic value.
>>
>> While the ZIP
> `-fd` flag:
>
> `echo hello | zip -fd > hello.zip`
>
> The PR also adds a test verifying that such a small Zip64 file can be parsed
> by ZipInputStream.
Eirik Bjørsnøs has updated the pull request with a new target base due to a
merge or a rebase. The pull r
Please review this PR to fix to a regression in ZipFileSystem, introduced by
JDK-8322565 in PR #17170.
When `Files.setPosixFilePermissions` is called on an existing MSDOS entry, then
`Entry.posixPerms` field will be -1 (all 1s in binary). The logic introduced by
JDK-8322565 did not account for
n-zero `crc`, `compressed size` or
> `uncompressed size` field values from a local header when in streaming mode.
> `ZipInputStream` should ignore these values and it would be good to have a
> test which asserts that this invariant holds even when the fields are
> non-zero.
Eirik B
On Wed, 24 Jan 2024 05:03:29 GMT, Jaikiran Pai wrote:
> The only part that is unclear to me is the use of `@library
> /javax/script/JDK_8196959`. Does the test fail if that isn't added?
Thanks! I must have thought this was required to put the service definition
file on the classpath. But it
"
> [..]
>TEST TOTAL PASS FAIL ERROR
>
>jtreg:test/jdk/javax/script/JDK_8196959 1 1 0 0
>
>
>
> Note that the original issue JDK-8196959 is not available in JBS, so my
> u
On Tue, 16 Jan 2024 14:55:39 GMT, Jaikiran Pai wrote:
> I think the only role that a zip64 block should play when we are deciding how
> to parse a data descriptor is whether or not the entry has zip64 extra field
> set (the header id value of the extra field). Does that sound reasonable?
Are
On Tue, 16 Jan 2024 18:18:38 GMT, Lance Andersen wrote:
> This comment could use a bit of wordsmithing to indicate what "correct" means
It's hard to write good prose for these tricky error scenarios. But just saying
"correct" without defining it is a bit too lazy, yes :-)
Please take a look
ew JUnit 5 test `CloseWrappedStream.java` which
> simulates the failure condition and verifies that the wrapped stream was
> closed under failing and non-failing conditions.
Eirik Bjørsnøs has updated the pull request incrementally with one additional
commit since the last revision
> `-fd` flag:
>
> `echo hello | zip -fd > hello.zip`
>
> The PR also adds a test verifying that such a small Zip64 file can be parsed
> by ZipInputStream.
Eirik Bjørsnøs has updated the pull request incrementally with one additional
commit since the last revision:
Remo
On Tue, 16 Jan 2024 13:54:06 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove trailing whitespace
>> - Remove trailing whitespace
>
> src/j
On Tue, 16 Jan 2024 13:42:30 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 534:
>>
>>> 532:
>>> 533: long csize = get32(tmpbuf, LOCSIZ);
>>> 534: long size = get32(tmpbuf, LOCLEN);
>>
>> Hello Eirik, I suspect this part of the
> `-fd` flag:
>
> `echo hello | zip -fd > hello.zip`
>
> The PR also adds a test verifying that such a small Zip64 file can be parsed
> by ZipInputStream.
Eirik Bjørsnøs has updated the pull request incrementally with one additional
commit since the last revision:
Remo
ew JUnit 5 test `CloseWrappedStream.java` which
> simulates the failure condition and verifies that the wrapped stream was
> closed under failing and non-failing conditions.
Eirik Bjørsnøs has updated the pull request incrementally with one additional
commit since the last revision:
Update te
On Wed, 10 Jan 2024 17:02:05 GMT, Eirik Bjørsnøs wrote:
>> Sounds like a CSR is needed for the behavioral change proposed here.
>
>> Sounds like a CSR is needed for the behavioral change proposed here.
>
> Thanks for flagging this @jddarcy
>
> I'm personal
On Fri, 8 Dec 2023 20:28:20 GMT, Eirik Bjørsnøs wrote:
> This PR suggests we retire the binary test vectors `ZipFile/input.zip`,
> `ZipFile/input.jar` and `ZipFile/crash.jar`
>
> Binary test vectors are harder to analyze, and sharing test vectors across
> unrelated
On Wed, 20 Dec 2023 18:51:08 GMT, Eirik Bjørsnøs wrote:
> This PR suggests that `Files.setPosixPermissions`as implemented by
> `ZipFileSystem` should preserve the leading seven bits of the 'external file
> attributes' field. These bits contain the 'file type', 'setuid'
On Wed, 10 Jan 2024 17:37:11 GMT, Lance Andersen wrote:
> Extra credit to convert this from testng to a junit test but not a must
Challenge accepted, see 885871f for the conversion to JUnit 5.
-
PR Comment: https://git.openjdk.org/jdk/pull/17170#issuecomment-1885395478
1 - 100 of 185 matches
Mail list logo
