Jpedal works perfect.
Conclusion: For single user client pc usage ok - in a multi user server environment better use something else. Ok to use: - in a single user client pc environment - if you use it as it is - if you have a powerful machine and don't care about the waste of memory and the strain on the CPU Use something else: - if you look for a multi user server environment library - if you need to change the source code or fix bugs by yourself - if you depend on the responsible use of resources Details: - Jpedal wastes ressources: Jpedal wastes a lot of memory and CPU due to inefficient programming. To convert a single digit page PDF (<1 MB size) to an image it needs 1,0 - 1,4 GB of memory. Due to its strain on the CPU certain PDFs (2 pages) need over 30 seconds to be converted. This may be acceptable for a single user client pc however not in a multi user server environment where jpedal locks up the whole machine. - Jpedal is hard to bugfix: Jpedal is implemented in that way, that if you need support you will have to contact the author because one has no chance to understand its source code in a limited amount of time. - Jpedal's quality of the code: Spaghetti code, misleading comments ("changed this and that for customer A" or "Customer problem.pdf issue XY "), (buggy) reimplementations of standard java classes, lots of bugs - I did run findbugs and it stopped after over 8000 issues! This is no code you'll want to depend on. You need an example? Just take a look for instance at the handy (2,7K LOC) PdfStreamDecoder.java and enjoy! Looking for junit tests? Nowhere to be found. Finally one thing I have to grant to Mark Stephens: If you close the hood above the chaotic sourcode and ignore the waste of memory and the strain on the CPU - in the end (most of the time) the result is surprisingly ok.