Java FileInputStream limited to 65535 bytes

I have a program that is opening a fileInputStream, reading it and writing it to an outputstream.

I'm using AIX.

When I run from terminal, I have no issues. However, when my third party application runs it, it encounters an issue where the FileInputStream only reads the first 65535 bytes from the file and then the next call to the .read() function returns -1, even though the file is slightly bigger than 65535 bytes (it's 68372 bytes). This results in a truncated output file.

My question is, what can cause this limitation? It doesn't appear to be an intrinsic limit of FileInputStream. I suspect there is a java option being set somewhere but I can't for the life of me determine where. Could this be an OS limitation somehow?

Here's my basic code:

OutputStream lOut = new FileOutputStream("/home/fileOut.txt");
FileInputStream fIn = new FileInputStream(new File("/home/fileIn.txt"));
int ch;
byte[] buf = new byte[65536];

while((ch = fIn.read(buf)) > 0)
{
    lOut.write(buf);
}

fIn.close();
lOut.close();

Solution

Leaving aside that your test code is broken; see @EJP's comments. (Yes. He >>is<< correct. Trust me / him.)

My question is, what can cause this limitation?

AFAIK, there is no such limitation.

It doesn't appear to be an intrinsic limit of FileInputStream.

There isn't one.

I suspect there is a java option being set somewhere but I can't for the life of me determine where.

There is no JVM option that would cause this behavior¹.

Could this be an OS limitation somehow?

In theory yes. Or it could be a bug / limitation in the file system drivers, a "resource limit" (see "man ulimit") or a storage media error. In practice, all of these explanations are unlikely. But you could confirm this the problem by trying to read ... or copy ... the same file using an OS utility that is known to work.

Actually, I suspect that the real problem is a bug in the third-party application² you are trying to using. It could be a similar bug to the bug in your test code, or something else.

^{1 - A slight overstatement. If the 3rd-party app did something really stupid (i.e. catching and squashing Throwable), then setting the heap size too small could in theory "cause" this behavior. If you ever encounter a problem like that, change vendors as soon as you can!}

^{2 - Just to be clear, a "third party application" is an application written & supplied by a third party. You / your organization are the first party, your JVM vendor is the second party ...}