Need some advice: Zip/Jar/Ear/War API backwards incompatibilities

[Stefan Bodewig <bo...@apache.org>]

Hi all,

it seems impossible to get bug 10755 fixed without modifying the
signature of at least isUpToDate in Zip.java in a way that would
keep subclasses working without modification.

The old signature has been

    boolean isUpToDate(FileScanner[] scanners, File zipFile) 

and right now it is

    boolean isUpToDate(ResourceScanner[] scanners, FileSet[] fss, File zipFile)

ResourceScanner is an extension of FileScanner that we need to handle
ZipEntry-s and Files in a uniform way.  If we merged the additional
methods from ResourceScanner into FileScanner, things will get even
worse as we'd now not only break API compatibility for a protected
method, but for a complete interface (that is implemented and not yet
touched in the ftp task for example).

The FileSet argument is necessary as the scanners themselves don't
know about fullpath or prefix attributes that have to be taken into
account when checking the existing archive for up-to-date-ness.

I see no way to get around this.  We could invoke the old method from
the new one, but not the other way around, i.e. all subclasses
invoking the old method signature won't get what they think they'll
get.

Which leads me to think that we should go even further, drop the
ResourceScanner argument (they can be derived from the FileSets) and
even replace the method by one that returns the resources that are
newer than the archive instead of just saying the archive was out of
date.

This would then lead to changed signatures in the various addFiles
methods as well, but ultimately result in code that may be easier to
detangle.  Without changing the signature of the add methods, we'd
either have to perform the "which resources are newer" check twice or
cache the results in instance variables (and rely on subclasses to
delegate to our protected methods).

Quite a big change for a minor release.

To make things worse, 1.6 is going to break the API once again, this
time the zipFile and zipDir methods are problematic as they now have
additional arguments for the (Unix) permissions.  This time subclasses
trying to override Zip's methods get into problems.

So what are we going to do?

Break the API twice with the next two releases?  Delay the fix for 1.6
and break the API then?  Merge the new permissions stuff into 1.5.2
and break the API there?

Stefan

Re: Need some advice: Zip/Jar/Ear/War API backwards incompatibilities

[Stefan Bodewig <bo...@apache.org>]

On Wed, 05 Feb 2003, Conor MacNeill <co...@cortexebusiness.com.au>
wrote:

> This is just my quickfire reaction based on the assumption that a
> break is required.

I don't see any reasonable other way.

I'll continue work in HEAD and we can talk about merging after that,
but I wanted to get some feedback so that I know how much merging
impact I'll be looking for 8-)

Thanks

Stefan

Re: Need some advice: Zip/Jar/Ear/War API backwards incompatibilities

[Conor MacNeill <co...@cortexebusiness.com.au>]

Stefan Bodewig wrote:
> Hi all,
> 
> So what are we going to do?
> 
> Break the API twice with the next two releases?  Delay the fix for 1.6
> and break the API then?  Merge the new permissions stuff into 1.5.2
> and break the API there?
> 

I haven't studied the recent changes and implications in detail. This is 
just my quickfire reaction based on the assumption that a break is required.

IMHO, if a break is required, there should be just one.  Therefore I would 
bring the new permission stuff into 1.5.2. I don't want to delay fixing this 
issue to 1.6.

Conor