Switch PDF dependency from iText to OpenPDF

[andreasrosdal]

Switch PDF dependency from iText to OpenPDF. (Reopening #780.)

https://github.com/librepdf/openpdf

[mpe85]

Are there any plans to migrate to OpenPDF?
JavaMelody isn't compatible with the latest OpenPDF version 1.3.x:

java.lang.ClassCastException: class java.lang.String cannot be cast to class com.lowagie.text.Element (java.lang.String is in module java.base of loader 'bootstrap'; com.lowagie.text.Element is in unnamed module of loader 'app')
	at com.lowagie.text.Phrase.add(Phrase.java:86)
	at net.bull.javamelody.internal.web.pdf.PdfJavaInformationsReport.writeDetails(PdfJavaInformationsReport.java:164)

The cause in this particular case is that the method Phrase::add(Object) was refactored into two overloaded methods Phrase::add(String) and Phrase::add(Element).

[andreasrosdal]

@mpe85 There is an API change in the new OpenPDF. However, maybe upgrading isn't so much work, it could be just to change a few variable definitions from Object to the new and more logical object type. It's part of the modernization efforts in OpenPDF. This should benefit javamelody also.

[mpe85]

I just saw that javamelody also uses itext-rtf which is not present anymore in openpdf 1.3. So the upgrade is not trivial I guess.

[andreasrosdal]

I just saw that javamelody also uses itext-rtf which is not present anymore in openpdf 1.3. So the upgrade is not trivial I guess.

I propose that Javamelody removes support for RTF, since it is an ancient format. RTF support was removed from OpenPDF, so that OpenPDF could focus on being good at editing and creating PDF files.

Then Javamelody can upgrade to OpenPDF, and get a maintained library to export PDF files with.

[mpe85]

@andreasrosdal I second that emotion
@evernat What's your opinion about this?

[evernat]

itext-rtf is used only in an almost obsolete part of javamelody (in the javamelody-swing module for the "Desktop" link in the monitoring report, to launch a Swing UI using JavaWebStart for those who have not forgotten about it). You can forget about that javamelody-swing module.

[mpe85]

Well then, I started off a PR to replace the itext dependency with openpdf. All unit tests seem to be OK. Feel free to complement/edit it.
#864

[evernat]

Given that:

• compatibility of javamelody with openpdf is broken in openpdf 1.3.11 (iText 2.x compatibility issue in recent OpenPDF versions LibrePDF/OpenPDF#274) and it does not seem easy to fix,
• if api compatibility between itext 2.1.7 and openpdf is restored soon, it may still break the same way in a later major version of openpdf,
• but many applications have itext 2.1.7 and not openpdf currently, independently of javamelody,

then I have changed the javamelody code (6532b4a), so that it is compatible with openpdf 1.3.11, while it still compiles and is fully compatible with itext 2.1.7. This change was done by never using Phrase::add(Object) with a String and only with an Element such as a Chunk.
This javamelody change is independent of openpdf issue to restore or not api compatibility with itext 2.1.7 for all applications and previous versions of javamelody. This is independent of replacing or not compilation and usage in javamelody from itext 2.1.7 to openpdf (#864) and still keeping compatibility with itext 2.1.7 if api is kept the same in openpdf.

[andreasrosdal]

Any news on this?

[evernat]

@andreasrosdal
No news more than said above. itext 2.1.7 is an optional (not transitive) dependency of javamelody-core. The plan in javamelody is to keep compatibility with itext 2.1.7 since applications often have currently an itext 2.1.7 dependency for whatever reason. javamelody is compatible with openpdf 1.3.11 and perhaps later. Issue 274 in openpdf is not fixed.