Re: Patches to java.util.zip by Christian Schlichtherle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > http://www.javaworld.com/jw-10-1997/jw-10-sunsuit.html Interesting article, especially this one: "And while Sun can exercise its legal rights over the use of the Java name, it can do little to stop Microsoft from implementing a "clean room" version of the Java virtual machine, says Morgenthal." :) cu Robert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDFk2vG9cfwmwwEtoRAombAJ9UTVX6pPf1WLBog1fBIAOKkUCWrQCfQzGF 4iEmTksWnekMs9YRe8Aug1o= =9i55 -END PGP SIGNATURE- ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Patches to java.util.zip by Christian Schlichtherle
Mark Wielaard wrote: But even then for a core class library implementation being conservative about extensions is a good thing. If you aren't careful you have to support a new way to use the library for years and then you will have to make really sure that it is worth it both for your users and to the developers that need to maintain backwards compatibility with it. I fully agree. I think the J2SE development over the last 10 years offers a strong argument in favour of conservativism. In 1996, the Java 1.0 Nutshell book came at whopping 460 pages, describing the language, and the APIs. In 1995, the Java in Nutshell book is now 1252 pages. And the language has not changed that much, to warrant such a blowup: it largely due to the JCP putting every API within their reach that could not run away fast enough into the J2SE. As a result, countless trees have been decimated for documenting all the backward compatibility cruft. ;) cheers, dalibor topic ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[Bug awt/20782] jawt assertion failure
--- Additional Comments From fitzsim at redhat dot com 2005-08-31 21:57 --- Fixed in GNU Classpath. Closing. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20782 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Patches to java.util.zip by Christian Schlichtherle
Stephen Crawley wrote: > Let us not beat about the bush. It would be bad for everyone (except > Microsoft) > if Java implementors were allowed to modify the APIs of the Java Class > Libraries. If you are a Java(TM) licensee, I think you can modify the APIs through the respective JSRs at the JCP. Sun, IBM, and others do it all the time, afaict. The J2SE growth I see with each version has to come from somewhere :) If you are not a Java(TM) technology licensee, then you can, essentially, do whatever you want, modulo violating other people's rights, of course. > Even if the API changes are upwards compatible (e.g. adding visible > methods, > constructors, fields or classes) the cause trouble. Specifically, if > vendor > XYZ has "enhanced" the APIs, then someone developing an application > using vendor > XYZ's Java platform may well find that their software does not run on other > vendor's Java platform. Yeah, I fully agree. I see that sometimes, myself, too, and find it pretty annoying. Some people are apparently ocassionally developing their programs written in the Java programming language on some closed, proprietary implementation that contains APIs, which enhance the ones in GNU Classpath. So when I try to use their applications on a free runtime, like Kaffe, their applications just don't work. That's why educating developers about the Java Trap is important. > Those with long memories will remember that Microsoft tried this trick. They even went so far as to drop RMI completely. And JNI. http://www.javaworld.com/jw-10-1997/jw-10-sunsuit.html > It was > only the Sun license (and Sun's willingness to take Microsoft to court) > that saved > the Java community from the hell of vendor specific Java "enhancements". I only wish Sun had saved the Java community from com.sun.* and sun.*, tools.jar and similar Sun-specific, non-standarsised nosense, as well. I can't have it all, I guess :) cheers, dalibor topic ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Patches to java.util.zip by Christian Schlichtherle
on Wed, 31 Aug 2005, Christian Schlichtherle wrote:
> More specifically, the size and compressed size field in the ZipEntry
> class
> are causing the problems as some comparisons are happening on these.
> The
> issue is that once a big integer equal or greater than 2*1024^3 and
> smaller
> than 4*1024^3 is stored into a Java int, it is hard to use this int as
> if it
> were unsigned. You would have to do something like this on an int
> (untested):
>
> final static long NUM_FOUR_BYTE_INTS = 256L * 256L * 256L * 256L; //
> Number
> of 4 byte ints
>
> private static long int2long(int i) {
> return i >= 0 ? (long)i : (long)NUM_FOUR_BYTE_INTS - (long)i;
> }
>
> private static void doIt() {
> int ok = 2 * 1024 * 1024 * 1024 - 1; // max signed int
> int tooBig = 3 * 1024 * 1024 * 1024; // Creates a negative
> integer
>
> // Compare ok and tooBig
> assert int2long(ok) < int2long(tooBig) : "This is ok!";
> assert ok < tooBig : "This fails!";
> }
>
> This is way too much computational overhead and it is way too easy to
> forget
> this on a comparison. Thus, the better way to deal with this issue is
> hold 4
> byte signed ints in a Java long if you don't need to care for the
> memory
> overhead.
Well, you could do that. But I find that:
long x = (i & 0xL);
Converts an unsigned int (i) into a signed long (x) correctly just fine.
/Sven
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
StatCVS report updated
I updated the StatCVS report for GNU Classpath: http://www.object-refinery.com/classpath/statcvs/ Regards, Dave ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Patches to java.util.zip by Christian Schlichtherle
Hi Christian, On Wed, 2005-08-31 at 14:05 +0200, Christian Schlichtherle wrote: > 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. In principle there is nothing "wrong" about it. But it isn't really what GNU Classpath is currently focusing on. Creating a Free Software implementation of the core class libraries is already a lot of work. Tracking extensions would currently be additional work that would distract from completion our set of core libraries. It is really better done in separate projects that don't have explicit compatibility as a goal. Your TrueZIP is a nice example of that. There you can do real innovation and create a really great new interface for people to use. For GNU Classpath we are focusing on providing the freedoms people except when using Free Software, better/smaller/faster/smarter implementations, good and complete documentation and creating opportunities for research and integration with other free software platforms (see native compilation in gcj, integration with #c and .net through ikvm, our gtk+ and qt peers for gnome and kde integration, all the research done http://www.gnu.org/software/classpath/stories.html etc). That doesn't mean we aren't looking for innovations, but we are looking for ways to make them as transparent as possible to our users. GNU Classpath should just feel/be better out of the box then other (proprietary) implementations without the user having to explicitly use extensions in their programs. Who knows what happens when we are entering the endgame and GNU Classpath is as complete as the proprietary non-free implementation. But we are not there yet, and that is certainly still one or two years ahead of us. But even then for a core class library implementation being conservative about extensions is a good thing. If you aren't careful you have to support a new way to use the library for years and then you will have to make really sure that it is worth it both for your users and to the developers that need to maintain backwards compatibility with it. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Patches to java.util.zip by Christian Schlichtherle
Jeroen Frijters wrote: Christian Schlichtherle wrote: 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. Let us not beat about the bush. It would be bad for everyone (except Microsoft) if Java implementors were allowed to modify the APIs of the Java Class Libraries. Even if the API changes are upwards compatible (e.g. adding visible methods, constructors, fields or classes) the cause trouble. Specifically, if vendor XYZ has "enhanced" the APIs, then someone developing an application using vendor XYZ's Java platform may well find that their software does not run on other vendor's Java platform. Those with long memories will remember that Microsoft tried this trick. It was only the Sun license (and Sun's willingness to take Microsoft to court) that saved the Java community from the hell of vendor specific Java "enhancements". -- Steve ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[Bug classpath/23653] lib/Makefile is not portable
--- Additional Comments From mark at klomp dot org 2005-08-31 14:12 --- Subject: Re: New: lib/Makefile is not portable > -path is not a portable option for find. Would changing it to -wholename help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23653 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Patches to java.util.zip by Christian Schlichtherle
Christian Schlichtherle wrote: More specifically, the size and compressed size field in the ZipEntry class are causing the problems as some comparisons are happening on these. The issue is that once a big integer equal or greater than 2*1024^3 and smaller than 4*1024^3 is stored into a Java int, it is hard to use this int as if it were unsigned. You would have to do something like this on an int (untested): ... This is way too much computational overhead To compare two unsigned ints just invert their sign bits: I.e. (using C syntax): unsigned int32 i, j; signed int32 is = (signed int32) i; signed int32 js = (signed int32) j; Then (i COMP j) if and only if ((signed int32) (is ^ 0x80) COMP (signed int32) (js & 0x8000)). Which is probably faster than: ((long) (is & 0x) COMP (long) (js & 0x)) -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
[Bug classpath/23652] New: scripts/check_jni_methods.sh is not portable
It appears that scripts/check_jni_methods.sh requires at least GNU diff and GNU grep to run properly: cd /home/eric/cvs/gcc/libjava/classpath && scripts/check_jni_methods.sh diff: illegal option -- 0 usage: diff [-bitw] [-c | -e | -f | -h | -n | -u] file1 file2 diff [-bitw] [-C number | -U number] file1 file2 diff [-bitw] [-D string] file1 file2 diff [-bitw] [-c | -e | -f | -h | -n | -u] [-l] [-r] [-s] [-S name] directory1 directory2 grep: illegal option -- q grep: illegal option -- f Usage: grep -hblcnsviw pattern file . Moreover, it doesn't appear to be run through CONFIG_SHELL. -- Summary: scripts/check_jni_methods.sh is not portable Product: classpath Version: 0.17 Status: UNCONFIRMED Severity: normal Priority: P2 Component: classpath AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org CC: bug-classpath at gnu dot org GCC build triplet: *-*-solaris2.* GCC host triplet: *-*-solaris2.* GCC target triplet: *-*-solaris2.* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23652 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
RE: Patches to java.util.zip by Christian Schlichtherle
Hi everyone,
> Yes, if someone can make a little testcase where we fail now
> and show how we are not properly converting the
> signed/unsigned ints at the moment that would be appreciated.
> Note that at the moment all public methods take and return
> longs already, we only store it as int internally and try
> treat it as unsigned already. It might be that we need to
> internally store everything in an long and not just treat the
> signed ints as unsigned ints as we do now in the code, but
> the patch contained so many unrelated changes that it was
> hard to make out which changes were explicitly for this
> issue. So if someone could extract those parts of the patch
> that would help a lot.
More specifically, the size and compressed size field in the ZipEntry class
are causing the problems as some comparisons are happening on these. The
issue is that once a big integer equal or greater than 2*1024^3 and smaller
than 4*1024^3 is stored into a Java int, it is hard to use this int as if it
were unsigned. You would have to do something like this on an int
(untested):
final static long NUM_FOUR_BYTE_INTS = 256L * 256L * 256L * 256L; // Number
of 4 byte ints
private static long int2long(int i) {
return i >= 0 ? (long)i : (long)NUM_FOUR_BYTE_INTS - (long)i;
}
private static void doIt() {
int ok = 2 * 1024 * 1024 * 1024 - 1; // max signed int
int tooBig = 3 * 1024 * 1024 * 1024; // Creates a negative integer
// Compare ok and tooBig
assert int2long(ok) < int2long(tooBig) : "This is ok!";
assert ok < tooBig : "This fails!";
}
This is way too much computational overhead and it is way too easy to forget
this on a comparison. Thus, the better way to deal with this issue is hold 4
byte signed ints in a Java long if you don't need to care for the memory
overhead.
With best regards,
Christian
smime.p7s
Description: S/MIME cryptographic signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
RE: Patches to java.util.zip by Christian Schlichtherle
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 Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Patches to java.util.zip by Christian Schlichtherle
Christian Schlichtherle wrote: > > 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). 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. > 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. Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Patches to java.util.zip by Christian Schlichtherle
Hi, On Wed, 2005-08-31 at 12:06 +0200, Jeroen Frijters wrote: > Christian Schlichtherle wrote: > > the changes from int to long are required as to the ZIP file format > > specification available online from PKZIP Inc. > > > > The specification says that all integers are 4 byte unsigned integers. > > Java's int type is 4 byte signed, thus the type long is > > required to hold a ZIP file integer. You can find this in other > > popular Java based ZIP file implementations as well (Apache ant, the > > JDK, etc.). > > Thanks for taking the time to explain this. We obviously should take in > these fixes. Yes, if someone can make a little testcase where we fail now and show how we are not properly converting the signed/unsigned ints at the moment that would be appreciated. Note that at the moment all public methods take and return longs already, we only store it as int internally and try treat it as unsigned already. It might be that we need to internally store everything in an long and not just treat the signed ints as unsigned ints as we do now in the code, but the patch contained so many unrelated changes that it was hard to make out which changes were explicitly for this issue. So if someone could extract those parts of the patch that would help a lot. Thanks, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Patches to java.util.zip by Christian Schlichtherle
Christian Schlichtherle wrote: > the changes from int to long are required as to the ZIP file format > specification available online from PKZIP Inc. > > The specification says that all integers are 4 byte unsigned integers. > Java's int type is 4 byte signed, thus the type long is > required to hold a ZIP file integer. You can find this in other > popular Java based ZIP file implementations as well (Apache ant, the > JDK, etc.). Thanks for taking the time to explain this. We obviously should take in these fixes. > Furthermore, the constructors I've introduced are provided to allow an > application developer to have the choice of choosing an encoding: > UTF-8 as with Sun's JDK which is only relevant if you need to exchange > ZIP files with JDK created ZIPs or CP437 to exchange ZIP files created > by the rest of the world (PKZIP, Winzip, infozip, MS Explorer, etc). > In my opinion, the latter is more relevant for real world > internationalized applications. 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. Thanks again. Regards, Jeroen ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: Patches to java.util.zip by Christian Schlichtherle
Hi everyone,
the changes from int to long are required as to the ZIP file format
specification available online from PKZIP Inc.
The specification says that all integers are 4 byte unsigned integers.
Java's int type is 4 byte signed, thus the type long is required to hold a
ZIP file integer. You can find this in other popular Java based ZIP file
implementations as well (Apache ant, the JDK, etc.).
I have introduced this fix because jazzlib 0.07 definitely breaks on ZIP
files larger than 2 GB. With my patches however, jazzlib is compatible to
the ZIP 32 spec which can hold up to 4 GB.
Furthermore, the constructors I've introduced are provided to allow an
application developer to have the choice of choosing an encoding: UTF-8 as
with Sun's JDK which is only relevant if you need to exchange ZIP files with
JDK created ZIPs or CP437 to exchange ZIP files created by the rest of the
world (PKZIP, Winzip, infozip, MS Explorer, etc). In my opinion, the latter
is more relevant for real world internationalized applications.
Removing all these fixes/enhancements make my submitted patches pretty
useless and do not solve important bugs/limitations of jazzlib 0.07.
Anyway, as nothing happened on these topics for almost half a year I've
moved away and rolled my own. The resulting ZIP package is available at
http://truezip.dev.java.net and does much more than just providing classes
which are backwards compatible to JDK's java.util.zip package. It provides
an additional layer of abstraction so that an application can treat a ZIP
file like an ordinary directory using classes which are backwards compatible
to JDK's java.io package. Using this you can create for instance an entry
nested in two ZIP files by simply writing to a new
FileOutputStream("outer.zip/inner.zip/file.txt").
With best regards,
Christian Schlichtherle
---
Schlichtherle IT Services
Wittelsbacher Str. 10a
10707 Berlin
Mobil: 0173 / 27 12 470
mailto:[EMAIL PROTECTED]
http://www.schlichtherle.de
> -Original Message-
> From: Mark Wielaard [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 30, 2005 11:45 PM
> To: John Leuner
> Cc: classpath-patches@gnu.org; Christian Schlichtherle
> Subject: Re: Patches to java.util.zip by Christian Schlichtherle
>
> Hi (moved to classpath-patches)
>
> On Tue, 2005-08-30 at 18:02 +0200, Mark Wielaard wrote:
> > I need to go through the rest of these patches.
> > It would help if they could be rediffed against current CVS
> head and
> > extra functionality would be moved to a new package.
>
> I reviewed the rest but dropped everything that would need
> new constructors. It would be best to rewrite that part so
> that it is an extension for another (gnu) package.
>
> While reviewing the classes I fixed some other small issues
> that I saw in the code. I choose to treat all strings
> explicitly as UTF-8 encoded although CP437 would probably be
> also a defensible choice. I did not use any of your int ->
> long changes in the method signatures since I was not sure
> how and where that was actually needed. If there is a change
> in the zip format could you give a reference to that and
> explain how the patch changes the values that gets written/read?
>
> I committed the following:
>
> 2005-08-30 Mark Wielaard <[EMAIL PROTECTED]>
> Christian Schlichtherle <[EMAIL PROTECTED]>
>
>* java/util/zip/ZipEntry.java (setTime): Use
>Calendar.setTimeInMillis().
>(getTime): First parse extra bytes. Use Calendar.getTimeInMillis().
>(parseExtra): Don't return early to make sure that KNOWN_EXTRA is
>always set.
>* java/util/zip/ZipFile.java (readEntries): Parse name and comment
>as UTF-8 string.
>(close): Check that raf is not null.
>* java/util/zip/ZipInputStream.java (getNextEntry): Set name as
>UTF-8 bytes.
>* java/util/zip/ZipOutputStream.java (setComment): Set comment as
>UTF-8 bytes.
>(putNextEntry): Likewise for name.
>(finish): Likewise for both.
>
> Could you check whether I missed something essential from
> your original patch?
>
> Thanks,
>
> Mark
>
smime.p7s
Description: S/MIME cryptographic signature
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
