Reasons for upgrade to iText 7
While we were always pretty happy with the capabilities of iText as they stood, there were a number of design choices that limited our wiggling room for further development. Over the years, a number of changes were introduced that used and transformed the existing framework in unintended, or even borderline improper ways. This was not per se a bad thing for the existing functionalities, but it made further extensibility - and, importantly, future-proofing for PDF 2.0 - much more difficult. Furthermore, some APIs were entirely public, which hampered our potential to reimplement functionality.
As a result of all this, we decided to rewrite iText from scratch in December 2013, thus breaking backward compatibility. Building from the ground up allowed us to make performance improvements that were impossible with the existing code, to make iText much more extensible and configurable from client code, and to get rid of some of the cruft that a project inevitably accumulates. The main improvements from a user's viewpoint are:
- iText 7 is modular, whereas the core library for iText 5 was one big JAR/DLL. You may need only a few of the modules for your use case, so you can reduce the total size of your compiled application. Add-ons are available for specific functionalities, but they don't encumber users that don't need them.
- uniformity in the PDF rendering engine. In iText 5, there were several rendering APIs that had a lot of functional overlap but also showed (sometimes subtle) differences in behavior.
- the Renderer framework, which lets you plug custom layout code into the standard library, thus reducing the need for the kind of feature requests that led to iText 5's mild case of featuritis.
Things that stay the same
While designing the code, we of course depended on our experience with our older versions. Since iText 5 already does a lot of things well, we took over some of its behavior and characteristics.
- The licensing model is unchanged: iText 7 is still released as FOSS software under the AGPL software license (meaning it remains an open source pdf generator), with commercial options available to users that do not wish to adhere to it.
- PDF parsing and text extraction was ported with only a few object name changes.
- The signing module is functionally equivalent to, and virtually unchanged from the iText 5 implementation.
- The PDF/A functionality is as easy to use as in iText 5.
- The layout module, with its HTML-like objects like Paragraph, List, etc, corresponds very closely to the high-level API of iText 5. Some classes have been renamed, but everything is very similar and transition should be easy for basic use cases. For more advanced use cases, you'll need to look into the Renderer framework.
iText 7 is built upon the Java SE 7 platform. Earlier versions have been EOL for multiple years and are not commonly used for new projects. Even though Java 7 itself is also (more recently) EOL, it is still very commonly used in the Java community. Another reason why we couldn't really go lower is that we use the enum java.lang.Character.UnicodeScript, which is only available from Java 7 onwards. Similarly, the .NET version of iText 7 targets the .NET Framework 4.0 as a reasonable base line for the future. We are also planning to support .NET Core and UWP in the near future alongside the .NET Framework.
In December 2017, iText5 will start its end of life phase. From that point on, iText5 will no longer be supported (unless agreed previously with our sales offices). If you make the switch to iText 7 now, you will continue having access to our support system, and bugfixes.
Why upgrade to iText 7?
When switching to iText 7, you get:
- better continued support and bugfixes,
- keeping up with today’s document workflow requirements,
- more modular, extensible handling of your document workflow,
- extra practical add-ons,
- 55 % better performance,
- encryption, hashing & digital signatures, and