(original) (raw)
Xueming,
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.
Martin
On Thu, Jun 25, 2009 at 09:12, Xueming Shen <Xueming.Shen@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
�src/share/classes/sun/tools/jar/Main.java
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".
Description:
\- 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.