Yes, I launched the JAR 10 times, twice I got a window opened.
I run resolution 1920x1200. Not a 4K HDPI setup though.
Yes, fonts are more normal sized when I launch the JAR, the fonts were quite a bit larger. Here's both launched side by side, JNLP (smallest dimensions) on left, JAR on right, see the difference.
That's interesting. With the .jar or .exe based launch, when you go into Configure->Configure Display Scaling, what does it show?
If you override the automatic display scaling by putting a number in there (say the number that was automatically determined), does that change the reliability of launching the program?
I just installed the Java version 10.0.2 + 13 JRE on a windows 10 computer and then installed FRP version 04-12-16.
With that setup, I was able to reliably launch and run the program multiple times. So on some systems at least, the program seems to run reliably with Java version 10.
I'll dig some more to see if I can find any other reports of the issue you're experiencing.
It looks like getting the program to work perfectly with Java 9 and later versions is going to take some work.
First, I found and reported an unrelated Java 9+ bug that shows up in the program's report printing functionality. The folks maintaining Java have reproduced this bug, so I'm hopeful it'll get fixed in an upcoming release.
Second, I'm pretty sure your startup issue is also a Java bug. I was able to reproduce it fairly reliably by creating some extra background CPU loading threads. It looks like a thread lock condition in Java's core code. I can make the problem go away by adding a Thread.sleep() at the right place, but of course, that's a lousy solution. I submitted a bug report for this with code that reproduces the problem somewhat reliably, but the bug hasn't been accepted yet, so I'm not sure if the Java maintainers will be able to see it. I'm still investigating workarounds that are more robust than adding sleep() calls.
Finally, Java 9+ versions changed the way Java DPI scaling works and I suspect there are a couple of bugs in that code too. My code can optionally do its own DPI scaling and that functionality has been working well for several years. The trouble is that Java's new DPI scaling messes up a few of my layouts and they'll be kind of tricky to fix without making them look ugly on Java 1.8 systems. This is still a work in progress.
So the short answer is that for now at least, the Flexible Retirement Planner runs best with Java version 1.8.
Interesting, thanks for the update. Maybe I'll drop back to latest 1.8 for no. Just feels like that is pretty old at this point, and it *should* be better to be more current, for security / hacker reasons. But if apps aren't going to work right with the newer version then that's a big problem.
From a security and stability standpoint, I think 1.8 is a perfectly robust approach for now. Java 1.8 will get security patches until at least the end of 2020, so that isn't a concern.
Also, in desktop environments I'd guess Java 1.8 has a much larger installed base than all new releases combined. You'll notice that if you go to Java.com and ask to install Java on your computer, by default, the site gives you Java 1.8.
Post Java 1.8 releases come with some changes to the licensing and support arrangements and the model for ongoing Java support is changing quite a bit for commercial users. It'll take a while for the user base to get comfortable with all this, but given time I think it'll all work out and we'll all eventually get onto the latest release train.
The Java community is very robust and vibrant and it's still growing and we certainly don't have to worry about Java going away any time soon.
Just a quick update to this thread for anyone following along.
I got an email today from the Java maintenance team that they successfully reproduced the bug I reported that was causing the main program window to not appear intermittently when using Java 10 or Java 11. They've assigned an official bug id to the problem and it will get tracked in their bug tracking database. This second bug is a thread lock condition that seems to involve a Java class called HTMLDocument (the first bug was also reproduced and assigned a bug id as indicated up thread).
While there are no guarantees about when these bugs will get fixed, now that they're officially on their radar they're both very likely to get fixed in a future release.
For now, the suggestion to stick with Java 1.8 holds. However, with some luck both bugs could be fixed in the upcoming Java 12 release which is planned for March 2019.