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

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

Hi Mark,

thanks for shedding some light on this! :-)

OK, at least my patches should help you to get rid of the obvious bugs (2GB
limitation, date/time conversion and probably others I've forgot about).

The more advanced enhancements like variable code pages and the
treat-ZIP-files-just-like-directories-features are reserved for my TrueZIP
package then. ;-)

With best regards,
Christian Schlichtherle
---
Schlichtherle IT Services
Wittelsbacher Str. 10a
10707 Berlin
 
Mobil: 0173 / 27 12 470
mailto:chr...@sc...
http://www.schlichtherle.de
 

> -----Original Message-----
> From: Mark Wielaard [mailto:ma...@kl...] 
> Sent: Wednesday, August 31, 2005 5:18 PM
> To: Christian Schlichtherle
> Cc: 'Jeroen Frijters'; 'John Leuner'; cla...@gn...
> Subject: 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
>