feat: add java and JSignPdf fallback

[vitormattos]

Usage:

Will be necessary identify the Java Version to configure the fallback and also add the URL to download the .tar.gz file.

$jsignParam = new JSignParam();
$jsignParam->setJavaVersion('21.0.0');
$jsignParam->setJavaDownloadUrl('');
$jsignParam->setJavaPath('/the/path/of/bin/java');

Was created from this other PR:

• chore: bump php and update dependencies #29

to-do

• Implement fallback to download Java
• Implement fallback to download JSignPdf
• Remove implementation of setup by composer using the package jsignpdf/jsignpdf-bin
• rewrite tests that have calls to markTestSkipped

[jeidison]

It looks good. What do you think about setting default parameters?

Something like this:

class JSignParam
{
...
private string $javaVersion = "21.0.8";
private string $javaDownloadUrl = "https://github.com/adoptium/temurin21-binaries/releases/download/jdk-21.0.8%2B9/OpenJDK21U-jre_x64_linux_hotspot_21.0.8_9.tar.gz";
private string $jSignPdfDownloadUrl = "https://github.com/intoolswetrust/jsignpdf/releases/download/JSignPdf_2_3_0/jsignpdf-2.3.0.zip";
private string $jsignPdfVersion = "/../tmp/jsignpdf/JSignPdf.jar";
...

Since the $isUseJavaInstalled flag is set to false by default, in most cases we use the package by downloading the Java binary. This way, the user just needs to install the package and use it.

Other points:

• I think you could store the downloaded binary under sys_get_temp_dir() or [PATH PROJECT]/vendor/bin.
• When do you check if the binaries have already been downloaded to avoid downloading them again?

[vitormattos]

What do you think about setting default parameters?

Good idea!

[vitormattos]

The required Java version needs to be slightly higher than this one, because the -version output shows:

openjdk version "21.0.8" 2025-07-15 LTS

[vitormattos]

What do you think about checking the Java version every time to determine whether it's necessary to update the binary when a new release is available?

I implemented this approach, but I'm concerned it might cause unnecessary resource usage, such as CPU, I/O, and memory.

Only by example, I implemented the version check at Java flow and not at JSignPdf flow.

[vitormattos]

What do you think about setting default parameters?

Done!

[vitormattos]

@jeidison ready for review

[jeidison]

What do you think about checking the Java version every time to determine whether it's necessary to update the binary when a new release is available?

I implemented this approach, but I'm concerned it might cause unnecessary resource usage, such as CPU, I/O, and memory.

Only by example, I implemented the version check at Java flow and not at JSignPdf flow.

Hmm, I'm not sure about this. I think it's a bit risky. It might use unnecessary resources and break if a future version is incompatible with some parameter or something else.

[vitormattos]

Maybe we could create a cache file and simply check for its existence, without reading its content. The file name could include the version identifier of the current package.

If the file doesn't exist, we proceed with the setup: clean the folder, download the resources, and complete the process.
I believe this approach could help reduce resource usage when checking for the version.

For example:

.java_version_OpenJDK21U-jre_x64_linux_hotspot_21.0.8_9
.jsignpdf_version_jsignpdf-2.3.0

The cache file name could follow the same naming pattern as the original download URL, just prefixed with a dot to make it hidden.

[vitormattos]

@jeidison could I go ahead with the last idea?

[vitormattos]

@jeidison I already implemented the version check using a cache file.

[jeidison]

@jeidison I already implemented the version check using a cache file.

Ok, let's try it.