> Am 18.03.2023 um 16:47 schrieb Andreas Lehmkuehler <andr...@lehmi.de>:
>
> Am 17.03.23 um 23:40 schrieb axh:
>> - 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?
Much of the IOUtils class is obsolete now:
- toByteArray(InputStream in) - use in.readAllBytes()
- copy(InputStream input, OutputStream output) - use input.transferTo(output)
- populateBuffer(InputStream in, byte[] buffer) - in.readNBytes(in, buffer)
And I think shorter code can be a value, take this code from LogDialog.java:
String info = "";
for (String str : infos)
{
if (info.length() > 0)
{
info += ", ";
}
info += str;
}
logLabel.setText(info);
Compare that to:
logLabel.setText(String.join(", ", infos));
(OK, that’s already possible in Java 8, wait for the patch)
>> - 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
Next release is in just two days, next LTS will be this fall and there are
still classes related to SecurityManager that are marked as deprecated for
removal used in PDFBox. I AccessControlException is dropped in Java 21 (next
LTS), chances are high PDFBox 3 won’t work in Java 21.
>> 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
I only wonder why those people have the need to update to the very newest
version of PDFBox and at the same time are totally unable to update their JDK
to a more recent one. ;-)
I honestly don’t know how long people have been waiting for PDFBox 3, but maybe
it would be an option to finish 3 first, and after that start working on 4. But
then, Java 17 would be on my wishlist right away. If you go that way, let me
know where I can help to speed up things.
I have to say that I know next to nothing about the inner workings of PDF
(except what I learned when debugging through PDFBox trying to find out how to
use it for my own project). But on the other hand I am quite fluent in Java.
Axel
