8301873: Avoid string decoding in ZipFile.Source.getEntryPos #12290

eirbjo · 2023-01-30T10:32:38Z

After finding a hash match, getEntryPos needs to compare the lookup name up to the encoded entry name in the CEN. This comparison is done by decoding the entry name into a String. The names can then be compared using the String API. This decoding step adds a significat cost to this method.

This PR suggest to update the string comparison such that in the common case where both the lookup name and the entry name are encoded in ASCII-compatible UTF-8, decoding can be avoided and the byte arrays can instead be compared direcly.

ZipCoder is updated with a new method to compare a string with an encoded byte array range. The default implementation decodes to string (like the current code), while the UTF-8 implementation uses JavaLangAccess.getBytesNoRepl to get the bytes. Both methods thes uses Arrays.mismatch for comparison with or without matching trailing slashes.

Additionally, this PR suggest to make the following updates to getEntryPos:

The try/catch for IAE is redundant and can be safely removed. (initCEN already checks this and will throws IAE for invalid UTF-8). This seems to give a 3-4% speedup on micros)
A new test InvalidBytesInEntryNameOrComment is a added to verify that initCEN does in fact reject invalid UTF-8 in CEN file names and comments. (I found no existing test coverage for this)
The recursion when looking for "name/" matches is replaced with iteration. We keep track of any "name/" match and return it at the end of the search. (I feel this is easier to follow and it also gives a ~30% speedup for addSlash lookups with no regression on regular lookups)

(My though is that including these additional updates in this PR might reduce reviewer overhead given that it touches the exact same code. I might be wrong on this, please advise :)

I'm seeing a ~17% saving on the micro ZipFileGetEntry.getEntryHit (modified to use xalan.jar):

Baseline:

Benchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   74.941 ± 1.004  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   84.943 ± 1.320  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  120.371 ± 2.386  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  126.128 ± 1.075  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   23.818 ± 0.838  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   29.762 ± 5.998  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   59.405 ± 0.545  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   71.840 ± 2.455  ns/op
ZipFileGetEntry.getEntrySlash            512  avgt   15  135.621 ± 4.341  ns/op
ZipFileGetEntry.getEntrySlash           1024  avgt   15  134.190 ± 2.141  ns/op

PR:

Benchmark                             (size)  Mode  Cnt    Score   Error  Units
ZipFileGetEntry.getEntryHit              512  avgt   15   62.267 ± 1.329  ns/op
ZipFileGetEntry.getEntryHit             1024  avgt   15   72.916 ± 2.428  ns/op
ZipFileGetEntry.getEntryHitUncached      512  avgt   15  101.630 ± 1.154  ns/op
ZipFileGetEntry.getEntryHitUncached     1024  avgt   15  113.161 ± 0.502  ns/op
ZipFileGetEntry.getEntryMiss             512  avgt   15   23.003 ± 1.191  ns/op
ZipFileGetEntry.getEntryMiss            1024  avgt   15   23.236 ± 1.114  ns/op
ZipFileGetEntry.getEntryMissUncached     512  avgt   15   56.781 ± 1.505  ns/op
ZipFileGetEntry.getEntryMissUncached    1024  avgt   15   67.767 ± 1.963  ns/op
ZipFileGetEntry.getEntrySlash            512  avgt   15   73.745 ± 2.717  ns/op
ZipFileGetEntry.getEntrySlash           1024  avgt   15   75.784 ± 1.051  ns/op

To assess the impact on startup/warmup, I made a main method class which measures the total time of calling ZipFile.getEntry for all entries in the 109 JAR file dependenies of spring-petclinic. The shows a nice improvement (time in micros):

Percentile Baseline Patch
50 %          23155 21149
75 %          23598 21454
90 %          23989 21691
95 %          24238 21973
99 %          25270 22446
STDEV           792   549
Count           500   500

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8301873: Avoid string decoding in ZipFile.Source.getEntryPos

Reviewers

Claes Redestad (@cl4es - Reviewer) ⚠️ Review applies to 3cb77dba
Lance Andersen (@LanceAndersen - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/12290/head:pull/12290
$ git checkout pull/12290

Update a local copy of the PR:
$ git checkout pull/12290
$ git pull https://git.openjdk.org/jdk pull/12290/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 12290

View PR using the GUI difftool:
$ git pr show -t 12290

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/12290.diff

…Pos for the common case that both the name and the entry name are encoded in LATIN1 compatible UTF-8

bridgekeeper · 2023-01-30T10:33:33Z

👋 Welcome back eirbjo! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2023-01-30T10:36:12Z

@eirbjo The following labels will be automatically applied to this pull request:

core-libs
security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

…e and API with a ~3% regression on getEntryHit

eirbjo · 2023-01-30T14:14:18Z

As suggested by @cl4es, I've replaced the use of ArraySupport.mismatch with Arrays.mismatch. The added range checks seems to give a regression of ~3% on the getEntryHit micro.

eirbjo · 2023-01-30T14:20:58Z

src/java.base/share/classes/java/lang/System.java

+                if (false) {
+                    // Arrays.mismatch without the range checks (~3% faster micro getEntryHit)
+                    int aLength = encoded.length;
+                    int bLength = toIndex - fromIndex;
+                    int length = Math.min(aLength, bLength);
+                    int i = ArraysSupport.mismatch(encoded, 0, b, fromIndex, length);
+                    return (i < 0 && aLength != bLength) ? length : i;
+                }
+                return Arrays.mismatch(encoded, 0, encoded.length, b, fromIndex, toIndex);
+            }


Leaving the ArraySupport.mismatch code here for now if anyone wants to investigate the ~3% regression introduced by the range checks in Arrays.mismatch

The performance hit of using Arrays.mismatch instead of ArraysSupport might be more like 5% actually:

Benchmark (size) Mode Cnt Score Error Units ZipFileGetEntry.getEntryHit 512 avgt 15 59.149 ± 0.820 ns/op ZipFileGetEntry.getEntryHit 1024 avgt 15 73.250 ± 1.114 ns/op ZipFileGetEntry.getEntryHitUncached 512 avgt 15 103.377 ± 1.118 ns/op ZipFileGetEntry.getEntryHitUncached 1024 avgt 15 115.418 ± 2.767 ns/op ZipFileGetEntry.getEntryMiss 512 avgt 15 22.200 ± 0.145 ns/op ZipFileGetEntry.getEntryMiss 1024 avgt 15 22.528 ± 0.271 ns/op ZipFileGetEntry.getEntryMissUncached 512 avgt 15 57.359 ± 0.428 ns/op ZipFileGetEntry.getEntryMissUncached 1024 avgt 15 68.013 ± 2.070 ns/op ZipFileGetEntry.getEntrySlash 512 avgt 15 72.407 ± 0.603 ns/op ZipFileGetEntry.getEntrySlash 1024 avgt 15 82.875 ± 11.094 ns/op

… win for "name/" matches.

… checked opening time by initCEN

…pFile rejects opening a ZIP with invalid UTF-8 byte sequences in its name or comment fields

…mentation to decode to string for comparison instead of encoding to bytes, this seems safer. Revert some changes from previous commits to parameters in the hasTrailingSlash method.

eirbjo · 2023-02-02T18:44:26Z

I realized that encoding to bytes and then comparing to CEN bytes might not be safe for encodings were multiple representations is possible for the same code points. So I moved string/byte array comparison into ZipCoder, which can now decode from CEN and compare as in the current code. Micros indicate this has no performance impact.

…t have as much as 5% regression

cl4es · 2023-02-05T22:13:50Z

src/java.base/share/classes/java/lang/System.java

+
+            @Override
+            public int mismatchUTF8(String str, byte[] b, int fromIndex, int toIndex) {
+                byte[] encoded = str.isLatin1() ? str.value() : str.getBytes(UTF_8.INSTANCE);


I think this is incorrect: latin-1 characters above codepoint 127 (non-ascii) would be represented by 2 bytes in UTF-8. What you want here is probably str.isAscii() ? .... The ASCII check will have to look at the bytes, so will incur a minor penalty.

Good news is that you should already be able to do this with what's already exposed via JLA.getBytesNoRepl(str, StandardCharsets.UTF_8), so no need for more shared secrets.

Nice, I have updated the PR such that the new shared secret is replaced with using getBytesNoRepl instead. If there is a performance difference, it seems to hide in the noise.

I had expected such a regression to be caught by existing tests, which seems not to be the case. I added TestZipFileEncodings.latin1NotAscii to adress this.

getBytesNoRepl throws CharacterCodingException "for malformed input or unmappable characters".

This should never happen since initCEN should already reject it. If it should happen anyway, I return NO_MATCH which will ignore the match just like the catch in getEntryPos currently does.

Yes, this should be fine.

cl4es · 2023-02-06T11:19:32Z

src/java.base/share/classes/java/lang/System.java

+                byte[] encoded = str.isLatin1() ? str.value() : str.getBytes(UTF_8.INSTANCE);
+                if (false) {
+                    // Arrays.mismatch without the range checks (~5% faster micro getEntryHit)
+                    int aLength = encoded.length;


Part of the difference you're seeing is due to knowing that you'll be matching the entire length of the first array (encoded, 0, encoded.length).

As an experiment I added Arrays.mismatch(byte[], byte[], int, int) to mismatch the entire range of the first array argument vs the range of the second and can spot an improvement in affected micros:

Benchmark (size) Mode Cnt Score Error Units ArraysMismatch.Char.differentSubrangeMatches 90 avgt 10 12.165 ± 0.074 ns/op # mismatch(a, aFrom, aTo, b, bFrom, bTo) ArraysMismatch.Char.subrangeMatches 90 avgt 10 10.748 ± 0.006 ns/op # mismatch(a, b, bFrom, bTo)

This might be something we can solve in the JITs without having to add new methods to java.util.Arrays to deal as efficiently as possible with the case when we're matching against the entirety of one of the arrays.

Interesting. Would be nice to solve this in the JIT!

This disabled code got deleted in my last commit, but it seems like you have a good analysis so we can let it go now.

Right. I might have fumbled this experiment a bit, and perhaps your setup would inline and then eliminate some of the known-in-range checks already.

Though we have intrinsified some of the Preconditions.check* methods in the past to help improve range checks, but the checkFromToIndex method that would be applicable here has not been intrinsified. It might be a reasonable path forward to replace Arrays.rangeCheck with Preconditions.checkFromToIndex and then look at intrinsifying that method to help eliminating or optimizing some of the checks.

Nevermind, I had a flaw in my experiment and seems the first range check in a call like Arrays.mismatch(encoded, 0, encoded.length, b, off, off+len); should be eliminated. So perhaps you're seeing the cost of the second range check, which might be unavoidable to be safe (zip meta data could otherwise be doctored to try and perform out of bounds reads via intrinsified code)

…ompare. Add a test case for UTF-8 encoded entry name which is latin1, but not ASCII

cl4es · 2023-02-06T14:54:54Z

Filed JDK-8301873 for this, update PR title when you're ready.

eirbjo · 2023-02-06T14:57:19Z

/issue 8301873

cl4es · 2023-02-09T11:39:18Z

Yes, I'll file a PR to see if we can make startsWith a bit sharper. In addition to - or instead of - an equals shortcut then if coders are the same we could use ArraysSupport.mismatch which should get similar speed and help more generally.

eirbjo · 2023-02-09T11:46:42Z

Yes, I'll file a PR to see if we can make startsWith a bit sharper

Thanks! I pushed the change to ZipCoder.compare.

In addition to - or instead of - an equals shortcut then if coders are the same we could use ArraysSupport.mismatch which should get similar speed and help more generally.

..and if String had (an optimized) mismatch method, then I bet all or most of the comparison methods (equals, compareTo, endsWith, startsWith, regionMatches) could delegate to that :-)

cl4es · 2023-02-09T13:05:44Z

In addition to - or instead of - an equals shortcut then if coders are the same we could use ArraysSupport.mismatch which should get similar speed and help more generally.

..and if String had (an optimized) mismatch method, then I bet all or most of the comparison methods (equals, compareTo, endsWith, startsWith, regionMatches) could delegate to that :-)

A private mismatch method might make sense. A public method would require making a stronger case, I think, e.g. showing use cases a mismatcher would solve (elegantly, performantly) that can't be expressed with existing methods.

LanceAndersen

Thank you Eirik for your efforts here. I am running your latest changes through our internal Mach5 systems.

Additional comments below which are meant to add clarity for future maintainers

LanceAndersen · 2023-02-13T19:59:50Z

src/java.base/share/classes/java/util/zip/ZipFile.java

                    }
                }
                idx = getEntryNext(idx);
            }
-            return -1;
+            // No exact match found, will return either slashMatch or -1
+            return slashMatch;


This gets a bit confusing as we return pos when we have an exact match so it would be helpful to had more clarity via additional comments(it might not have been clear with the previous comments but I think if we are going to add slashMatch we should take the time to beef up the comments

The dual-modality of this method certainly allows for some head-scratch trying to find a succinct way to describe its logic. I have made an attempt to improve it, but I'm sure it could be even better.

The slashPos name was probably ok as a local variable, but now that it is part of the contract of ZipCoder.compare, I think it helps to rename the enum value to DIRECTORY_NAME and update slashPos to dirPos accordingly.

Do you have any suggestions on how to improve the comments in the last version?

LanceAndersen · 2023-02-13T20:00:51Z

src/java.base/share/classes/java/util/zip/ZipCoder.java

+        SLASH_MATCH,
+        NO_MATCH
+    }
+


Please add a comment indicating what the values mean

I added comments to the enum and each of the values.

LanceAndersen · 2023-02-13T20:02:02Z

src/java.base/share/classes/java/util/zip/ZipCoder.java

+     * String for comparison, this can be avoided if the String coder
+     * is known and matches the charset of this ZipCoder.
+     */
+    Comparison compare(String str, byte[] b, int off, int len, boolean addSlash) {


If you could add an @param comments, that would be awesome 😎

I improved the Javadoc of this method and added @param comments.

LanceAndersen · 2023-02-13T20:20:22Z

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java

+    @Test(expectedExceptions = ZipException.class,
+            expectedExceptionsMessageRegExp = BAD_ENTRY_NAME_OR_COMMENT)
+    public void shouldRejectInvalidName() throws IOException {
+        try (ZipFile zf = new ZipFile(invalidName.toFile())) {


If you could please convert to use expectThrows to get to validate the message name

The message is already validated using expectedExceptionsMessageRegExp in the @Test annotation.

Would you prefer if I use expectThrows instead, or perhaps inline the BAD_ENTRY_NAME_OR_COMMENT constant as a literal?

Sorry if this was not clear, we have gone away from using the annotation element exepectedExceptions for new and updated tests and have tried to standardize on assertThrows and expectThrows instead which is the basis for my suggestion.

Thank you for your other updates. I will go through them later today

No worries, this makes sense. Updated to expectThrows with assertEquals.

LanceAndersen · 2023-02-13T21:17:20Z

test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java

@@ -115,6 +124,54 @@ public void testUnicodeManyEntries(String charsetName) throws Throwable {
        test(70000, 10, true, Charset.forName(charsetName));
    }

+    @Test


Please add a comment introducing the test

I described the rationale of adding this test in a comment.

LanceAndersen · 2023-02-13T21:17:35Z

test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java

+            assertNotNull(z.getEntry(entryName));
+        }
+    }
+    @Test(dataProvider = "all-charsets")


Please add a comment introducing the test

I described the rationale of adding this test in a comment.

LanceAndersen · 2023-02-13T21:19:13Z

test/jdk/java/util/zip/ZipFile/TestZipFileEncodings.java

@@ -247,7 +304,7 @@ private void writeEntry(ZipOutputStream zos, CRC32 crc,
                crc.update(data);
                ze.setCrc(crc.getValue());
            }
-            ze.setTime(System.currentTimeMillis());
+            ze.setTime(1675862371399L);


Please add a comment indicating what the time is

This change was accidentaly introduced, I have reverted it. Good catch.

…ues. Describe rationale for the tests added to TestZipFileEncodings. Revert unintended change in setTime in TestZipFileEncodings. Rename Comparison.SLASH_MATCH to DIRECTORY_MATCH.

eirbjo · 2023-02-14T08:42:46Z

Thanks for your thorough and helpful review, Lance.

LanceAndersen

Thank you Eirik, it looks much better.

I will kick off another run tomorrow and make another pass as it has been a long day :-)

Thank you again for your work here to improve the Zip code base

LanceAndersen · 2023-02-14T23:12:38Z

test/jdk/java/util/zip/ZipFile/InvalidBytesInEntryNameOrComment.java

-            // Should throw ZipException
-        }
+        ZipException ex = expectThrows(ZipException.class, () -> {
+            openZipFile(invalidName);


You could just do

ZipException ex = expectThrows(ZipException.class, () -> { new ZipFile(invalidName.toFile()) });

versus adding openZipFile()

The habit of opening resources in a TwR is hard to break, but I guess it's ok for a test like this. I have inlined the method and removed the TwR.

The habit of opening resources in a TwR is hard to break, but I guess it's ok for a test like this. I have inlined the method and removed the TwR.

Agree, thanks for addressing the suggestion as it makes the test cleaner given expects/assertThrows should react to the Exception being thrown by new ZipFile(...)

My inlining accidentally made the shouldRejectInvalidComment test the invalid name file. Fixed with last commit.

…coded string" refers to those found in the CEN byte array and to use the term "the encoded string" instead of the more convoluted "the string encoded in the byte array".

…in the invalid comment test

LanceAndersen · 2023-02-16T18:03:03Z

As soon as my last set of Mach5 runs complete I will approve this change. The JCK tests in this area also look good.

LanceAndersen

Thank you Eirik for your patience through the review and testing of your PR.

I think we are in good shape overall. Mach5 tiers1-6 look good as do the JCK tests for Zip

Best
Lance

eirbjo · 2023-02-18T12:02:20Z

/integrate

openjdk · 2023-02-18T12:04:01Z

@eirbjo
Your change (at version 08160a1) is now ready to be sponsored by a Committer.

cl4es · 2023-02-18T12:37:51Z

/sponsor

openjdk · 2023-02-18T12:39:29Z

Going to push as commit 78f71b4.
Since your change was applied there have been 168 commits pushed to the master branch:

f82385e: 8302623: jarsigner - use BufferedOutputStream to improve performance while creating the signed jar
43cf8b3: 8302664: Fix several incorrect usages of Preconditions.checkFromIndexSize
6b082fb: 8302615: make JVMTI thread cpu time functions optional for virtual threads
7c60b9c: 8302358: Behavior of adler32 changes after JDK-8300208
86b9fce: 8301992: Embed SymbolTable CHT node
03d613b: 8294402: Add diagnostic logging to VMProps.checkDockerSupport
a263f28: 8302777: CDS should not relocate heap if mapping fails
a917fb3: 7033677: potential cast error in MemberEnter
6120319: 8302226: failure_handler native.core should wait for coredump to finish
fef3eab: 8302734: Parallel: Remove unused LGRPSpace::_invalid_region
... and 158 more: https://git.openjdk.org/jdk/compare/09b8a1959771213cb982d062f0a913285e4a0c6e...master

Your commit was automatically rebased without conflicts.

openjdk · 2023-02-18T12:39:42Z

@cl4es @eirbjo Pushed as commit 78f71b4.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

eirbjo added 2 commits January 30, 2023 10:38

Avoid decoding the entry name string when comparing names in getEntry…

d7813a2

…Pos for the common case that both the name and the entry name are encoded in LATIN1 compatible UTF-8

Update copyright years

79247e8

eirbjo changed the title ~~Avoid string decoding and allocation in ZipFile.Source.getEntryPos~~ Avoid string decoding in ZipFile.Source.getEntryPos Jan 30, 2023

openjdk bot added security security-dev@openjdk.org core-libs core-libs-dev@openjdk.org labels Jan 30, 2023

Use Arrays.mismatch instead of ArraySupport, allowing for cleaner cod…

448b4d4

…e and API with a ~3% regression on getEntryHit

eirbjo commented Jan 30, 2023

View reviewed changes

eirbjo added 8 commits January 31, 2023 19:10

Make getEntryPos non-recursive. No regression for exact matches, ~30%…

a72a9ca

… win for "name/" matches.

The try/catch for IllegalArgumentException is redundant since this is…

6771407

… checked opening time by initCEN

Adding test InvalidEntryNameOrCommentEncoding which validates that Zi…

e58a3ff

…pFile rejects opening a ZIP with invalid UTF-8 byte sequences in its name or comment fields

Revert accidental change to comment

eeeaace

Simplify comment for "name/" match

0699dee

Improve summary for the test

f2a7867

Produce template ZIP as a byte[] instead of writing it to disk

5ee69b4

ByteBuffers for reading ZIP files must be little-endian

92a0841

eirbjo marked this pull request as ready for review February 2, 2023 13:38

Move String/byte[] comparison into ZipCoder. Change the default imple…

682d571

…mentation to decode to string for comparison instead of encoding to bytes, this seems safer. Revert some changes from previous commits to parameters in the hasTrailingSlash method.

eirbjo added 4 commits February 2, 2023 19:56

Micros seem to indicate that the range checks in Arrays.mismatch migh…

aab08c5

…t have as much as 5% regression

Some minor improvements to code comments

08320fe

Adjust whitespace

e0c29bd

Rename test to InvalidBytesInEntryNameOrComment

301a4c5

cl4es reviewed Feb 5, 2023

View reviewed changes

cl4es reviewed Feb 6, 2023

View reviewed changes

Replace new shared secret with using getBytesNoRepl in UTF8ZipCoder.c…

3ca98e2

…ompare. Add a test case for UTF-8 encoded entry name which is latin1, but not ASCII

Revert accidental removal of UTF8ZipCoder.compare

d94cbe3

LanceAndersen reviewed Feb 13, 2023

View reviewed changes

Improve documentation of ZipCoder.compare and the Comparison enum val…

a633d27

…ues. Describe rationale for the tests added to TestZipFileEncodings. Revert unintended change in setTime in TestZipFileEncodings. Rename Comparison.SLASH_MATCH to DIRECTORY_MATCH.

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Feb 14, 2023

Remove accidentally introduced trailing whitespace

21cdb73

openjdk bot added ready Pull request is ready to be integrated rfr Pull request is ready for review labels Feb 14, 2023

Prefer expectThrows with asserts over test annotation regex

4981abd

LanceAndersen reviewed Feb 14, 2023

View reviewed changes

eirbjo added 3 commits February 15, 2023 10:50

Inline openZipFile and remove TwR

49ad8d3

Update javadocs for ZipCoder.Comparison to first clarify that the "en…

9b83002

…coded string" refers to those found in the CEN byte array and to use the term "the encoded string" instead of the more convoluted "the string encoded in the byte array".

Fix a regression where the invalidName was tested instead of comment …

08160a1

…in the invalid comment test

LanceAndersen approved these changes Feb 18, 2023

View reviewed changes

openjdk bot added the sponsor Pull request is ready to be sponsored label Feb 18, 2023

openjdk bot added the integrated Pull request has been integrated label Feb 18, 2023

openjdk bot closed this Feb 18, 2023

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Feb 18, 2023

8301873: Avoid string decoding in ZipFile.Source.getEntryPos #12290

8301873: Avoid string decoding in ZipFile.Source.getEntryPos #12290

Conversation

eirbjo commented Jan 30, 2023 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Jan 30, 2023

openjdk bot commented Jan 30, 2023

eirbjo commented Jan 30, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eirbjo commented Feb 2, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cl4es commented Feb 6, 2023

eirbjo commented Feb 6, 2023

cl4es commented Feb 9, 2023 • edited Loading

eirbjo commented Feb 9, 2023

cl4es commented Feb 9, 2023

LanceAndersen left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eirbjo Feb 14, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eirbjo Feb 14, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eirbjo commented Feb 14, 2023

LanceAndersen left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LanceAndersen Feb 15, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

LanceAndersen commented Feb 16, 2023

LanceAndersen left a comment

Choose a reason for hiding this comment

eirbjo commented Feb 18, 2023

openjdk bot commented Feb 18, 2023

cl4es commented Feb 18, 2023

openjdk bot commented Feb 18, 2023

openjdk bot commented Feb 18, 2023

eirbjo commented Jan 30, 2023 •

edited by openjdk bot

Loading

cl4es commented Feb 9, 2023 •

edited

Loading

eirbjo Feb 14, 2023 •

edited

Loading

eirbjo Feb 14, 2023 •

edited

Loading

LanceAndersen Feb 15, 2023 •

edited

Loading