WinRun4j executables do not respect program arguments in app.l4j.ini

[keastrid]

I'm submitting a…

• bug report
• feature request
• other

Short description of the issue/suggestion:
When using winrun4j to build the exe, it does not respect the launch argument contents of app.l4j.ini.

Steps to reproduce the issue/enhancement:

1. Build using winrun
2. Setup app.l4j.ini
3. Attempt to change the available memory of the application

What is the expected behavior?
For it to respect program arguments set there

What is the current behavior?
It ignores them

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

What is the motivation / use case for changing the behavior?
Unified config across all platforms and launchers

Please tell us about your environment:

• JavaPackager version: 1.6.5
• OS version: Win10
• 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!
Yes, right now if WinRun4J is used to generate EXE files, VM arguments have to be set in ${name}.ini, which has a different format than ${name}.l4j.ini. The logical solution to this issue would be to modify the behavior of the WinRun4J EXE file, but I'm not sure if it's worth the effort.

[keastrid]

@fvarrui well, turns out it was worth the effort for me...

I've mostly rewritten what wr4j is doing and have it capable of reading in l4j's thing. Though what I have now is probably less feature complete, it does turn things on.

Would you be open to supporting it in javapackager, or adding a custom option that runs the exe through the same process as wn4j's? Though I'm not sure icon and renaming works yet

[fvarrui]

@keastrid, oh, great! 😅 ... what if we do the same as with custom templates? So, if you place a resource with the same name in ${assetsDir}, this will be used instead of the JavaPackager one. I mean, place your custom EXE in assets/windows/WinRun4J64.exe.

But if your WinRun4J64.exe works as expected, I've no problem in replace the current one with yours. Are your WinRun4j changes published anywhere?

[keastrid]

It is available here

And by "mostly rewritten" I meant "I made a new thing" (I can't read C and wn4j looked like a mess).
The format of the config is different, and is a hardcoded name (I would love to bundle it in the jar; attached is an example, remove the .txt, the quotes aren't needed).

So far the advantage over wr4j is no need to be so specific with the location of jvm.dll (it will search the path).

In its current state it will produce a launcher that will read the config files and function - I have yet to test RCEdit for the icon and name though.

launcher.ini.txt

[fvarrui]

Wow, nice work! I think in this case we should add Why (😄) as new EXE generation tool. Please, tell me something about tests with RCEdit. It would be great to have a good replacement for Launch4J and WinRun4J, taking the best of each.

[keastrid]

Thanks!

Just gave it a test, renaming and icon adding work!

Still no idea about how to bundle the ini file - but meh, that can be a future problem.

[keastrid]

The supported options and their format are documented here.

[fvarrui]

Just gave it a test, renaming and icon adding work!

Great!

Please, could you publish the EXE in the releases section of the repo?

[fvarrui]

The supported options and their format are documented here.

Thanks!

[keastrid]

Published in releases.

Note: jvm lookup (outside of specified and JAVA_HOME) is not yet implemented.

[keastrid]

Rather, now its published.

[fvarrui]

JavaPackager v1.6.6 released to Maven Central