RFD: Should java.util.zip.[In|De]flater.getTotal[In|Out] be deprecated?

[Alan Bateman]

On 16/02/2024 19:20, Eirik Bjørsnøs wrote:
> Hi,
>
> Initially, the Deflater and Inflater classes in java.util.zip only 
> supported up to 2GB of inflated or deflated data, the reason being 
> that their getTotalIn and getTotalOut methods returns an int.
>
> Around 2004, this limitation was remedied by introducing the new 
> methods getBytesRead and getBytesWritten returning long. The legacy 
> methods getTotalIn and getTotalOut were updated to simply delegate to 
> the new method with an added cast to int.
>
> The legacy methods include notes in their Javadoc similar to this:
>
>        * <p>Since the number of bytes may be greater than
>          * Integer.MAX_VALUE, the {@link #getBytesRead()} method is now
>          * the preferred means of obtaining this information.</p>
>
>
> but these methods are not marked as @Deprecated in Javadoc or with 
> annotations.
>
> Is there any good reason why these four methods have not been 
> officially deprecated in the past? If not, would it be worthwhile 
> doing so now?
>

Good question. I'm surprised the spec for these methods wasn't clarified 
in Java 5 when the new methods to return long were added. Right not, 
it's not clear from the spec how the older methods behave when the 
number of bytes is greater than Integer.MAX_VALUE. Long standing 
behavior is to cast to int so they will return a negative value once the 
total in/out exceeds Integer.MAX_VALUE.  Methods such as 
URLConnection::getContentLength are clamped so they return 
Integer.MAX_VALUE when the content length is larger than that. Both 
behaviors are a hazard but arguably the Inflater/Delater behavior is 
worse. So I think there is good case for deprecating the old methods.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240217/7767f3a6/attachment-0001.htm>