Modernization of OpenPDF in 2.0.0
andreasrosdal opened this issue · comments
Modernization of OpenPDF in 2.0.0:
- Removal of 108 deprecated old methods and fields. Started here: be38865 This will allow a cleaner API with less technical debt. See JavaDoc for the methods marked as deprecated in 1.3.40 and the new methods to use instead: https://javadoc.io/doc/com.github.librepdf/openpdf/latest/index.html
- Allow breaking API changes to allow modern Java 17+ syntax, using generics and modern methods.
- Use modern Java 17+ compatible syntax and libraries.
- Java 17 will be required for OpenPDF 2.0.0. https://blogs.oracle.com/javamagazine/post/its-time-to-move-your-applications-to-java-17-heres-why-and-heres-how
- Fix compilation warnings
Pull request for modernizing OpenPDF for version 2.0.0 is welcome.
Suggested release date for OpenPDF 2.0.0 can be 2024-03-01. After this release I imagine a long period of stable API.
According to semantic versioning this needs to be version 2.0.0
So in this issue we can discuss modernization of OpenPDF. In particular how the API can be improved by taking advantage of new Java versions. Previous releases is not much to do about now. So I encourage you to submit proposals on how to modernize OpenPDF here.
Further note that the adoption of the recent OpenPDF versions have been quite good, with few followup bugreports.
It's important for this project to listen to the users of the library, so therefore feedback about how to modernize the library is welcome.
It seems that some users are not able to update their Java versions so easily, and for these users we can maintain separate branches for old Java version, if you specifically request it. Over time most users are able to update their Java versions eventually.
Furthermore, it's very much possible to volunteer to help maintain this fine library, and to help maintain branches and releases for old Java versions. It's also possible to create forks on Github, and create your own releases with specific features.
Hi, would you consider changing the class packages ?
Everything is under a com.lowagie.*, wouldn't it be better to have some org.openpdf.* ?
The code is dealing with dates as Calendar maybe we could bring some support for the java.time.* API here
Closing this now. So the two modernizations in OpenPDF 2.0 will be removal of 108 deprecated methods and fields, and requirement for Java 17. Pull requests for further modernization is welcome, however, these two improvements is all for now that I'll implement.