(LWJGL) Application Deployment - Best practices?

[Source_of_Truth]

This thread is somewhere between a discussion and a question thread, please speak your mind freely...

One of Java's strength is the fact that the JRE exists on multiple platforms. As such, assume we have our nice Java game up and running, playing great and having zero bugs 

Now, how to we pack it together and deploy it best? Users (or customers even) do not want to play through a programming IDE or fiddle with arguments in the command line. They want to double-click on an Exe, a launch-script or a button/link in Steam (or whatever their favorite platform is, mine is GoG). Furthermore, they do not want to manually install any dependencies, ideally they do not want to "install" anything at all, it should just magically "work"  .

Granted, of course we still have installers today. Granted, of course we still install dependencies today, just remember how often you installed some Visual C++ Redistributable today. But the purpose of this topic is to discuss how to deal with the problem best in a Java context, an LWJGL-context even, leveraging the fact that our code runs on all the big OS out there if a compatible JRE is tagging along.

In short, we need to deploy the following things to a user's machine:
* our compiled Java Source Code (in some shape or form, e.g a JAR)
* our native codes, e.g. LWJGL or the STB-library, in a distribution matching the platform of the user
* a Java Runtime in a distribution matching the platform of the user
* our game assets, that means its graphics, its sounds and the whatnot

Depending on our build system, aka how we manage our code during development, some of this stuff might be easier, harder or just different. A Maven build works differently from a Gradle one, a manually managed project is an entirely different beast ...

For sake of example, assume we have a Maven-managed project with LWJGL (and thus its natives) only, some graphics and of course some Java Code. If we manage to distribute this, the more complex cases will follow. Furthermore, assume that our distribution simply takes the form of a (zipable) directory which is supposed to run standalone on any somewhat modern PC of today onto which we copy said folder. No "installer", no custom compression, no registering the game in same OS-specific registry, no programmatic removal...

The way I see it, there are two big approaches pre-Java 14:

1.) doing it by hand
You download the JRE for the target OS and place your compiled JARs of your maven-target next to it. Furthermore, you place your game's assets there as well (in the dir-structure your game requires) and you do the same with OS-compatible LWJGL natives you need.
Finally, you write a little native program in some other programming language that, on launch, executes the JRE with your JAR (and potentially all the other relevant file locations) as input.

2.) the build-system approach
This is similar to the above, but you leave the asset management to your build system, e.g. Maven. This probably has benefits if you are using classpath-resources. Natives and graphics get packed into your JARs as well or are already part of a JAR, like lwjgl-natives. Note however that since most OS only load native libraries from a "true" file, files from lwjgl-native will be regularly unarchived into a user's temporary directory by LWJGL.
For the rest, you procced as you did above, that means having the JRE somewhere in your distribution and writing a little launcher application.

With Java 14, a new way has arisen (or came back) and as such, the rather new JPackager needs to be discussed. This thing is supposed to construct a pseudo-native Application containing the relevant parts of the JRE necessary for your program, but I have little experience with this technology thus far. With respect to our example, it seemingly overcommits, since it does in fact build an installer around the distribution, but everything else sounds good. How it interoperates with existing native code of the project, like LWJGL, is unclear to me. If somebody here has experience with the thing, please share your thoughts or even a practical example.

So, considering our goal of deploying a hassle-free, runable distribution, what are your thoughts on the matter? 
Is there an established practice for LWJGL programs? Is it worth to check out what libgdx does or is that too far removed from the pure Java with a little lightweight native that LWJGL represents?

[Source_of_Truth]

Absolutely no posts here? I must confess, this a disappointment . Does this mean no one ever finishes his or her LWJGL projects around here?

[Evgeny]

Do you know about graal vm? I think it can help you, because bytecode will be compiled to native image. As result you will get executable file. It means that you should't think about jvm and other libreries. Native image will be contained everything to need to run your app.

[jakethesnake]

I'm distributing a java game continuously via approach 1. I have some scripts helping me, and it's really just a click now that it's all set up. I'm using a java 8 jre for win/linux/mac, have made an exe with launch 4j, and create mac and linux executables with pacr.

It was a daunting process getting it all right.

Problem with this is obviously that a jre is 200MB zipped, filled with bloat I so very much would like to trim off.

Problem with java > 8, IMO is their new licencing thing. I just can't wrap my head around it. They've also added a bunch of modern stuff, encouraging inefficient code. Backwards combability can also be a problem, especially on windows 7, which still exist.