11 ms·
We build all our desktop products using Swing, and it works pretty well. Looks pretty native (if you want it to), is thoroughly battle-tested, reasonably perfor
by grandinj 6y ago
We build all our desktop products using Swing, and it works pretty well. Looks pretty native (if you want it to), is thoroughly battle-tested, reasonably performant, and has a bazillion open-source extras floating around (of varying quality).
If you need 3d, we drop into OpenGL and use that (e.g. when integrating WorldWind).
Sometimes I feel bad about how easy it is to write desktop UIs in Java - the API is stable, nobody keeps changing it under me, I don't have to wonder what Microsoft is pushing this year, it is (mostly) easy to debug, has open source forms designers (Netbeans), etc, etc.
- MaxBarraclough 6y agoDo you plan on trying JavaFX?
- grandinj 6y agoSigh. I had such high hopes for it, and then Oracle abandoned it. But we are trying it, and opinions (internal to my company) are varied. Some people like it, but I don't. Because (a) it has missing functionality here and there (b) it still has a long road to go to become battle-hardened (c) I don't see any of the current supporters having deep enough pockets to fix (a) and (b) So we're taking a mostly wait-and-see attitude. But we have an existing deep and wide investment in Swing in our products, so our risk profile is probably somewhat different to yours.
- apta 6y ago> Sigh. I had such high hopes for it, and then Oracle abandoned it. As far as I'm aware, it was only pulled from the JVM into a separate dependency, as did several other components, in order to keep the JVM slim. Are you saying development on it stopped altogether?
- grandinj 6y agoOracle has mostly disbanded the team that was working on it, leaving only one or two staff to manage community contributions. There are however, a couple of small companies, and some individuals using it, and providing contributions.
- usrusr 6y agoSometimes a setup like that is the best setup possible, no ambitious team trying to make their mark by replacing something that doesn't require replacing or that they can't replace well enough. I doubt that JavaFX would have more impact if they put a team of dozens on it (or, shudder, hundreds) but they would surely make life harder for those who still build on FX. A larger team might have already declared javaFX dead entirely, urging everyone to port to some exciting new javaFY and losing many of the remaining users in the process, without attracting any new ones. Arguably Swing to FX was already a bit like that.
- vips7L 6y agoAs far as I know Gluon has taken over the development of JavaFX.
- fayten 6y agoJavafx is very much alive at: https://openjfx.io/ https://openjfx.io/ Gluon also provides builds for LTS and latest here: https://gluonhq.com/products/javafx/ https://gluonhq.com/products/javafx/
- cmiles74 6y agoIt's not easy to get JavaFX working for development and it's tricky to get it bundled properly for deployment. I can see why they wanted to split out big parts of Java but I think it does discourage developers from using the library.
- hutzlibu 6y agoWell, the author did not say, Swing etc. does not work. But that it is incredibly hard to make a UI with it, that looks good and is performant. And this matches my experience with java 10+ years ago, when I tried it out and left in horror ... for: flash. (Flash had many, many drawbacks: proprietary, security, ... but it was really easy, to make something nice looking, that also run smooth - it was designed for that and later taken to higher level with flex)
- grandinj 6y agoYeah, your mileage may vary. I was writing UIs in Swing 10 years ago, and we managed fine even back then, but our target customer is technical people so maybe our definition of "looks good" is somewhat easier.
- hutzlibu 6y ago"so maybe our definition of "looks good" is somewhat easier." Yup, there is the difference. My target audience are common people, so I have to care more.
- AnIdiotOnTheNet 6y agoYou really don't. I interact with "common people" every single day and they couldn't give less of a shit how the UI looks as long as they can do their job or whatever it is they need the program for. The people who care about "looks good" are managers and designers because they never actually have to use the damned thing.
- hutzlibu 6y agoDepends, if you have people needing to do a (unpleasant) job, sure, they also care more about functionality, than form. Nobody cares about a smooth animation, if he cannot get his job done. But given the choice, they prefer the better looking one. In consumer facing apps much more. Especially younger people, used to shiny websites/html point out quickly, how ugly something looks. And then not use it.
- swiley 6y agoYou would have thought after 40 years there would be some standard GUI toolkit all the major OSes would adopt but stuff like swing, html, and TCL/tk are all we have... and of course vt100 escape sequences for some reason.
- barnacled 6y agoI guess not globally adopted but Qt to me is a pretty workable cross platform solution, nicely performant and reasonably easy to work with with great community support and problem googleability as well as pretty damn nice docs.
- coldtea 6y agoWell, the idea between "major OSes" is that they try/do/offer different things. And the UI is large part of that. If they all have adopted the same, we might as well use a single OS. That said, there should have been one, good, cross platform GUI toolking, and Qt, for various reasons, isn't it. The best we have is Electron...
- mmm_grayons 6y agoI think an option could be GPU-accelerated drawing. It won't look native, but one can create a UI that performs well on just about any platform. Vulkan greatly improves the portability of such applications (compared to the OpenGL vs. OpenGL ES mess), and Skia has a nice set of primitives on which one could build. It's also worth pointing out that creating a cross-platform API is better for new players than for entrenched ones.
- specialist 6y agoSwing is mostly fine. Ideologically, it's cousins with Qt. I don't think Swing's MVC strategy worked out. It was worth trying. But maybe 40%-50% of the framework could be safely removed. Some kind of DSL would be nice. JavaFX ain't it. In my own noodling, Swing's UI component hierarchy needed to be refactored to be fully composable. By the time I created enough shims to make Swing truly composable, I wish I'd started from scratch. (I haven't done Swing work in ages, so maybe this happened.) An event loop is the biggest thing missing from Swing and other UI toolkits of that era. Meaning all modifications are handled by the framework, no client code (or non event loop threads) can modify the UI. My bestie George Smith's Juipeter (?) took the Win32 API approach, preserving the Swing API and all dispatch was handled under the hood. This is kinda how a browser's event loop is implemented. I much prefer an exposed event loop and Command objects. (It's easier to stepwise debug. Every desktop app I've ever created also had Undo/Redo; so you're gonna do Command objects one way or another.) And then make the framework pretty with some kind of DSL over the top. Sadly, though inspired, I think Swing's LookAndFeel plumbing proved unnecessary. Sun believed everyone who said it mattered. Maybe it did for a while. But the world moved on. I still have no firm opinions on how I'd make an app reskinnable. (I should probably look to see what Qt's doing these days.) Edit: I didn't mention AWT/Swing layout managers. Just peeked at Google/JetBrains Compose. Meh. I like that it uses Kotlin; less syntactic vinegar than Java. Alas, Compose repeats the mistake of not separating out the layout code. After doing way too much layout code -- some Australians did a hysterical GridBagLayout rage meme video, back in the day -- The Correct Answer[tm] is custom layout managers. Still include some stock managers in the JDK. And make the layout hooks API easier to implement and debug.
- R0b0t1 6y ago>Sadly, though inspired, I think Swing's LookAndFeel plumbing proved unnecessary. Sun believed everyone who said it mattered. It maybe it did for a while. But the world moved on. I still have no firm opinions on how I'd make an app reskinnable. (I should probably look to see what Qt's doing these days.) Well, if they didn't bake LookAndFeel in from the start, all of the work would fall on the application developer to manage these things. Having had to look into doing this the way they chose is the best way, what most people have a problem with is the UI didn't look fully native on most platforms for a long time.
- cashewchoo 6y agoI have a long history with Swing and as painful as it is to use sometimes (e.g. "There are Swing developers with low pain tolerances?") it's astonishing how productive Swing feels compared to React even so many years later. Maybe I'm just warped but GridBagLayout, while containing a certain base level of frustration, is O(1) for frustration. Whereas CSS are absolutely O(n) or worse. One of the best feelings in the world is replacing a complicated nesting of buggy BorderLayouts et al with one nice (slightly verbose) GridBagLayout that actually works. In my imaginary company that I own where we all run linux laptops that are managed by puppet or something, I think we might make a strong case for building many internal tools in Swing. The biggest hurdle I see nowadays to using Swing is all about distribution: both of the jvm and the program. Imo that's really where the web won - certainly not because of its dev productivity. So it's definitely a no-go for your actual software product.... but for internal tools where you have a lot more leverage over the environment, I think it looks extremely attractive. Regarding JavaFX... Honestly, I really like it. I have a personal project that was originally in Swing and I ported it to JavaFX because HiDPI is in a lot better shape there (though I think Swing has since figured it out?). And it's a lot better in many ways. I love-love-love using SceneBuilder for designing the view layer and the Observable pattern, I think, yields a lot of nice QOL/verbosity-reducing things. That said, I think it did have a slightly higher O() for frustration than Swing's O(1). And I think the community, as a whole, just understands it less (less prior art etc). So if someone said "build a usable high-quality GUI asap or you die" to me, I'd go to Swing immediately.
- specialist 6y agoMy buddy worked on a niche volumetric (voxel) renderer for ages. I helped with some of the OpenGL bindings and plumbing. Java Web Start (JNLP) worked great. It just worked. His customers loved him. I've always wondered why something like desktop JNLP didn't happen.
- gorjusborg 6y agoI owned development of a JNLP app around a decade ago. JNLP did a good job of solving the app distribution/update problem, but required that you already had the JRE installed. Not too much different from assuming a browser is installed, but I found it much less likely that a user would take the initiative to install a JRE than a browser. They just don't understand what they are doing or why in the case of the language runtime. That said, it did work very well, in my experience.
- alzoid 6y agoI feel the same way. I was writing a desktop Windows/Mac app using swing 10 years ago. The look and feel that came out of the box was fine. At first it was metal. It was a light blue with gradients to white on the buttons. Then they came out with Nimbus - I think that one was based on SVG or something similar. No client complained about either of those. And at the end of the day you could always call a method to get the platform look and feel and it could look like Windows or Mac OS. I had a menu to change this in the app itself. I never found the UI development hard. I was hand coding it in the beginning. I thought the Layouts were pretty straight forward (except grid bag which I never used). Eventually NetBeans had a decent UI designer and I used that. I think the sloppy or slow UI's came from developers who never took advantage of the Observable / MVC aspects of the UI components.
- abraae 6y agoFunny. We just built it new platform in gwt. It's an unashamedly retro approach but there's a lot to be said from using Java on the front end as well as the back. Productivity was really high.
- splittingTimes 6y agoIndeed. JavaFx is not to slow to build RealWorld GUI Desktop Apps. Here is an example of a Desktop CAD/CAM Application for Digital Dentistry written in Java using JavaFx and OpenGL. It is smooth and performant, otherwise noone would use it. https://youtu.be/36dWOXyQWmo?t=124 https://youtu.be/36dWOXyQWmo?t=124
- avseq01_dat 6y agoDo you know how could they integrate OpenGL context with JavaFX? I tried to do the same few years ago, couldn't find a reliable way.
- ptx 6y agoI've wanted to use Swing (I kind of like the old-school metal L&F) but my issue with it is the glitchy-looking result, the opposite of Wayland's "every frame is perfect" motto. When I tell Swing to display a simple window with some simple widgets, it will 1. First display the window in some random place on the screen, 2. Then move it to the position I actually specified. 3. Draw all the widgets with a slightly wonky layout, 4. Then erase the widgets it just displayed and redraw them with the correct layout. This happens in every Swing app I've ever used when opening a window, even IntelliJ. (The glitching window position is not always observable.)