> > > > > > Are we really willing to maintain tests for UTF-8, ASCII-compatible, and > > ASCII-incompatible code paths? > > If we aren't then I think we should terminally deprecate all the ZipFile > constructors that take a Charset argument. Not a call I can make. >
I mean more generally. You're proposing to fix zip files where the metadata is UTF-16 encoded. But I suspect we aren't testing such zip files at all, and I suspect it's broken in other ways, that we might discover by expanding our zip tests to fully cover such zip files. > > > > > ASCII-compatibility is also deeply embedded in the original C code, > > which is still there > > Yep, the assumption go way back, but as long as it's functionality only > relevant to jar files it's fine in both impls. > > Is there any usage left of the C implementation these days? > Bootclassloader likely doesn't use java code! So -Xbootclasspath/a is implemented using that C code. --- The number one reason to make a zip test "manual" is that it consumes too many resources to run all the time.
