Hi everyone, > Unfortunately, we cannot add additional public constructors, > but I would suggest adding a system property to control the > encoding used by our zip implementation. By default we should > be compatible with the JDK, but this would allow applications > and/or users to override the encoding to be compatible with > the rest of the world.
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). For my personal education: What's wrong about adding constructors? The result would still be backward compatible to the JDK source, so I think this would make up a good solution. This is also what people have often requested from Sun if you look at the bug tracker thread on this topic. With best regards, Christian
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
