Re: log4j2 revert

[axh]

Hi,

I opened PDFBOX-5705 <https://issues.apache.org/jira/browse/PDFBOX-5705> for 
this and created a patch. Everything seems to work, but please verify in 
Jenkins. Sorry that Jira somehow changed priority to „important“ without me 
noticing. My internet connection is somewhat unreliable today and every click 
in Jira takes several tries to get through so I will just leave it at that if 
it’s ok for you.

Axel

> Am 20.10.2023 um 09:52 schrieb axh :
> 
> Ah, this is weird. Log4J2 currently isn’t used at all in the PDFBox code 
> base. But when running tests and examples, log4j-core and log4j-jcl are 
> included to reroute commons logging to log4j2 which is then used to set the 
> output format and create the log file you mentioned. It seems that with the 
> updated version, the commons logging to log4j bridge simply isn’t loaded 
> anymore.
> 
> This is also something that will get better once we switch directly to log4j.
> 
> I’ll keep you updated when I find out why log4j-jcl isn’t loaded.
> 
> Axel
> 
>> Am 20.10.2023 um 08:11 schrieb Tilman Hausherr :
>> 
>> Yes, although the log file isn't part of the distribution (or is it?) I 
>> wondered why it wasn't there. And then I noticed that the logging didn't 
>> work anymore, i.e. the typical output format wasn't there in the console. 
>> And not in the file either. And the same happened at work with another 
>> software of mine.
>> 
>> @Axel the "Files differ" lines are not a problem, this always happens. I 
>> check these manually or with a modified code and my own "expected" files.
>> 
>> Tilman
>> 
>> On 20.10.2023 07:55, Andreas Lehmkühler wrote:
>>> 
>>> 
>>> Am 20.10.23 um 07:17 schrieb axh:
>>>> Hm… I just did a clean checkout of trunk and did mvn clean verify and 
>>>> everything passes, both with log4j2.version set to 2.20.0 and 2.21.0. I 
>>>> can however see file differences reported in the log like this:
>>> The buidl itself works fine after the update. The Jenkins build adds 
>>> another step to the end which fails. An expected log file is missing:
>>> 
>>> ERROR: Step ?Archive the artifacts? failed: No artifacts found that match 
>>> the file pattern "pdfbox/target/pdfbox.log". Configuration error?
>>> 
>>> 
>>> See [1] for further details
>>> 
>>> [1] https://ci-builds.apache.org/job/PDFBox/job/PDFBox-trunk/1823/console
>>> 
>>> 
>>>> 
>>>> [INFO] Running org.apache.pdfbox.pdmodel.interactive.form.PDAcroFormTest
>>>> Files differ: 
>>>> /Users/axelhowind/IdeaProjects/pdfbox/pdfbox/src/test/resources/org/apache/pdfbox/pdmodel/interactive/form/MultilineFields.pdf-1.png
>>>> /Users/axelhowind/IdeaProjects/pdfbox/pdfbox/target/test-output/MultilineFields.pdf-1.png
>>>> Rendering of target/test-output/MultilineFields.pdf failed or is not 
>>>> identical to expected rendering in 
>>>> src/test/resources/org/apache/pdfbox/pdmodel/interactive/form directory
>>>> [INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
>>>> 1.027 s -- in 
>>>> org.apache.pdfbox.pdmodel.interactive.form.MultilineFieldsTest
>>>> 
>>>> But these are not reported as test failures. In the test code, I can see 
>>>> that this is by design:
>>>> 
>>>> // compare rendering
>>>> if (!TestPDFToImage.doTestFile(pdf, IN_DIR.getAbsolutePath(), 
>>>> OUT_DIR.getAbsolutePath()))
>>>> {
>>>> // don't fail, rendering is different on different systems, result 
>>>> must be viewed manually
>>>> System.err.println("Rendering of " + pdf + " failed or is not 
>>>> identical to expected rendering in " + IN_DIR + " directory");
>>>> }
>>>> What exactly does "it no longer works" mean? Is it related to the above, 
>>>> or is it the build failures reported by Jenkins on the list?
>>>> 
>>>> Axel
>>>> 
>>>>> Am 20.10.2023 um 06:50 schrieb axh :
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> just saw your message here. As I just started on replacing 
>>>>> commons-logging by log4j, I will also look into this. I also overlooked 
>>>>> that there’s already a property for the log4j version. Will update the 
>>>>> patch I just submitted and then see if I can find out what’s causing the 
>>>>> test failure with 2.21.0.
>

Re: log4j2 revert

[axh]

Ah, this is weird. Log4J2 currently isn’t used at all in the PDFBox code base. 
But when running tests and examples, log4j-core and log4j-jcl are included to 
reroute commons logging to log4j2 which is then used to set the output format 
and create the log file you mentioned. It seems that with the updated version, 
the commons logging to log4j bridge simply isn’t loaded anymore.

This is also something that will get better once we switch directly to log4j.

I’ll keep you updated when I find out why log4j-jcl isn’t loaded.

Axel

> Am 20.10.2023 um 08:11 schrieb Tilman Hausherr :
> 
> Yes, although the log file isn't part of the distribution (or is it?) I 
> wondered why it wasn't there. And then I noticed that the logging didn't work 
> anymore, i.e. the typical output format wasn't there in the console. And not 
> in the file either. And the same happened at work with another software of 
> mine.
> 
> @Axel the "Files differ" lines are not a problem, this always happens. I 
> check these manually or with a modified code and my own "expected" files.
> 
> Tilman
> 
> On 20.10.2023 07:55, Andreas Lehmkühler wrote:
>> 
>> 
>> Am 20.10.23 um 07:17 schrieb axh:
>>> Hm… I just did a clean checkout of trunk and did mvn clean verify and 
>>> everything passes, both with log4j2.version set to 2.20.0 and 2.21.0. I can 
>>> however see file differences reported in the log like this:
>> The buidl itself works fine after the update. The Jenkins build adds another 
>> step to the end which fails. An expected log file is missing:
>> 
>> ERROR: Step ?Archive the artifacts? failed: No artifacts found that match 
>> the file pattern "pdfbox/target/pdfbox.log". Configuration error?
>> 
>> 
>> See [1] for further details
>> 
>> [1] https://ci-builds.apache.org/job/PDFBox/job/PDFBox-trunk/1823/console
>> 
>> 
>>> 
>>> [INFO] Running org.apache.pdfbox.pdmodel.interactive.form.PDAcroFormTest
>>> Files differ: 
>>> /Users/axelhowind/IdeaProjects/pdfbox/pdfbox/src/test/resources/org/apache/pdfbox/pdmodel/interactive/form/MultilineFields.pdf-1.png
>>> /Users/axelhowind/IdeaProjects/pdfbox/pdfbox/target/test-output/MultilineFields.pdf-1.png
>>> Rendering of target/test-output/MultilineFields.pdf failed or is not 
>>> identical to expected rendering in 
>>> src/test/resources/org/apache/pdfbox/pdmodel/interactive/form directory
>>> [INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
>>> 1.027 s -- in org.apache.pdfbox.pdmodel.interactive.form.MultilineFieldsTest
>>> 
>>> But these are not reported as test failures. In the test code, I can see 
>>> that this is by design:
>>> 
>>> // compare rendering
>>> if (!TestPDFToImage.doTestFile(pdf, IN_DIR.getAbsolutePath(), 
>>> OUT_DIR.getAbsolutePath()))
>>> {
>>>  // don't fail, rendering is different on different systems, result 
>>> must be viewed manually
>>>  System.err.println("Rendering of " + pdf + " failed or is not 
>>> identical to expected rendering in " + IN_DIR + " directory");
>>> }
>>> What exactly does "it no longer works" mean? Is it related to the above, or 
>>> is it the build failures reported by Jenkins on the list?
>>> 
>>> Axel
>>> 
>>>> Am 20.10.2023 um 06:50 schrieb axh :
>>>> 
>>>> Hi,
>>>> 
>>>> just saw your message here. As I just started on replacing commons-logging 
>>>> by log4j, I will also look into this. I also overlooked that there’s 
>>>> already a property for the log4j version. Will update the patch I just 
>>>> submitted and then see if I can find out what’s causing the test failure 
>>>> with 2.21.0.
>>>> 
>>>> Axel
>>>> 
>>>>> Am 19.10.2023 um 19:06 schrieb Tilman Hausherr :
>>>>> 
>>>>> I have reverted the change to the log4j2 version. It no longer works. 
>>>>> I'll wait a bit if there is an issue about it, there was nothing on the 
>>>>> mailing list today.
>>>>> 
>>>>> 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: log4j2 revert

[axh]

Hm… I just did a clean checkout of trunk and did mvn clean verify and 
everything passes, both with log4j2.version set to 2.20.0 and 2.21.0. I can 
however see file differences reported in the log like this:

[INFO] Running org.apache.pdfbox.pdmodel.interactive.form.PDAcroFormTest
Files differ: 
/Users/axelhowind/IdeaProjects/pdfbox/pdfbox/src/test/resources/org/apache/pdfbox/pdmodel/interactive/form/MultilineFields.pdf-1.png
  
/Users/axelhowind/IdeaProjects/pdfbox/pdfbox/target/test-output/MultilineFields.pdf-1.png
Rendering of target/test-output/MultilineFields.pdf failed or is not identical 
to expected rendering in 
src/test/resources/org/apache/pdfbox/pdmodel/interactive/form directory
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.027 s 
-- in org.apache.pdfbox.pdmodel.interactive.form.MultilineFieldsTest

But these are not reported as test failures. In the test code, I can see that 
this is by design:

// compare rendering
if (!TestPDFToImage.doTestFile(pdf, IN_DIR.getAbsolutePath(), 
OUT_DIR.getAbsolutePath()))
{
// don't fail, rendering is different on different systems, result must be 
viewed manually
System.err.println("Rendering of " + pdf + " failed or is not identical to 
expected rendering in " + IN_DIR + " directory");
}
What exactly does "it no longer works" mean? Is it related to the above, or is 
it the build failures reported by Jenkins on the list?

Axel

> Am 20.10.2023 um 06:50 schrieb axh :
> 
> Hi,
> 
> just saw your message here. As I just started on replacing commons-logging by 
> log4j, I will also look into this. I also overlooked that there’s already a 
> property for the log4j version. Will update the patch I just submitted and 
> then see if I can find out what’s causing the test failure with 2.21.0.
> 
> Axel
> 
>> Am 19.10.2023 um 19:06 schrieb Tilman Hausherr :
>> 
>> I have reverted the change to the log4j2 version. It no longer works. I'll 
>> wait a bit if there is an issue about it, there was nothing on the mailing 
>> list today.
>> 
>> 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: log4j2 revert

[axh]

Hi,

just saw your message here. As I just started on replacing commons-logging by 
log4j, I will also look into this. I also overlooked that there’s already a 
property for the log4j version. Will update the patch I just submitted and then 
see if I can find out what’s causing the test failure with 2.21.0.

Axel

> Am 19.10.2023 um 19:06 schrieb Tilman Hausherr :
> 
> I have reverted the change to the log4j2 version. It no longer works. I'll 
> wait a bit if there is an issue about it, there was nothing on the mailing 
> list today.
> 
> 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: PDFBox 4.0 and development plans

[axh]

Hi,

I suggest to also revisit logging. Last week I opened an issue for that 
(PDFBOX-5695 ), but it seems 
everybody is tired by this subject and no none even looked at it. Nonetheless, 
please take a look. The last time a switch to a logging facade was proposed 
(and rejected) has been 10 years ago. I think it is worth reconsidering, and a 
new major release would be the right time to do a change like that. More 
details in the issue.

Whatever the project decides, I am willing to contribute the required patch(es).

Cheers,
Axel 

> Am 11.10.2023 um 07:53 schrieb sahy...@fileaffairs.de:
> 
> Dear colleagues,
> 
> with 3.0 being released and 4.0 being started I'd like to start
> discussing what the major plans are for 4.0. And maybe in a way that
> the release can be made faster than what we had for 3.0. (maybe size it
> in a way that we can do the dev stuff by spring 2024 and then release
> in summer 2024 followed by a 4.1 release to add to that instead of
> doing a big bang like 3.0) 
> 
> Shall we share some ideas via the mailing list or start a page on our
> website (I think ml is easier to do). We can still document the major
> initiatives as soon as we have agreed in a blog post.
> 
> Here are my current thoughts (some of which might also be backported to
> 3.0) in no particular order
> 
> - appareance stream handlers for interactive form widgets (similar to
> what we have for annotations) also allowing one to add their own
> handler
> - replacement or at least new base for XMPBox (current thought is to
> have a new base parser and add if possible XMPBox current end user api
> on top - might be able to reuse xmlgraphics XMP lib). Would allow to
> better deal with XMPs which are not standard and make it easier to add
> to existing XMPs low level.
> - then we had the discussion about an event handler/listener similar to
> what fop provides so one can listen to corrections/repairs done under
> the hood (I know that we can only lay the ground for that as this is a
> major undertaking given all the places where we correct things)
> - enhance the parsing to keep the information about incremental
> versions (better debugging, trace of changes done ...)
> - review and add some more PDF 2.0 capabilities
> - better text formatting/language support (maybe by including fop parts
> or looking into using HarfBuzz)
> - I'd also like to discuss reaching out to fop to look at integrating
> some of their font handling into fontbox
> ...
> 
> That list is already long and I think would be too much given above
> idea of release planning.
> 
> With regards to versioning I'd like to propose that we have 2.0 as LTS
> and 4.x being the next LTS.
> 
> Thoughts
> BR
> Maruan
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
> For additional commands, e-mail: dev-h...@pdfbox.apache.org
> 

Re: CipherInputStream may not be closed

[axh]

Hi Anna-Katharina,

what version are you using? In the current 3.0, the stream is closed 
(implicitly) by using the try-with-resources syntax 
(https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html):

try (CipherInputStream cis = new CipherInputStream(data, cipher))
{
…
}
According to Git Blame, try-with-resources has been used at that point since 
2017, so there should be no problem. Disclaimer: I am not a maintainer, I just 
sometimes contribute code.

Axel


> Am 08.09.2023 um 14:08 schrieb Anna-Katharina Wickert 
> :
> 
> Hei dear maintainers,
> 
> For a benchmark [1], we randomly sampled JCA usages to decide if the API 
> usage is a violation of any API usage constraint.
> We believe we found one for the JCA class CipherInputStream.
> The call to *close* is missing for the call sequence to *CipherInputStream*. 
> Thus, the input stream including the ressources of the stream are not 
> released. [More Details in the JDK 17 
> documentation](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/crypto/CipherInputStream.html)
> The instance that we sampled is located in:
> - file: 
> pdfbox/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/encryption/SecurityHandler.java
> - method: private void encryptDataAES256(InputStream data, OutputStream 
> output, boolean decrypt) throws IOException
> - line: 379
> 
> To the best of my knowledge, this JCA usage does not result in a 
> vulnerability (directly). However, it violates the API constraint discussed 
> above. Therefore, we consider adding this usage as a violation into the 
> benchmark.
> 
> Best,
> Anna-Katharina Wickert
> For the CamBench team
> 
> [1] https://github.com/CROSSINGTUD/CamBench

Updating PDFBox code to use Java 11 features

[axh]

Hi,

now that 3.0 has been released and the Java version was updated to at least 
Java 11 in trunk for the next release, the PDFBox code can be updated in many 
places.

Some methods in IOUtils are now obsolete:

 - `public static long copy(InputStream input, OutputStream output) throws 
IOException` can be replaced by a simple call to input.transferTo(output).
 - `public static byte[] toByteArray(InputStream in) throws IOException` can be 
replaced by `in.readAllBytes()`

Now I could either
 - a) leave those methods in IOUtils and just change the implementations of 
both methods
 - b) remove the methods and make the changes mentioned above at the call sites

I prefer b) because I think it’s the cleaner approach. This means that if 
anybody uses the IOUtils class in their client code, they will have to change 
their code too. But I think that would be alright since 4.0 will be a new major 
release and thinks like that are to be expected.

There’s of course an alternative:
 - c) change the methods implementations and mark the methods in IOUtils as 
deprecated (so they are still available for client code), and at the same time 
change all call sites to use the new methods provided by the JDK.

Which solution is preferred?

Axel


-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org

issues with the eclipse formatter settings

[axh]

Hi,

after I received the comment to follow PDFBox coding style and use the provided 
settings for the eclipse formatter, I tried to import the eclipse settings into 
IntelliJ (the IDE I usually use) and received an error. I investigated and 
found out that two of the settings caused a problem:

 * 
 * 

The import works if I delete these two lines. Now I wouldn't bother to report 
it here, but I opened IDEA-315699 (
https://youtrack.jetbrains.com/issue/IDEA-315699), and they closed it saying 
that "120" is indeed an incorrect value although eclipse accepts it (but 
according to them, eclipse treats it as "0").

If you think this would be worth fixing, I would do this:
* do a clean checkout of trunk
* reformat the complete code with the provided formatter settings
* do the same once more but with the two lines mentioned above removed/set to 
"0"
* check if there are any differences
* if there are no differences, provide a patch for the formatter file

Would such a patch be accepted? I think it might help other potential 
contributors if they can just apply the formatter settings in their preferred 
IDE.

Alternatively, I could provide a matching IntelliJ or EditorConfig file 
(editorconfig should also work with other IDEs/editors such as VS code, and 
others).

Cheers,
Axel

Re: Minimum Java version for PDFBox 3.x

[axh]

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

[axh]

> 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

[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.

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>

Minimum Java version for PDFBox 3.x

[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
 - 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

Re: [ANNOUNCE] Apache PDFBox 3.0.0-alpha2 released

[axh]

Hi,

Just wanted to give a positive feedback: I have replaced my custom built 
pdfbox.jar with alpha2 in my project and so far everything works as expected. 
The JPMS problem that prevented me from using the unmodified alpha1 (aka RC) is 
fixed and I have not encountered any other issues so far.

Axel


-
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org