Hi Andreas,
you are right about the typo, it’s Tomcat 9.1 that drops Java 8 support and
requires at least Java 11.
What I tried to point out with that list is that IMHO there’s no benefit in
maintaining compatibility with an outdated Java version.
I think reasons to update are:
- code can be shorter and more concise in many places
- it will be easier to find contributors
- functionality available in newer versions of the JDK does not have to be
reproduced and later maintained
- functionality provided by the JDK implementations will in most cases be
better tested and often more performant
- functionality deprecated after Java 8 cannot be used because it would impact
compatibility with newer Java versions while new functionality cannot be used
because it impacts compatibility with Java 8
Public updates for Java 8 have stopped in march 2022, now one year ago, and
keeping PDFBox compatible with that version does not come at no cost (see the
points above), so what’s the point of still supporting it?
And yes, there are more things to brush up. For example Apache commons logging
has not seen an update in 9 years, is missing functionality, and IMHO should be
replaced by SLF4J 2 or log4j. But that’s another point (and yes, I’d volunteer
to do the transition provided there’s a chance to get it in).
Cheers,
Axel
> Am 17.03.2023 um 20:06 schrieb Andreas Lehmkuehler <andr...@lehmi.de>:
>
> Am 17.03.23 um 10:09 schrieb axh:
>> Hi,
>> I am developing a software that relies heavily on Apache PdfBox. It uses the
>> current the current PDFBox 3.0.0 from trunk, with some patches.
>> I wanted to know what your thoughts are about raising the minimum Java
>> version for PDFBox 3.x to Java 11. I know some might say "we are still on
>> JDK 8 and will be for the foreseeable future“. But then you could probably
>> stay on the 2.x line of PDFBox, since you won’t be able to update most of
>> your technology stack to recent versions anyway:
>> - Spring BOOT 3 requires Java 17
>> - WildFly 27 dropped support for Java 8, and while I don’t have access to
>> the Redhat docs, I think so will JBOSS 8
>> - Hibernate 6 requires at least Java 11
>> - Apache Tomcat 6 requires at least Java 11, 6.1 even requires 17
> Has to be a typo, Tomcat 9 or 10 are the recent to be used. ;-)
>
>> - Apache Lucene 9.5 requires Java 11
>> IMHO, the next major version a.k.a. PDFBox 3.0.0 would be the right moment
>> to increase the required Java version.
> Yes, but I don't see any reason to do so. The trunk version works fine with
> java 19 and 20. As long as we don't really need any java9 or later feature I
> tend to stick with java8. We don't have to switch just because others are
> doing so ;-)
>
> Andreas
>
>> - PDFBox uses classes and methods that are deprecated in newer Java versions.
>> - IMHO it will also be harder to get contributors.
>> - Some things have to be done in a cumbersome and less performant way to
>> maintain Java 8 compatibility because functionality introduced in newer JDKs
>> cannot be used to keep Java 8 compatibility:
>> Java 8 (current implementation):
>> public static byte[] toByteArray(InputStream in) throws IOException
>> {
>> ByteArrayOutputStream baout = new ByteArrayOutputStream();
>> copy(in, baout);
>> return baout.toByteArray();
>> }
>> public static long copy(InputStream input, OutputStream output) throws
>> IOException
>> {
>> byte[] buffer = new byte[4096];
>> long count = 0;
>> int n = 0;
>> while (-1 != (n = input.read(buffer)))
>> {
>> output.write(buffer, 0, n);
>> count += n;
>> }
>> return count;
>> }
>> Java 11:
>> public static byte[] toByteArray(InputStream in) throws IOException {
>> return in.readAllBytes();
>> }
>> public static long copy(InputStream input, OutputStream output) throws
>> IOException {
>> return input.transferTo(output);
>> }
>> I would like to contribute to PDFBox, but would really suggest to bump the
>> required Java version to Java 11. I personally would be OK with going
>> directly to 17 like Spring framework did, but I can see that Java 11
>> compatibility might be a serious issue for some.
>> What are your thoughts on this matter?
>> Axel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
> <mailto:dev-unsubscr...@pdfbox.apache.org>
> For additional commands, e-mail: dev-h...@pdfbox.apache.org
> <mailto:dev-h...@pdfbox.apache.org>
