Closed andreasrosdal closed 10 months ago
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.
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)
@albfernandez I think you are right. We should revert these changes. And redo them in another Major Version.
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.
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 :-)
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.
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.
Is there any known issues on the API not beeing a drop-in replacemant for iText?
Looks like this was fixed here: https://github.com/javamelody/javamelody/issues/788
https://github.com/javamelody/javamelody/issues/788#issuecomment-535818722