Re: [cp-patches] RFC: [Patch] rewrite of classpath/gnu/java/net/protocol/http/*

[David Daney]

Chris Burdess wrote:
> David Daney wrote:
>
> > As I threatened last week, I made some major changes to the 
> > gnu.java.net.protocol.http package.  ...
> >
> > The current version reads the entire body of a HTTP response in to a 
> > memory buffer (ByteArrayResponseBodyReader) and if user code needs the 
> > content it gets a ByteArrayInputStream wrapped around the buffer.
> >
> > There are several problems with this approach  The main one is that if 
> > the response is larger than one half of the heap limit (a copy of the 
> > data is made so you need space for two copies) You get an 
> > OutOfMemoryError.
>
>
> Indeed. A specialised implementation of both ResponseBodyReader and 
> InputStream that does not make two copies of the byte array would solve 
> that problem.
>
> > And related is that if the response is larger than Integer.MAX_VALUE 
> > you run into the java language limit on array sizes.
>
>
> True, however most current machines will run out of memory before that 
> happens. As I said before, if you want to stream arbitrarily large 
> entities over HTTP you would be advised to use an API specialised for 
> the purpose (namely HTTPConnection and ResponseBodyReader).
>
> > Here is an outline of what I did:
> >
> > ... I did not bother to check or investigate.  ...
> > ... More testing is probably needed.
> >
> > Comments?
>
>
> You would probably have a better chance if you threw out all the inetlib 
> classes and started from scratch with a pull-based client.

What are you talking about?  I am not using inetlib.  My client uses the 
standard java.net API as published by Sun.

Let me ask you a couple of questions:

1) What do you think the purpose of Classpath is?

2) Do you think the GNU coding standards (especially sections 3.2 and 
4.1) have any relevance with respect to Classpath?


These are my answers:

Classpath's purpose is to provide a free replacement for the standard 
java runtime libraries.

I do agree with sections 3.2 and 4.1 of the GNU coding standards.  I do 
think that Classpath *should* be compatible with the reference 
implementation (Sun's).  I do think that Classpath *should* be robust. 
It *should* "Avoid arbitrary limits ...". To do otherwise "... is not 
acceptable in a GNU utility."

Your responses above just don't make sense to me.  You seem to be saying 
that because the current implementation of Classpath's HTTP code is 
architecturally limited, I should come up with some private 
re-implementation of the standard java runtime so that ... I don't know 
what.

When I asked for Comments I really meant about my patch.  Not whether or 
not I should be using the standard java runtime.

David Daney