OpenPDF
OpenPDF copied to clipboard
LibrePDF
Maintain Java 7 branch
A Java 7 branch of OpenPDF has been requested multiple times, so it is something some users want. Such a Java 7 branch has been maintained in the past. However, I deleted the old Java 7 branch because of the workload required to maintain it.
I have now created a new Java 7 branch. Pull-requests welcome.
I suggest you try one of these two releases of OpenPDF for Java 7 support: https://github.com/LibrePDF/OpenPDF/releases/tag/1.2.3.java7 https://github.com/LibrePDF/OpenPDF/releases/tag/1.0.5
I'm just taking a look at the java7 branch. I merged master into it (only locally), and changed the pom so java 1.7 is really used (not only in travis). There are many issues here, because streams, optionals and lambdas are being used. I'm not sure how easy it will be to port this things back to java7.
I would appreciate, if the Java7 branch could be maintained. Bound to an old IDE, I have to work on WinXP and Java 7 is the last release that installs on XP. And maybe there is more need for a Java7 release of openPDF ...
I manage to convert all production code to Java7: no streams, no lambdas, no functionalInterfaces, and no use of classes, which are not present in JDK 7. But now, going to the tests I have a dilemma: JUnit5 requires JDK 8? what do? Any Suggestions?
But now, going to the tests I have a dilemma: JUnit5 requires JDK 8? what do?
There must be possibility to compile tests with different JDK version, but running tests with different Java version is probably related to CI, I'm not sure about that. Or project can be switched back to JUnit 4 ofc)
I think I have the solution: It must be compilable on JDK7, but the build and test can be done with JDK8, so the Tests will run. I'm still not ready, as there are some Optionals in the code, I didn't get using jdk8 locally.
I manage to convert all production code to Java7: no streams, no lambdas, no functionalInterfaces, and no use of classes, which are not present in JDK 7. But now, going to the tests I have a dilemma: JUnit5 requires JDK 8? what do? Any Suggestions?
It's actually unreasonable to downgrade Java version. We can't satisfy all possible user needs. If I create issue that I need to use library with Java 4 - this does not mean that we will remove all annotations from code.
I would appreciate, if the Java7 branch could be maintained.
@arnthom What do you mean under "maintained"? AFAIK there's already Java 7 compatibility branch. Does it suit your particular needs? I do not want to limit someone in usage of OpenPDF, but switching to older release will slow down development and possible involvement of new developers - without even saying that maintaining two Java releases requires a lot of efforts. Hope you understand what I mean
There is indeed "openPdf 1.2.3 Java 7". I managed to use this instead of 1.3.11. It would be nice, if this branch could profit from bugfixes and maybe some enhancement in the main branch. An example: In the Java7 branch you won't find HorizontalAlignment and VerticalAlignment. I use them quite often, so I had to add these classes to my project ...
Hi @arnthom , can you try the new branch, after the last merge from master? You need to build it yourself.
Hi @asturio! Now I started a new Maven project in Eclipse (openpdf, pdf-swing, pff-toolbpx), but (since it is my first encounter with Maven) I do not know how to build. Can you give a hint how do do this? Thanks a lot!
Hi @arnthom , just to in to the project directory and type "mvn package". You will find the jar in openpdf/target. If your project uses maven, you can also install openpdf with "mvn install", and your project should find the jar if you put the right dependency there. HTH
Hello,
first let me thank you a lot for setting up a Java 7 branch for OpenPDF. I am currently working on a project that is still on Java 7 but requires automatic PDF formular population. I first tried out 1.2.3.java7 but had some dependency issues that I could not resolve due to the other given dependencies in the project. 1.0.5 seemed to work at first as it let me compile but now I get an error connected to bouncycastle when trying to start the tomcat server:
Caused by: java.lang.SecurityException: class "org.bouncycastle.jce.provider.JCEECPrivateKey"'s signer information does not match signer information of other classes in the same package
As far as I understand the documentation, bouncycastle is only required for encryption which I do not need and did not implement. I also tried adding the compile dependencies of 1.0.5 to bouncycastle to my dependencies but this is of course rejected by Maven as these dependencies are unused.
Do you guys have an idea what the underlying issue could be? Or is 1.0.5 in a state where this behavior is to be expected as it is not refined yet?
Best regards, Jonas
java.lang.SecurityException: class "org.bouncycastle.jce.provider.JCEECPrivateKey"'s signer information does not match signer information of other classes in the same package
Such an exception usually means that multiple jars in your classpath contain the same package (here org.bouncycastle.jce.provider) and that classes in that package from both jars in use.
This in turn most often means that you have multiple versions of the same library in your class path.
Thus, please check your classpath (also endorsed and similar in-JRE paths) for conflicting BouncyCastle versions.
Hello @mkl-public ,
thank you a lot for your explanation. I checked and we do indeed have an older bouncycastle version on the class path coming from an existing dependency that does not allow us to upgrade to the bouncycastle version required by the openpdf Java 7 branches.
Hi: I need a version of openpdf that is java7 compatible and supports QR code generation and QR code printing.
Does this version support it?
Best.
I think, there is nobody wanting to maintain the Java 7 Branch anymore. Moreover I think there should be now some improvements because of all the latest LTS Versions of Java. So it is more important to focus on Java 8, 11, 17 and 21 compatibility.