You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Sean C. Sullivan" <se...@seansullivan.com> on 2002/02/10 08:48:12 UTC
[httpclient] question regarding HttpMethod interface: getResponseBody method
jakarta-commons httpclient inquiry:
Currently, HttpMethod.java (an interface) defines a
method called "getResponseBody":
/**
* Return my response body, if any,
* as a byte array.
* Otherwise return <tt>null</tt>.
*/
public byte[] getResponseBody();
I would prefer if this method returns a zero-length array instead
of null.
Returning a zero-length array is one of the API design tips that
is recommended in Josh Bloch's book:
Effective Java Programming Language Guide
http://www.amazon.com/exec/obidos/ASIN/0201310058/
==> Item 27: Return zero-length arrays, not nulls
Regards,
-Sean
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] patch for GetMethod.java, recycle() method in GetMethod class
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
> jakarta-commons httpclient inquiry + patch:
>
>The HttpMethod interface declares a method called
>recycle():
>
>----------------
>
> /**
> * Recycle this method so that it can be used again.
> * Note that all of my instance variables will be reset
> * once this method has been called.
> */
> public void recycle();
>
>----------------
>
>The GetMethod class implements the HttpMethod interface
>and the recycle method:
>
>#################
>
> // override recycle to reset redirects default
> public void recycle() {
> super.recycle();
> setFollowRedirects(true);
> }
>
>################
>
>
>GetMethod.recycle() does not reset its instance variables properly.
>
>I am attaching a patch for GetMethod.java (patch file: GetMethod.patch)
>
>Cheers,
>
>-Sean
>
Applied....
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] patch for GetMethod.java, recycle() method in GetMethod class
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
jakarta-commons httpclient inquiry + patch:
The HttpMethod interface declares a method called
recycle():
----------------
/**
* Recycle this method so that it can be used again.
* Note that all of my instance variables will be reset
* once this method has been called.
*/
public void recycle();
----------------
The GetMethod class implements the HttpMethod interface
and the recycle method:
#################
// override recycle to reset redirects default
public void recycle() {
super.recycle();
setFollowRedirects(true);
}
################
GetMethod.recycle() does not reset its instance variables properly.
I am attaching a patch for GetMethod.java (patch file: GetMethod.patch)
Cheers,
-Sean
Re: [httpclient] question regarding HttpMethod interface: getResponseBody method
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>From: "dIon Gillard" <di...@multitask.com.au>
>
>
>>Sean C. Sullivan wrote:
>>
>>>Currently, HttpMethod.java (an interface) defines a
>>>method called "getResponseBody":
>>>
>>> /**
>>> * Return my response body, if any,
>>> * as a byte array.
>>> * Otherwise return <tt>null</tt>.
>>> */
>>> public byte[] getResponseBody();
>>>
>>>
>>>I would prefer if this method returns a zero-length array instead
>>>of null.
>>>
>>>Returning a zero-length array is one of the API design tips that
>>>is recommended in Josh Bloch's book:
>>>
>>> Effective Java Programming Language Guide
>>> http://www.amazon.com/exec/obidos/ASIN/0201310058/
>>>
>>>
>>>==> Item 27: Return zero-length arrays, not nulls
>>>
>>given I don't have the book handy, this doesn't make for a very
>>convincing argument as to why we should change the API. [...]
>>
>>Can you please provide some more info on why you'd like the change?
>>
>
>First, I want the behavior of getResponseBody to be consistent with
>the behavior of other "standard" (java.*) classes.
>
>Example 1: java.util.Vector.toArray
>
> The return value, Object[], will never be null.
>
>Example 2: java.lang.String.getBytes
>
> The return value, byte[], will never be null.
>
>In Josh Bloch's book, "Effective Java Programming Language Guide",
>Item 27 states:
>
> Return zero-length arrays, not nulls
>
>Rationale:
>
>If the method sometimes returns null and other times returns a non-null array,
>the programmer is forced to always check for null.
>
>With the current HttpMethod interface, programmers must write:
>
> byte[] result = hm.getResponseBody();
> if (result != null)
> {
> processBody(result);
> }
>
>If we return a zero-length array instead of null, programmers can write:
>
> byte[] result = hm.getResponseBody();
> processBody(result);
>
>>As well, the current api documents returning null. Which is cheaper from the
>>
>JVM
>
>>perspective than creating a new byte array.
>>
>
>Bloch (page 134) writes:
>
> "It is sometimes argued that a null return value is preferable to a
>zero-length
> array because it avoids the expense of allocating the array. This argument
>fails
> on two counts. First, it is inadvisable to worry about performance at this
>level
> unless profiling has shown that the method in question is a real contributor
>to
> performance problems. Second, it is possible to return the same zero-length
> array from every invocation that returns no items because zero-length arrays
> are immutable and immutable objects may be shared freely."
>
>Solution: declare a static zero-length array variable
>
> private final static byte[] ZERO_LENGTH_BYTE_ARRAY = new byte[0];
>
>Regards,
>
This assumes that there is no difference between null (no response body
exists) vs a returned response of length 0. I'm not sure this is the
case and I think we do need to differentiate between the two.
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] question regarding HttpMethod interface: getResponseBody method
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
From: "dIon Gillard" <di...@multitask.com.au>
>
> Sean C. Sullivan wrote:
>
> >Currently, HttpMethod.java (an interface) defines a
> >method called "getResponseBody":
> >
> > /**
> > * Return my response body, if any,
> > * as a byte array.
> > * Otherwise return <tt>null</tt>.
> > */
> > public byte[] getResponseBody();
> >
> >
> >I would prefer if this method returns a zero-length array instead
> >of null.
> >
> >Returning a zero-length array is one of the API design tips that
> >is recommended in Josh Bloch's book:
> >
> > Effective Java Programming Language Guide
> > http://www.amazon.com/exec/obidos/ASIN/0201310058/
> >
> >
> >==> Item 27: Return zero-length arrays, not nulls
> >
>
> given I don't have the book handy, this doesn't make for a very
> convincing argument as to why we should change the API. [...]
>
> Can you please provide some more info on why you'd like the change?
>
First, I want the behavior of getResponseBody to be consistent with
the behavior of other "standard" (java.*) classes.
Example 1: java.util.Vector.toArray
The return value, Object[], will never be null.
Example 2: java.lang.String.getBytes
The return value, byte[], will never be null.
In Josh Bloch's book, "Effective Java Programming Language Guide",
Item 27 states:
Return zero-length arrays, not nulls
Rationale:
If the method sometimes returns null and other times returns a non-null array,
the programmer is forced to always check for null.
With the current HttpMethod interface, programmers must write:
byte[] result = hm.getResponseBody();
if (result != null)
{
processBody(result);
}
If we return a zero-length array instead of null, programmers can write:
byte[] result = hm.getResponseBody();
processBody(result);
> As well, the current api documents returning null. Which is cheaper from the
JVM
> perspective than creating a new byte array.
Bloch (page 134) writes:
"It is sometimes argued that a null return value is preferable to a
zero-length
array because it avoids the expense of allocating the array. This argument
fails
on two counts. First, it is inadvisable to worry about performance at this
level
unless profiling has shown that the method in question is a real contributor
to
performance problems. Second, it is possible to return the same zero-length
array from every invocation that returns no items because zero-length arrays
are immutable and immutable objects may be shared freely."
Solution: declare a static zero-length array variable
private final static byte[] ZERO_LENGTH_BYTE_ARRAY = new byte[0];
Regards,
-Sean
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] question regarding HttpMethod interface: getResponseBody method
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>jakarta-commons httpclient inquiry:
>
>
>Currently, HttpMethod.java (an interface) defines a
>method called "getResponseBody":
>
> /**
> * Return my response body, if any,
> * as a byte array.
> * Otherwise return <tt>null</tt>.
> */
> public byte[] getResponseBody();
>
>
>I would prefer if this method returns a zero-length array instead
>of null.
>
>Returning a zero-length array is one of the API design tips that
>is recommended in Josh Bloch's book:
>
> Effective Java Programming Language Guide
> http://www.amazon.com/exec/obidos/ASIN/0201310058/
>
>
>==> Item 27: Return zero-length arrays, not nulls
>
Hi Sean,
given I don't have the book handy, this doesn't make for a very
convincing argument as to why we should change the API. As well, the
current api documents returning null. Which is cheaper from the JVM
perspective than creating a new byte array.
Can you please provide some more info on why you'd like the change?
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [httpclient] minimum supported JDK version
Posted by dIon Gillard <di...@multitask.com.au>.
Sean C. Sullivan wrote:
>What is the minimum supported JDK version for
>the HttpClient class library?
>
From status.html, JDK 1.2 for run time, although the 'external'
interface is 1.1 compliant.
>
>
>Will HttpClient run on JDK 1.1.x?
>
Not sure. I'm certain it won't compile on it. Use of List etc...
>
>
>Is the intent to avoid using any JDK 1.2.x features
>so that the library will run on JDK 1.1.x?
>
Not AFAIK.
>I have some changes that I'd like to make to HttpClient.
>My changes assume that JDK 1.2.x is the minimum JDK environment.
>
>Please advise.
>
>Regards,
>
>-Sean
>
Could you also try to include some more info with your patches on
why/what is being patched. It's hard sometimes to have to read the patch
and work out what's being changed, rather than a short blurb in the
patch posting itself.
--
dIon Gillard, Multitask Consulting
http://www.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[httpclient] minimum supported JDK version
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
What is the minimum supported JDK version for
the HttpClient class library?
Will HttpClient run on JDK 1.1.x?
Is the intent to avoid using any JDK 1.2.x features
so that the library will run on JDK 1.1.x?
I have some changes that I'd like to make to HttpClient.
My changes assume that JDK 1.2.x is the minimum JDK environment.
Please advise.
Regards,
-Sean
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>