Picking a right version of PDFNet for my JAVA deployment


I’m using the download for linux 64-bit from your website: http://www.pdftron.com/downloads/PDFNetC64.tar.gz

My goal is to implement this within a stand-alone web application using jetty to provide conversion of pdf files into xps. The implementation seems fairly simple and straight-forward. Going off of the “ConvertTest” sample included in the SDK, I have the following within my conversion method:


PDFDoc doc = new PDFDoc(getPdfLocal());

Convert.toXps(doc, outputFile.getAbsolutePath());


After deploying and starting the Jetty server, the first request results in:

java.lang.UnsatisfiedLinkError: no PDFNetC in java.library.path

All subsequent requests result in:

java.lang.NoClassDefFoundError: Could not initialize class pdftron.PDF.PDFNet

These errors are being thrown from the initialize() method.

Both the PDFNet.jar and libPDFNetC.so are in the lib/include subfolder of my project war.

PDFNetC.dll was not included in the download for 64-bit linux, and I assume that is only needed for a Windows install, but just in case I downloaded the Windows version and copied the PDFNetC.dll and PDFNetC.lib into the lib/include folder as well, but it did not make any difference.

I am able to run the sample by executing RunTest.sh from the ConvertTest and it works satisfactorily.

Not able to get the project to work using a packaged .war file, I extracted the war and attempted to run it unpackaged. I verified that Jetty is being run with the -Djava.library.path= option pointing to the full path of the lib/include folder where both the .jar and .so files reside. This however, did not make any difference. I am still getting the same errors.


There are a couple of reasons why you are getting this problem, both leading to the Java binary not being able to load PDFNetC on runtime:

1. The library path Java sees does not contain libPDFNetC.so. In your case, however, you mentioned that you set the java.library.path to the directory that contains libPDFNetC.so. An alternative way of setting the library path is to install the shared object to the system wide library directory (i.e. /usr/lib or /usr/local/lib) then run the application again.

2. If the previous solution does not work, then it is likely that there is a mistmatch in architectures. If you are running JRE 32-bit mode, then you will need 32-bit PDFNetC. Likewise for 64-bit versions. You can check your JRE version by invoking "java -version". It should either say mixed-mode (32-bit) or 64-bit. Please try using the appropriate PDFNetC to match the reported architecture.

With these information in mind, I would like to clarify a number of things that are relevant to your situation:
a.) PDFNetC.dll will not work on Linux directly. Linux uses ELF format (.so) while Windows uses PE format (.dll). These are two different formats. Therefore, your assumption is correct that PDFNetC.dll is for Windows only.

b.) Can you please verify the architecture of the JRE that your Jetty uses? As mentioned in point #2 above, you may need to use the 32-bit version of PDFNetC. It could be possible that your Jetty uses a different Java binary from the one you used to run the ConvertTest sample. In this case the solution would be to use 32-bit version even though your app runs on 64-bit OS.