JDK-6341887 : Inflater.setInput(), Inflater.inflate() can't handle ByteBuffer
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 11
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-10-26
  • Updated: 2019-10-10
  • Resolved: 2018-04-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11 b11Fixed
Related Reports
CSR :  
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
The Inflater class' methods - setInput() and inflate() - take byte arrays, but not ByteBuffers.
They need to take ByteBuffers.

JUSTIFICATION :
The new java.nio.* API is nice and uses ByteBuffers, which I've been told are more efficent, and are definitely easier to work with than getting integers from byte arrays.  Inflater and Deflater should use ByteBuffers to avoid having to convert back and forth when compressing data to send over the internet.
Also, I think this would be an easy fix.  Wrapping doesn't cut it.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Inflater class taking ByteBuffers

int len = sockechannel.read(bytebuffer);
inflater.setInput(bytebuffer, 0 , len);
inflater.inflate(bytebuffer); //if this has to use a seperate ByteBuffer that's fine too

ACTUAL -
Lots of conversions

int len = socketchannel.read(bytebuffer);
byte[] temp = byte[len];
bytebuffer.get(temp);
inflater.setInput(temp,0,len);
byte [] temp2 = byte[len*10];
len = inflater.inflate(temp2);
bytebuffer.put(temp2, 0 , len);


---------- BEGIN SOURCE ----------
 /*
     it really doesn't matter what i put since it would take pages to actually
     connect to the real server.  If you really need this to understand my
     issue, email me and ill send you whatever you need.
 */

import java.util.zip.*;
import java.nio.*;
import java.nio.channels.SocketChannel;
import java.io.IOException;


public class SocketGold extends Thread
{
	ByteBuffer lenBytes;
	SocketChannel socket;
	Inflater compresseur;
	byte[] gonfl��;

	public SocketGold(SocketChannel sc)
	{
		socket = sc;
		lenBytes = ByteBuffer.allocateDirect(2);
		compresseur = new Inflater();
		gonfl�� = new byte[1536];
	}


	//disregard this, it just makes the important code easier for the eyes
	private int read(ByteBuffer buf)
	{
		try {
			return socket.read(buf);
		}
		catch(IOException e) {
			System.exit(1);
		}

		return -1;
	}


	public void run()
	{
		short len;
		int r��sultat=0;
		byte[] temp;
		ByteBuffer tempBuffer;

		while (true) {
			read(lenBytes);
			len = lenBytes.getShort();

			tempBuffer = ByteBuffer.allocateDirect(len);

			//example of good behavior
			read(tempBuffer);

			//i disagree with this method
			temp = new byte[len];
			tempBuffer.get(temp);

			compresseur.setInput(temp,0,len);

			try {
				r��sultat = compresseur.inflate(gonfl��);
			} catch(DataFormatException e) {
				System.exit(1);
			}

			//this is also annoying
			tempBuffer = ByteBuffer.allocateDirect(r��sultat);
			tempBuffer.put(gonfl��,0,r��sultat);
		}

	}
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
I'm using byte arrays.

Comments
EVALUATION ByteBuffer.array() is an optional operation, hence client code attempting to use it would be even more convoluted than that shown in the Description. Submitter's request strongly suggests that client code would want to watch for ReadOnlyBufferException and UnsupportedOperationException being thrown from inflater.setInput and/or inflater.inflate. Contrast this with ByteBuffer.get(), which as per the sample in the Description, will always work (modulo the unlikely event of a BufferUnderflowException). If one of those two exceptions is thrown, then client code can fall back on that shown in the Description. Since that further complicates client code, rather than simplifying it, closing as Not a Defect.
27-10-2005

EVALUATION Why can't simply ByteBuffer.array() be used, allowing a ByteBuffer view for programmer convenience, while satisfying the API? I'm inclined to close as Not A Defect.
27-10-2005