Default template for winrun4j does not correctly specify/verify jvm.dll location for all runtimes

[keastrid]

I'm submitting a…

• bug report
• feature request
• other

Short description of the issue/suggestion:
Some java runtimes place the jvm.dll in /server rather than /client. Not sure why they have differing locations.

Steps to reproduce the issue/enhancement:

1. Build and package with Azul Zulu JDK 17
2. Attempt to run exe

What is the expected behavior?
Choosing the suitable path

What is the current behavior?
Hard specifying `/client``

Do you have outputs, screenshots, demos or samples which demonstrate the problem or enhancement?

AstroImageJ without the user-specified ini.vtl will display this behavior.

What is the motivation / use case for changing the behavior?
A bit of a surprise when it builds successfully and fails to run when the java distribution is present.

Please tell us about your environment:

• JavaPackager version: 1.6.3
• OS version: Windows 10
• JDK version: 17
• Build tool:
  • Maven
  • Gradle

Other information (e.g. related issues, suggestions how to fix, links for us to have context)

[fvarrui]

Hi @keastrid!
In this issue you can find a solution proposal.

[keastrid]

The fallback behavior looks good!

[fvarrui]

Fixed!

[fvarrui]

JavaPackager 1.6.4 released to Maven Central.