Re: java.util.zip Limitations
From: Chris Uppal (chris.uppal_at_metagnostic.REMOVE-THIS.org)
Date: 05/25/04
- Next message: Fong: "Program cannot recognize asterisk(*) as an argument passed from the command line?"
- Previous message: Chris Uppal: "Re: Java Interview Questions: Am I Being Too Difficult?"
- In reply to: Joseph Dionne: "Re: java.util.zip Limitations"
- Next in thread: Michael Borgwardt: "Re: java.util.zip Limitations"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 25 May 2004 10:53:18 +0100
Joseph Dionne wrote:
> Sorry my response is so delayed, I've been heads down in project without
> time to play. At times the theoretical must make room for the practical.
It's Good to eat...
> All your points are well taking, and in keeping with OOP and Java
> principles. Perhaps this is where my issue derives -- I have
> fundamental disagreements with OOP and the direction Java is taking. As
> a c language programmer from K&R forward, I love the simplicity of that
> language, believing less is more.
I agree that Java is over-complex, but I suspect that we are thinking of
different things...
> With Java, the "API" is so large, and growing, it is approaching the
> point where effective use will be diminished because of its immense
> size.
Yes, we are. The class library is only an application of Java -- albeit one
that is standardised. I prefer to keep the concepts of the language and the
library separate.
The API is huge, and growing. It has some nasty kludges due to early design
flaws. But I don't see how to avoid that and still have a lot of pre-packaged
functionality. It's nothing to do with OO really, just the shear number of
application domains that Sun have added to the mix.
Perhaps it'd be better if there were a clearer separation between a small
"core" library that could be thought of as part of the Java language (akin to
the C standard library), and a much larger set of code that is only part of the
Java "platform".
> > As far as I can
> > see, the current low-level APIs are just about sufficient to allow Sun
> > to create a higher level one on top of them[*].
>
> The functionality I added in myZipFile class, using InputStream and
> ZipStream, have the ability to 1) differentiate between an invalid zip
> file, for example myZipFile.java, and one such as the OPs zip file
> missing the TOC, and 2) simulate the functionality of ZipFile, less
> direct access of course (which I intend to add in the future). The
> replacement is functional, and demonstrates my point that the native
> method ZipFile.open() could do the same, thus making ZipFile more
> useful, not less. (Look mom, no utilities!)
Well, you can look at this in another way, and say that the fact that you have
done this shows that it's not necessary to package this functionality as part
of the /standard/ class library. (Which, after all, we have just agreed is
dauntingly big).
> It remains my opinion that as a "user" of the Java language, I have the
> right to "demand" reasonable behavior from the language developers, just
> like my customers/users demand reasonable behavior from my work.
I very much agree with this in general. There is a specific point though: in
my experience, users tend to want solutions that are "too" simple -- that is
the solution they ask for (first) is actually simpler than the task itself,
which means that they wouldn't always be able to do their work with it. Part
of our job as designers/programmers is to ensure that we know /all/ the
/necessary/ complexities of their task, and ensure that we don't forget that
the users will have to deal with "odd" cases, even though the users themselves
tend to do so.
I'm of the opinion that there's a similar "pressure" from consumers of a class
library for X, for it to be simplified to reflect the limited concept of X that
is most common. It's the job of the class library designer to ensure that the
process of dropping/hiding "inconvenient" aspects of X doesn't go too far.
Of course, it's a matter of opinion whether Sun's Zip library has gone too far
in the opposite direction. I think you've made a fair case that it has. (But,
I don't agree so strongly that I've changed the API of my own Zip library to
include the features you are seeking ;-)
-- chris
- Next message: Fong: "Program cannot recognize asterisk(*) as an argument passed from the command line?"
- Previous message: Chris Uppal: "Re: Java Interview Questions: Am I Being Too Difficult?"
- In reply to: Joseph Dionne: "Re: java.util.zip Limitations"
- Next in thread: Michael Borgwardt: "Re: java.util.zip Limitations"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
