RE: Minimum Java version for PDFBox 3.x
Hi,
You can compile with the api in 18 fine, just the feature cant be used. We use
it to lock down the application on a server.
Thanks
-Original Message-
From: axh
Sent: 19 March 2023 09:38
To: dev@pdfbox.apache.org
Subject: Re: Minimum Java version for PDFBox 3.x
Hi,
why do you need to use the SecurityManager? This will probably be a problem in
the future as starting with Java 18, the SecurityManager cannot be used by
default, and if PDFBox really needs it, this will possibly break compatibility
with the next LTS due in autumn:
>From JEP 411 (https://openjdk.org/jeps/411):
> In Java 18, we will prevent a Java application or library from dynamically
> installing a Security Manager unless the end user has explicitly opted to
> allow it.
So if possible, PDFBox should not rely on SecurityManager being there (at least
from 4 onward).
> Am 19.03.2023 um 09:41 schrieb Simon Steiner :
>
> Hi,
>
> We still need to use securitymanager on java 11/17, so you would need to keep
> those.
>
> Thanks
>
> -Original Message-
> From: axh
> Sent: 18 March 2023 17:14
> To: dev@pdfbox.apache.org
> Subject: Re: Minimum Java version for PDFBox 3.x
>
>
>
>> Am 18.03.2023 um 16:47 schrieb Andreas Lehmkuehler :
>>
>> 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
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For
> additional commands, e-mail: dev-h...@pdfbox.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
Re: Minimum Java version for PDFBox 3.x
I've created https://issues.apache.org/jira/browse/PDFBOX-5576 to not forget about this ;-) Andreas Am 18.03.23 um 18:07 schrieb Maruan Sahyoun: Fine - so let‘s target that for 4x Am 18.03.2023 um 16:51 schrieb Andreas Lehmkuehler : Am 18.03.23 um 10:49 schrieb Maruan Sahyoun: I‘d second a move to 11 for 3.x as for the lifetime of 3.x this will enable us to use newer funtions without another major release. I'd like to do so for the next major version 4.0.x. Hopefully it won't take us that much time to release that version as it took us to release 3.0.x. BTW 3.0.x will be the last version supporting preflight and maybe it is a good idea to stuck with java 8 compatibility. Andreas BR Maruan Am 18.03.2023 um 10:13 schrieb Tilman Hausherr : You may have a point with some of your arguments, but not this one: Public updates for Java 8 have stopped in march 2022, now one year ago My latest jdk8 is from January 17th of this year. (Amazon Corretto) About the difficulty to find contributors - this has always been difficult. That's because PDF isn't "sexy" at all. Coincidentally, our CI builds are now failing because of Jenkins / Hudson has moved to jdk11. Tilman - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
Re: Minimum Java version for PDFBox 3.x
Hi,
why do you need to use the SecurityManager? This will probably be a problem in
the future as starting with Java 18, the SecurityManager cannot be used by
default, and if PDFBox really needs it, this will possibly break compatibility
with the next LTS due in autumn:
From JEP 411 (https://openjdk.org/jeps/411):
> In Java 18, we will prevent a Java application or library from dynamically
> installing a Security Manager unless the end user has explicitly opted to
> allow it.
So if possible, PDFBox should not rely on SecurityManager being there (at least
from 4 onward).
> Am 19.03.2023 um 09:41 schrieb Simon Steiner :
>
> Hi,
>
> We still need to use securitymanager on java 11/17, so you would need to keep
> those.
>
> Thanks
>
> -Original Message-
> From: axh
> Sent: 18 March 2023 17:14
> To: dev@pdfbox.apache.org
> Subject: Re: Minimum Java version for PDFBox 3.x
>
>
>
>> Am 18.03.2023 um 16:47 schrieb Andreas Lehmkuehler :
>>
>> 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
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
> For additional commands, e-mail: dev-h...@pdfbox.apache.org
>
RE: Minimum Java version for PDFBox 3.x
Hi,
We still need to use securitymanager on java 11/17, so you would need to keep
those.
Thanks
-Original Message-
From: axh
Sent: 18 March 2023 17:14
To: dev@pdfbox.apache.org
Subject: Re: Minimum Java version for PDFBox 3.x
> Am 18.03.2023 um 16:47 schrieb Andreas Lehmkuehler :
>
> 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
-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
Re: Minimum Java version for PDFBox 3.x
> Am 18.03.2023 um 16:47 schrieb Andreas Lehmkuehler :
>
> 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
Re: Minimum Java version for PDFBox 3.x
Fine - so let‘s target that for 4x > Am 18.03.2023 um 16:51 schrieb Andreas Lehmkuehler : > > Am 18.03.23 um 10:49 schrieb Maruan Sahyoun: >> I‘d second a move to 11 for 3.x as for the lifetime of 3.x this will enable >> us to use newer funtions without another major release. > I'd like to do so for the next major version 4.0.x. Hopefully it won't take > us that much time to release that version as it took us to release 3.0.x. > > BTW 3.0.x will be the last version supporting preflight and maybe it is a > good idea to stuck with java 8 compatibility. > > Andreas >> BR >> Maruan Am 18.03.2023 um 10:13 schrieb Tilman Hausherr : >>> >>> You may have a point with some of your arguments, but not this one: Public updates for Java 8 have stopped in march 2022, now one year ago >>> >>> My latest jdk8 is from January 17th of this year. (Amazon Corretto) >>> >>> About the difficulty to find contributors - this has always been difficult. >>> That's because PDF isn't "sexy" at all. >>> >>> Coincidentally, our CI builds are now failing because of Jenkins / Hudson >>> has moved to jdk11. >>> >>> Tilman >>> >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org >>> For additional commands, e-mail: dev-h...@pdfbox.apache.org >>> >> - >> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org >> For additional commands, e-mail: dev-h...@pdfbox.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: dev-h...@pdfbox.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
Re: Minimum Java version for PDFBox 3.x
Am 18.03.23 um 10:13 schrieb Tilman Hausherr: You may have a point with some of your arguments, but not this one: Public updates for Java 8 have stopped in march 2022, now one year ago My latest jdk8 is from January 17th of this year. (Amazon Corretto) About the difficulty to find contributors - this has always been difficult. That's because PDF isn't "sexy" at all. Coincidentally, our CI builds are now failing because of Jenkins / Hudson has moved to jdk11. I've switched the builds (trunk and 2.0) to Java11. Andreas Tilman - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
Re: Minimum Java version for PDFBox 3.x
Am 18.03.23 um 10:49 schrieb Maruan Sahyoun: I‘d second a move to 11 for 3.x as for the lifetime of 3.x this will enable us to use newer funtions without another major release. I'd like to do so for the next major version 4.0.x. Hopefully it won't take us that much time to release that version as it took us to release 3.0.x. BTW 3.0.x will be the last version supporting preflight and maybe it is a good idea to stuck with java 8 compatibility. Andreas BR Maruan Am 18.03.2023 um 10:13 schrieb Tilman Hausherr : You may have a point with some of your arguments, but not this one: Public updates for Java 8 have stopped in march 2022, now one year ago My latest jdk8 is from January 17th of this year. (Amazon Corretto) About the difficulty to find contributors - this has always been difficult. That's because PDF isn't "sexy" at all. Coincidentally, our CI builds are now failing because of Jenkins / Hudson has moved to jdk11. Tilman - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
Re: Minimum Java version for PDFBox 3.x
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 :
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 frame
Re: Minimum Java version for PDFBox 3.x
I‘d second a move to 11 for 3.x as for the lifetime of 3.x this will enable us to use newer funtions without another major release. BR Maruan > Am 18.03.2023 um 10:13 schrieb Tilman Hausherr : > > You may have a point with some of your arguments, but not this one: >> Public updates for Java 8 have stopped in march 2022, now one year ago > > My latest jdk8 is from January 17th of this year. (Amazon Corretto) > > About the difficulty to find contributors - this has always been difficult. > That's because PDF isn't "sexy" at all. > > Coincidentally, our CI builds are now failing because of Jenkins / Hudson has > moved to jdk11. > > Tilman > > > > - > To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: dev-h...@pdfbox.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
Re: Minimum Java version for PDFBox 3.x
You may have a point with some of your arguments, but not this one: Public updates for Java 8 have stopped in march 2022, now one year ago My latest jdk8 is from January 17th of this year. (Amazon Corretto) About the difficulty to find contributors - this has always been difficult. That's because PDF isn't "sexy" at all. Coincidentally, our CI builds are now failing because of Jenkins / Hudson has moved to jdk11. Tilman - To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
Re: Minimum Java version for PDFBox 3.x
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 :
>
> 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>
Re: Minimum Java version for PDFBox 3.x
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
For additional commands, e-mail: dev-h...@pdfbox.apache.org
Minimum Java version for PDFBox 3.x
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
- 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.
- 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
