Am 17.03.23 um 23:40 schrieb axh:
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.
This are all valid points, but
I think reasons to update are:
- code can be shorter and more concise in many places
We have a lot more complicated issues than code which could be written shorter
using a more recent java version
- it will be easier to find contributors
Interesting, but I doubt that. The biggest issue is the complexity of the PDF
format
- functionality available in newer versions of the JDK does not have to be
reproduced and later maintained
Do you have a specific example in your mind?
- functionality provided by the JDK implementations will in most cases be
better tested and often more performant
Sorry, but IMHO that is just a theory. We have seen a lot of different
behaviours. Better/worst performance, issue intorduce due to an improvement ...
- 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
We already removed most of that stuff, otherwise we won't be able to run PDFBox
using Java 19 or 20
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?
There are still some java 8 based JDK/JREs which are updated on a regularly
basis.
We won't solve any real issue with that version bump but would cut off a lot of
people from the long awaited 3.0 version. PDFBox as a "under the hood lib" and
there are a lot of people using it who don't run a most recent java version
environment
Andreas
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>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
