Java Network InputStream markSupported()

I’m using Aspose behind a Jersey REST Web Service.

I’m having problems with com.aspose.words.FileFormatUtil.detectFileFormat(InputStream). This works but when I then pass the InputStream to com.aspose.words.Document(InputStream) and call com.aspose.words.Document.save(OutputStream, SaveFormat). I get an empty pdf created.

If I leave out the call to detectFileFormat then save part works. It’s only when I call detectFileFormat then save that I get empty pdf documents.

Since Java 1.5 (2005), so over a decade ago https://docs.oracle.com/javase/1.5.0/docs/api/java/io/InputStream.html.

It has three methods markSupported(), reset() and mark(marklimit). The idea is before using the InputStream you say how many bytes your about to read, then when you call reset() the pointer in the stream returns to where you marked. Any chance your able to update your code as this might be a critical issue to use to use Aspose.

I’ve adapted your java example https://github.com/aspose-words/Aspose.Words-for-Java

Specifically the CheckFormat.java https://github.com/aspose-words/Aspose.Words-for-Java

I updated this so detectFileFormat(InputStream) is used.
I also updated it so it saves a pdf instead of simply copying files.

It does 3 types of save, 2 work and 1 fails. The one that fail is key for the code i’m writing as I don’t want to create server side temp files.

Fails using the same InputStream that detectFileFormat used for new Document(InputStream).
Works create new InputStream from File for new Document(InputStream).
Works pass file location into new Document(String).

Any chance your able to confirm this is a defect and if their are any work around available.

Hi John,

Thanks for your inquiry. Please upgrade to the latest version of Aspose.Words for Java 15.12.0 and see how it goes on your end. Hope, this helps.

In case the problem still remains, please attach your input Word document you’re getting this problem with here for testing. We will investigate the issue on our end and provide you more information.

Best regards,

I’ve tried with 15.8.0, 15.9.0, 15.10.0, 15.11.0 and just a second ago with 15.12.0.

All version have the same issue.

The word document used appears to be irrelevant. I was using documents provided by aspose.

Here is the link to the aspose docs I was testing with;

https://github.com/aspose-words/Aspose.Words-for-Java

Hi John,

Thanks for your inquiry. After an initial test with Aspose.Words for Java 15.12.0 and your code, I was unable to reproduce this issue on my side. Could you please simplify your code to a few lines, try executing this simplified code in a standalone Java application in your local environment (document should also be on your local system without requiring network access) and see how it goes. Please let me know if I can be of any further assistance.

Best regards,

Hi Awais,

Just to confirm you tried to create 3 pdf files, and all 3 files where created successfully. Could you please attach your working version so I can confim, that it works and also is testing the right thing.

As per my original example I’ve attached a simpler version for you. It is standalone, using local system and fails as I’ve previous explained.

Version 1 fails, version 2 & 3 work correctly.

  1. new Document(existing input stream that FileFormatUtil.detectFileFormat(input stream) had previous used)
  2. new Document(new FileInputStream(string to source file))
  3. new Document(string to source file)

Hi John,

Thanks for the additional information. We tested the scenario further and have managed to reproduce the same problem on our end. For the sake of correction, We have logged this problem in our issue tracking system as WORDSJAVA-1270. Our product team will further look into the details of this problem and will keep you updated on the status of correction. We apologize for your inconvenience.

Best regards,

How quickly should I expect an update or an expected fix? days, weeks, months?

Hi john.patrick3

We are glad you are interested in Aspose.Words for Java.

You are right there are methods mark(), reset() and markSupported but FileInputStream doesn’t support mark/reset method. Please have a look at JDK’s source.

There are a few solutions which can help you to achieve the goal

  1. Wrap FileInputStream into BufferedInputStream (e.g. new BufferedStream(myFileInputStream))
  2. Use PushbackInputStream
  3. Or use FileChannels

Let us know if it helped.

Slava.

Hi Slava,

Before suggesting these solutions did you try them yourself???

  1. doesn’t work see attachment CheckFormatThenCreatePdfUsingBufferedInputStream.java.txt
    same issue where a corrupt file of few bytes is being created.

  2. markSupported returns false, and also produces the same issue. see attachment CheckFormatThenCreatePdfUsingPushbackInputStream.java.txt

  3. I’m trying to not use File, so have not tried this as it’s just a different wrapper to a File. I’m trying to just use InputStream’s so no local/temporary files are created/used/required.

does the code within FileFormatUtil.detectFileFormat(InputStream) definetly check markSupported() then do a mark(int) and a subsequent reset() prior to returning?

Hi John,

Please note that FileFormatUtil.detectFileFormat() method has a JavaDoc that informs: “When this method returns, the stream is positioned at the end of the document.”

As a result, if you try to use your InputStream as is just after detectFileFormat() – you will get zero-length document from zero-length stream.

Decade ago we used markSupported()/mark(marklimit)/reset() methods from InputStream contract to rewind the stream as you suggest now. But this caused a number of tangled bugs on user side. Most bugs caused by bad/inaccurate implementation of InputStream contract: reset() sets position to some early (or even arbitrary!) mark, markSupported() returns true but mark(marklimit)/reset() do not work, etc.

So we decide that user can better control his streams. Moreover, you are the first (and the single for 10 yars) who ask to return support of mark()/reset().

Sorry, I just closed your issue as not a bug. Please insert InputStream.mark(marklimit) before call to our FileFormatUtil.detectFileFormat() and InputStream.reset() after the call - all should work. Sorry for inconvenience.

Best regards,