iText 2.x compatibility issue in recent OpenPDF versions

[andreasrosdal]

javamelody/javamelody#788 (comment)

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)

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).

[evernat]

Perhaps this issue also impacts other software or applications using or trying to use OpenPDF as a replacement for iText 2.1.7.

The compatibility between OpenPDF 1.3.x and iText 2.1.7 may be restored by adding:

    public boolean add(Object o) {
        if (o instanceof String) {
            return add((String) o);
        }
        if (o instanceof RtfElementInterface) {
        	return super.add(o);
        }
        return add((Element) o);
    }

I think it's worth it to keep compatibility.
Of course, if there are other major api incompatibilities, it may not be worth it.

[albfernandez]

It's not easy because Phrase extends ArrayList <Element>
method add(Object) could not be defined ... unless remove the generic Element in the extends clause (and rollback generics changes related to it in this and other classes)

[asturio]

@albfernandez I think you are right. We should revert these changes. And redo them in another Major Version.

[andreasrosdal]

Maybe it was time to break API compatibility with iText, in this small way, as part of the modernization efforts. People should update from old iText versions to OpenPDF anyway, to get all the latest security fixes and bugfixes.

[asturio]

So... how about branch now a 1.3 release and a 2.0 release (e.g. in master). In the 2.0 release we can continue the modernization, and we break the compatibility even more, and in the 1.3 line, we try to keep the compatibility (and restore any broken issues)?
And I would only release some RC of the 2.0-line at first. So we could do all the nice things we are dreaming about :-)

[albfernandez]

So... how about branch now a 1.3 release and a 2.0 release (e.g. in master). In the 2.0 release we can continue the modernization, and we break the compatibility even more, and in the 1.3 line, we try to keep the compatibility (and restore any broken issues)?
And I would only release some RC of the 2.0-line at first. So we could do all the nice things we are dreaming about :-)

I think it's easier to maintain a 1.2.x (java7) branch and try to backport there the important fixes.

I'm not sure in doing a "break" release. We use some libraries which use OpenPDF / itext, if we break compatibility, we must stuck in old versions until all libraries upgrade to the new release.

[lapo-luchini]

Mhhhh… being "drop-in" replacement for iText 2.x (or, the few that knew it, 4.x) is a strong use-case for OpenPDF in many situations, I'd be nice to have a (somewhat maintained) branch of that available in the future too (which, of course, can have much less changes/updates than any main branch), it would be a shame to lose that.

[asturio]

Is there any known issues on the API not beeing a drop-in replacemant for iText?

[andreasrosdal]

Looks like this was fixed here: javamelody/javamelody#788