[Jazzlib-developers] RE: Patches to java.util.zip by Christian Schlichtherle

[Christian S. <chr...@sc...>]

Hi everyone,

> > this would be an all-or-nothing-approach, i.e. you could have
> > CP437 for either all ZIP* objects or none. The constructors however 
> > allow you to define this on a case by case basis, e.g.
> > using CP437 for any file ending with a .zip suffix and 
> UTF-8 for any 
> > file ending with a .jar suffix, which is the most 
> reasonable general 
> > approach to deal with the encoding issue in my personal 
> opinion (which 
> > is arguable however).
> 
> Personally, I'm almost always in favor of compatibility with 
> the JDK and in this case there is no doubt in my mind that we 
> should use UTF-8 by default. I recognize that the system 
> property is only a hack that solves a limited number of 
> scenarios, but it's better than nothing.

Absolutely agreed, which is why the constructors injected by the JDK API use
UTF-8 in my patches. However, when writing a Java application that needs to
deal with general ZIP files (not just the ones created by JDK tools) I would
always use CP437 as suggested above for broader compatibility.

> > For my personal education: What's wrong about adding constructors?
> 
> It is a violation of the Sun license included with the API 
> specification
> -- you could argue about whether the license is valid or not, 
> but that's not the point, and it would preclude us (or any 
> JVM based on GNU
> Classpath) from ever passing the TCK.

Thanks for this. I've learned a lesson. This effectively means that you
can't expect classpath to solve a problem which the JDK didn't solve either
- what a pity. :-( But at least now I have a good excuse to have rolled my
own solution as in the TrueZIP project. :-)

With best regards,
Christian