[bisq-network/bisq] Upgrade JavaFX to v14 (#4242)

[cd2357]

As @ghubstan mentioned in https://github.com/bisq-network/bisq/pull/4048#issuecomment-625445260:

> JFX 14 has some leak bugfixes, but Bisq is holding back on upgrading to OpenJDK 14 until the new [java packaging tool](https://openjdk.java.net/jeps/343) is released from incubation to GA.

I hadn't noticed the packager tool was still in incubation, I thought it's GA.

Then I'd say we can put this PR on hold and have another look at it when `jpackager` is properly released.

---

Although **alternatively**, there is always the option to just move away from trying to ship native apps, an effort which binds Bisq to
* limitations and schedules of packagers
* constantly changing app signing and notariazation requirements (https://github.com/dotnet/core/issues/3943#issuecomment-576844597)
* complex distro-dependent peculiarities (#4012)
* etc

Instead, the Bisq team could get rid of that overhead and simply deliver the (signed) source code + 3 platform-dependent start scripts.

Basically all that needs to happen is
```
./gradle build
./bisq-desktop
```
Some script magic could hide away the console output, or beautify it in some way, if necessary -- but essentially its just that.

It could even come pre-compiled and pre-packaged, so no `./gradle build` is necessary -- just double-click `start.sh` in order to `./bisq-desktop` and done.

In that case, Bisq would have no more dependency on `jpackager`.

Cause sometimes a small team with limited resources has to prioritize. What is worth more investing time in:
1. optimizing for a more secure, more private, more de-centralized exchange, or
2. optimizing for a more native-looking nice app?

In fact, 2. actively conflicts with 1. because striving for 2. forces Bisq to now use 3-4 year old frameworks which are EOL (Java 10), as well as modules that have known memory leaks and security issues that have been fixed since years (JavaFX 11, which is used now).

Which sort of undermines users' security, making them vulnerable to attackers who could specifically try to exploit the known issues in these older frameworks. Best case, denial of service by finding ways to trigger high memory usage and crashing their Bisq app. Worst case, well there is always the jackpot of getting access to those juicy private keys.

So I'd say there is a strong argument to be made for prioritizing 1. above 2. and perhaps sacrificing nice double-click installers for the benefits of state-of-the-art security, reliability, performance.

Maybe I'm over-reacting and blowing this out of proportion, but I was just surprised to see how many of the current issues (UI freezing, system crashing, etc) would probably go away if Bisq just upgraded a few modules and components. Solutions are known and are out there, others have worked on and fixed and optimized things, but we're not using them.

I realize its not a simple choice to make, and there are nuances -- but at the end of the day, how much better could Bisq's trading protocol be right now, if all that effort invested in trying to analyze and fix *tens* and *tens* of memory-related issues, etc -- if even part of that effort went into for example Bisq v2. Or gRPC.

Anyway, working on this PR made me a big fan of dropping `jpackager` and native apps in favor of actually delivering a fix for these issues (upgrading to JavaFX 14 seemed to address most of them).

What do you guys think? Would you generally agree or disagree?

(Tagging @freimair since this could be relevant for security)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/bisq/pull/4242#issuecomment-625501156
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200507/4eeb7049/attachment.html>