I want to display some russian characters in a program, but fail now. Please take a look here:
Until today, this program worked just nice at least on my machine. I did not have Java21 installed, but configurated the gradle script to build with Java21. So gradle grabs an according Java version and worked fine with it. Running from a distribution or gradle wrapper did not work.
Now, I installed Java21, and my program runs now but displays garbage where it should show russian characters.
I faced many fuckups until now (my IDE does not open files in utf-8 but Windows-1252) with file encodings, but as far I know, this mess should be unified to utf-8 in Java 17 (or a version near there).
Has anyone an idea how to deal with that, and getting a well working distribution? I would also prefer to pack it with an own jvm, so I do not need to care about the user has already installed Java.
It seems I fixed the russian character issue by adding -Dfile.encoding=UTF-8 as jvm option. I wonder a little why this helps, because this should be the default behavior, but ok.
Edit:
But nevertheless, I would like to know how to include an own jvm to my project distribution. If somebody has a hint about this, would be very nice.
It is a bit more complex.
Since Java 18 the default encoding in Java is UTF-8.
This also applies to things like calling javac and so on.
But if you execute Gradle with Java <18 and just have Java >=18 used as toolchain, then afair this new default does not kick in, but the default of the Java that is used to run Gradle is used.
So safest is to still configure the relevant Gradle tasks that the source encoding is UTF-8, or using the big-hammer method that you used that might also have other side effects though.
As far as I remember, there are also some Gradle plugins out there, that configure some task types to use UTF-8 like JavaCompile tasks and JavaDoc tasks. But I don’t remember which one exactly it was and whether there are other tasks missing.
Thanks…if the raw hammer works, I think it should be fine at least for now. As far I see, the program is ready and I try to publish at first time a program (good test track for my other project). Because it’s ready I hope it does not suffers by effects.
For my other problem - bundling a jvm with my application - I think I have a solution. JLink (I know it is not really new, but for me my first time), or as gradle plugin this here: https://badass-jlink-plugin.beryx.org/releases/latest/
But I fail here, it seems I’m not skilled enough to declair a module file. I tried everything, including both runtime and jlink badass plugin, with unnamed module, nothing works. With module, I hang on an error “doubled module in application path” (translated from german, the original message may differ in english).
Be aware that you then make your distribution target OS specific.
And be aware that the two badass plugins are unmaintained.
If you are not using JPMS anyway for your application, you should not use the jlink plugin, but the runtime plugin.
The jlink plugin is for when your application is a JPMS module itself.
The runtime plugin is for when your application is not a JPMS module but you still want to use jlink to produce a shippable runtime.
The plugins work still, even though they are unmaintained, but they could of course make problems with upcoming Gradle versions, or already not properly support some things like configuration cache.
I try the runtime plugin again, but there seems to be a fault. I get always this message in powershell:
Directory ‘C:\Program Files\AdoptOpenJDK\jdk-15.0.1.9-hotspot’ (Windows Registry) used for java installations does not exist
Directory ‘C:\Program Files\Java\jdk-14.0.2’ (Windows Registry) used for java installations does not exist
I have never installed Java 14 on my machine, that’s right so far. I have jdk8, 16 and 21 here, so what went wrong here?
Ask the plugin maintainers?
From what you showed, I’d guess you did have those JDKs installed and they are still noted in the Windows Registry but not found on disk anymore.