Header of the notification message doesn't show app name on Windows-11 about fxtrayicon HOT 11 CLOSED

Actually, the issue is on Win-11. On Win-10 here is the screenshot which seems ok. It correctly displays my application's name.

I am going to change the issue title accordingly.

from fxtrayicon.

@hrzafer that's very interesting that you got different results under Windows 11... are you using the same version of Java on both versions of Windows?

from fxtrayicon.

from fxtrayicon.

@hrzafer - That is VERY interesting ... Java must make calls to the same windows libraries in each case, but the Windows 11 library was obviously changed without proper change management oversight... seems odd for Microsoft to be careless ... but it might be something that will need to be brought to their attention as I can't see how it would Javas responsibility to work around what they assume will work as originally designed by Microsoft. Java is doing nothing wrong to cause the anomaly - which is evidenced by the fact that you are executing the code under the exact same JDK.

On a side note ...

I just recently moved out of the Java 1.8 'safety zone' and am close to a solid first release on my first Java 17 project. The learning curve wasn't so bad once the whole modular concept finally clicked ... What I can't seem to do yet, is actually create artifacts that run. Some of the reading I've done on jpackage has been... well ... clear as mud but I haven't really taken the time yet to dive into it. I've never used jpackage before so it'll be another learning curve.

Any advice on what I should read ... or perhaps some examples I could look at for packaging relatively simple projects into self-sustaining apps with installers for the different OSes?

from fxtrayicon.

Actually, you don't even have to make your app modular. Also you don't need jpackage as well. You can use maven-javafx-plugin and mvn clean javafx:jlink will create a cross-platform custom JRE.

There is another maven-javafx-plugin which can create native installers. Which is essentially a wrapper around javapackager

But I use this plugin jtoolprovider-plugin which is a wrapper around jpackage.

Finally, there is native-maven-plugin.

I still don't know which option is the best though. Also, I think there also similar plugins for Gradle if that's your preference.

from fxtrayicon.

@EasyG0ing1 , I just realized that the problem only happens when I'm running the app directly from IntelliJ. If I use the installed version which was packaged as msi, it works fine.

from fxtrayicon.

@hrzafer Thanks for the info on the installer wrappers, I'll check them out and experiment.

And Gradle? I'm not a fan of Gradle ... Maven has always seemed to me to be much more concise and easier to use.

Also, interesting about the fix for the Windows 11 issue. I would file a bug report with JetBrains as it seems like it's an issue with the IDE.

from fxtrayicon.

@hrzafer - I rad most of the documentation provided on that jtoolprovider plugin and all I can say is ... why is it so freaking complicated to compile a Java program? It's on a level of absurd borderline obscene how monumental of a task it is.

from fxtrayicon.

Closing as this appears to be related to build tool rather than library itself. Please re-open if not in agreeance.

from fxtrayicon.

I just ran into this same issue, but for me it's happening even when compiling to a jar and running outside of intellij. I'm just using standard Oracle OpenJDK 17 not a custom version or using any msi installers or anything. Anyone else happened to look at this anymore and figure out what might be happening? I'm guessing it's something to do with running it through Java not as a stand alone or something.

from fxtrayicon.

@steven6282 - When you run a program from IntelliJ, in the output at the bottom of the screen, that first line will be the line that IntelliJ used to run the code ... if you copy that line into a text editor, then break it down ... I usually do a search for space dash and replace with a hard enter then a space dash - and I also look for :/ and replace with :<enter>/ so after doing all of that, it becomes a somewhat neatly formatted command line so that you can look at which dependencies are being injected into the classpath, etc., and it MIGHT give you some insight as to running a compiled .jar version of the code where you can control the classpath a little better and make sure everything is pointing back to the native SDK / library source paths wherever possible.

Initial thoughts are that "getting back to basics" as much as possible would be a good first effort at finding a workable solution.

from fxtrayicon.