Miscellaneous improvements to "jar".
martinrb at google.com
Thu Jun 25 17:50:36 UTC 2009
Congratulations for finding the incompatible change!
Yes, if you are running in a turkish locale (unlikely)
and if your jar file has the index entry in lower case,
(unlikely - hopefully INDEX.LIST files are all machine generated).
then it will not be found in the old implementation,
and will be found in the new one.
Can we consider this a simple bug fix? Please?
Even if all of the above occurs, the change in behavior may be benign -
the resulting jar file will contain both upper and lower case index files.
Perhaps I should add a test, but it would be painful to write one.
It was never a good idea to make these entry names case-insensitive.
On Thu, Jun 25, 2009 at 09:12, Xueming Shen <Xueming.Shen at sun.com> wrote:
> do we have a Turkish i "regression" for the index name comparing by
> assuming ASCII only?
> yes, the original impl is not consistent already when dealing with manifest
> and index , one use
> toUpperCase(Locale.ENGLISH), one does not.
> Martin Buchholz wrote:
>> Hi jar team,
>> I have a bunch of minor improvements to
>> Toby and Xueming, please review.
>> Warning: the index code has not been maintained for many years.
>> Xueming, please file a bug.
>> Synopsis: Miscellaneous improvements to "jar".
>> - Use standard jdk coding style for javadoc
>> - Don't create a temp file for jar index in STORED mode.
>> - Don't use synchronized collections.
>> - Fix javac warnings.
>> - Don't define new names for things like INDEX_NAME;
>> use static import instead.
>> - more efficiently compare special file names in update mode.
>> Update mode should be measurably faster.
>> - make CRC32OutputStream a nested class.
>> refactor crc32.reset and updating entry into CRC32OutputStream.
>> - Fix apparently benign bug updating n in CRC32OutputStream.write(byte,
>> int, int)
>> Evaluation: Yep.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the core-libs-dev