Replace AWT-based GUI
PatrikScully opened this issue · comments
Migrate the existing Java AWT-based GUI framework to JavaFX for a more modern and maintainable solution.
The current implementation relies on the Java AWT library, which is considered deprecated and lacks the features and flexibility offered by JavaFX. This migration aims to enhance the user experience, leverage JavaFX's rich set of UI controls, and ensure compatibility with modern development practices.
This would solve the #1324 issue too, because now the GUI doesn't support the MacOS application bar.
Thanks for opening your first issue here! 😃
Please check our contributing guideline. Especially when you report a problem, make sure you share a Minimal, Complete, and Verifiable example to reproduce it in this issue.
JavaFx is not part of JDK. So how it is supposed to work?
That is a yes and no depending on java usage. With java 8, 9, and 10, javaFx is certainly in the jdk. It was only removed afterwards. See https://www.infoworld.com/article/3261066/javafx-will-be-removed-from-the-java-jdk.html.
However this is no different than any other library, it would get bundled up for usage.
I would though suggest we do not do so in spotbugs itself. If this were to be done and I agree it should be, we should cut a new repo 'spotbugs-javafx' and let our internal gui just become deprecated for some future removal (probably years from now).
As it stands we are still supporting java 8 at the moment and it wouldn't make sense to do the work based on the jdk copy given how old that is at this point. I'd go as far as to state we wrap spring boot around it to handle the crust of libraries, configuration, etc and obviously on jakarta namespace so spring boot 3 and java 17, maybe even go right to 21 given how javafx progresses side by side with jvm.
The hard part would be who does the work. I've barely touched javafx myself other than trivial update of versions and not sure who has that expertise that would even want to try that out that is on our team. I would think it should not be done at spotbugs at all at first. Someone should do that on their own repo, prove it works, demo it to us, if we like it, they could transfer it over to us. Aside from that I'm not sure this would move fast.
My understanding in general is that AWT was the oldest, then came swing, then swingx, and javafx is really just swingx evolved if I'm not mistaken. So its a big leap. However, quick google seems to imply its not that difficult.
@Spatrik95 Is this something you know how to do and does any of what I noted even sound remotely feasible or accurate ?
However this is no different than any other library, it would get bundled up for usage.
Oracle licensing is sometimes very surprising, so one should check first if bundles are allowed, and if that applies in general or only for private use etc. Don't forget the mess with JDK licensing...
With java 8, 9, and 10, javaFx is certainly in the jdk. It was only removed afterwards
Yes, so none of modern JDK ditros contain JavaFx anymore.
Anyway, not sure if we should simply remove AWT related code. Last time I've tried Findbugs GUI (long time ago), I believe it was Swing based, so AWT must be really something ancient.
@Spatrik95 Is this something you know how to do and does any of what I noted even sound remotely feasible or accurate ?
I built a JavaFX application with JDK8 a few years ago, and I think it's quite good for a small one-window application like this one. That's why I suggest this library. You can build UI components with an XML or a standard AWT/Swing way. (build UI objects and pass them to each other)
I would though suggest we do not do so in spotbugs itself. If this were to be done and I agree it should be, we should cut a new repo 'spotbugs-javafx'
Do you mean that the GUI part could be totally independent from the core of the SpotBugs? I didn't analyze the dependencies, I just see that the GUI is in the main spotbugs module.
However this is no different than any other library, it would get bundled up for usage.
Oracle licensing is sometimes very surprising, so one should check first if bundles are allowed, and if that applies in general or only for private use etc. Don't forget the mess with JDK licensing...
With java 8, 9, and 10, javaFx is certainly in the jdk. It was only removed afterwards
Yes, so none of modern JDK ditros contain JavaFx anymore.
After Java 11, Oracle passed JavaFX to the community, so it's totally open source now. Here, you can find the license, or on the official website.
Here, you can find the license
So this can't be part of Spotbugs distribution, as it uses GPL and would force Spotbugs to use GPL too, which is not acceptable.
Then I don't have a good idea for the replacement for the gui module because the Java-based solutions are quite deprecated, only this OpenJFX project is currently alive and was created to replace this AWT/Swing way.
Maybe if it's migrated to another spotbugs-gui project, we could migrate to another, but currently supported and popular technology or language as well (for gui development), for example, a web-based Electron app, Flutter, or .NET MAUI.
I'm not sure if it's correct that AWT (or rather Swing) is deprecated. There seem to be at least bugfixes going on (looking at the openjdk repo here: https://github.com/openjdk/jdk/tree/master/src/java.desktop)
Latest update I've found was from May 2020 when Oracle reaffirmed that they're supporting it:
https://www.oracle.com/technetwork/java/javase/javaclientroadmapupdatev2020may-6548840.pdf
AWT has been an integral part of Java SE since its launch in 1995. Swing was introduced shortly
thereafter as a separate library and finally incorporated into “J2SE 1.2” in 1998. Both toolkits are part of
the Java SE Specification and core to many other toolkits and applications that build on top of them.
Oracle will continue developing Swing and AWT across all supported releases as a core Java SE
technology.
If you want to build an OpenJFX GUI for SpotBugs, by all means go for it, but I don't think it is necessary.
Probably there's a way to have a Swing menubar on MacOS without rewriting the whole thing.