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.
I 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.
I'd strongly recommend looking at miglayout [0] if you have to do another UI in Swing (haven't tried it with JFX). It's pretty much the best layout library I've seen, bar none, for developing UIs in Swing. You can think of it of GridBagLayout on steroids, and it even handles things like reordering buttons on a per platform basis (eg. Ok and Cancel on a dialog are in Ok/Cancel order on Windows, Cancel/Ok on Mac).
I 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.
I'll echo this. I owned a jnlp app, and most of the support we had was around walking people through installing a sufficiently correct jre. Not always easy to do that
When I was developing a Swing app, I ended up just distributing an NSIS installer that would automatically download and run the JRE installer if Java was old or missing, for that reason.
I am about 90% sure there was some sort of 3rd party open-source wrapper that would download a jre. But I cannot remember what it might have been called
When you're distributing a real installer with a swing app, including a copy of the JRE is definitely the thing to do.
A jnlp app is a file format that defines how to launch a java executable over the internet. It defines the location where the executable is, and what version of java is required. Opening the jnlp to download and launching the app requires an installed JRE, or there is nothing to interpret the jnlp and go get the application.
There is, iirc, a utility that will wrap a jnlp file and go get a jre. I forget what it's called, but it makes jnlp apps more like an auto-updating standard app.
The benefit of the jnlp approach is if you can guarantee your users have java installed, then they don't need to install your app. Just click a link, then a java app self-downloads, installs and sets up a shortcut on the desktop. And it updates whenever they open it and a new version is detected.
I hear Java GUI has supposedly gotten better, but all of the Java GUI apps I see look awful. For instance, try telling that to Ghidra and it's butt-ugly text that shows up super thin on my hidpi display. I like Ghidra, but for a graphical RE tool, Cutter is so much prettier with its QT interface. Of course, r2 is great and works from CLI.
I say that some who likes Jetbrains and buys their products:
No one in his right mind loves the UI of Jetbrains Apps and the Linux experience has always been a shitshow unless you were using Gnome or KDE. Because Swing does not implement the XWindows protocol properly. So yeah, a great team can still make a functional app with terrible GUI technology -- but there is a world of a difference to something that's really polished, fast and enjoyable to use.
I think IntelliJ has the best UI of all IDEs I've seen, it sure as hell beats Visual Studio (the paid one), it beats Netbeans, Eclipse.. What else?
VsCode and atom are simpler, but they just don't provide UI, for many setting you have to go to config files, and some functionality is missing outright.
Jetbrains products are my preferred choice for full-featured IDEs, but this is not exactly an industry renowned for producing snappy and pleasing interfaces. And since LSP has narrowed the gap, most of the time I don't require the features that would make up for the bad UX so the majority of my coding happens outside an IDE.
MacVim is my favorite when it comes to UX. It starts instantly and stays fast even on huge files. It's very customizable and works exactly how I want, including the layout of nested horizontal and vertical split panes.
I like being able to configure just about everything in just a single config file, but still getting an additional escape hatch for overriding OS default keybindings I want to use.
People love IntelliJ despite Swing because its other qualities make up for the slightly off-looking Swing font rendering, the glitching Swing layout redrawing and the glitching Swing window focus.
Also, the menu bar in IntelliJ was reimplemented from scratch to make it work properly. The Swing menu bar would have been unusable with its broken handling of submenus.
Really? I love eclipse. Though not as much as I used to.
I suppose preferences here are at least partially determined by how you think about software project management. Eclipse makes perfect sense to me, and has since the first day I used it. IntelliJ is obtuse and odd and ... wrong to me.
Swing 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.
>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.
Honest question: can someone explain the focus a lot of the HN crowd seems to have on "native"-looking UI? I've used plenty of applications that don't look "native" and it doesn't bother me. Is there a reason to prefer it? I get that performance can be an advantage, but one can easily write a very performant application using something like Skia, or doing one's own GPU acceleration, without having any native look.
There are a few reasons to prefer a native look and feel.
One is that if the look and feel of an app is native to the platform then it can lean on a design language that users of the platform assume, which makes it easier for those users to understand how to use the UI. Affordances look and act the way they expect, which reduces the time and effort it takes them to learn a UI.
Another reason to prefer it is that a UI that doesn't look native stands out as different. Noticeable differences are information. If something in a UI gets your attention, it should be because it's telling you something meaningful. Gratuitous differences from the platform's UI standard are not telling you anything meaningful, so they're just noise.
A third reason is that native platforms provide their native looks and feels through standard frameworks that also provide substantial whole-system features beyond just making things look alike. For example, Mac users can rely on a common set of keystrokes to do the same things across almost all applications (and the exceptions are badly behaved). UIs built without the platform frameworks must either recapitulate all of these platform-wide conventions or just ignore them. Commonly, they just ignore them, which means that conventions that users take for granted stop working in some apps for no good reason.
Back in the day in Unix desktop land there were 4 or 5 different UI toolkits and they looked behaved in a massively different way. X looked like ass. QT looked less like ass but had totally overloaded UIs. The differences were even starker on lower-res displays.
Also back then browser apps were a novelty instead of how most people interact with computers most of the time, and thus anything that wasn't using a native toolkit stood out pretty bad. A few apps like MP3 players used it for their advantage, but I remember those as being mostly a confusing mess.
More importantly, font rendering has improved incredibly and most rendering looks the same across toolkits in the same desktop environment. Back then some toolkits supported antialiasing, some did not, some had godawful rendering that looked like crap, some couldn't render certain symbols correctly, some didn't have good hinting for LCDs, etc.
The reality is that very slowly most UI paradigms have converged into a few well-established patterns (no more multiple-window apps, no more focus-follows-mouse, no more deep right-clicked context menus, etc). So now the styling differences are more apparent but most UIs are functionally the same nowadays.
The same could not be said 15 years.
We have come a long way; despite the different looks, the feel is much more uniform, and there's a better understanding of what makes for good UIs.
As I write this, I'm frankly quite thankful that we have reached this state of good-enoughness. Spending hours looking into GTK themes and different fonts was fun, but in a frustrating way in which no exact font-icon-theme combination was entirely satisfactory.
It's a fantasy problem. Hold on before you downvote folks and count the number of 'native' applications that were written since year 2010.
Most consumer applications are now webapps or electron apps. From accounting software to music players, they are not native.
If someone botheres to make a desktop app, you either have proffeshionals tools or resource intensive applications like Adobe Photoshop, Blender3D, 3Dmax, IntelliJ IDE's and Games. None of them look native either!
Almost noone bothers to develop platform spesific apps, and native applications are dying. If we don't stop squabbling about native look and feel, we will get no native applications at all.
> Almost noone bothers to develop platform spesific apps, and native applications are dying. If we don't stop squabbling about native look and feel, we will get no native applications at all.
Well, unless you're talking open source tools and/or everythign within the sphere of desktop productivity . Then invariably your "consumer" desktop apps of choice are some mixture of GTK2/3, Qt, Swing, WxWidgets......
Granted, the different GUI libraries and applications using them tend to have _slight_ inconsistencies (GNOME 3 / GTK3 window titles versus everything else's window titles), but for the most part they're consistently themed, they render quickly, they behave the same way with the clipboard, mouse interactions, element focusing, keyboard shortcuts, accessibility functions......
So I have open right now LibreOffice Writer, Firefox, Evolution, many gnome-terminals, Transmission BT client, GNOME Files, GNOME Boxes... all of which look the same and there's no cognitive load spent switching between them, because they behave the same and look the same.
I can open up Inkscape and GIMP and Evince and KeePassXC and VLC and retain that experience.
Meanwhile, whilst still my IDE of choice, my PyCharm (so, JetBrains) IDE windows do whatever the hell they want (STOP STEALING FOCUS!!!), glitch out rendering, look completely different. And Spotify - gets all its points docked just for how it handles tabbing through UI elements. ("No, I don't want to tab through ALL of the Discover page, I want tab to cycle through the different UI elements, preferably not taking a painfully long time to reach "search".... Ugh fine, CONTRIBUTE TO MY CARPAL TUNNEL THEN!!!)
"Native" (as in, "consistent experience across the whole suite of desktop applications") toolkits still make it way easier for _developers_ to design applications consistent with the rest of the system.
Android and iOS UI toolkits serve same useful purpose. I tend to find that apps that are just a reactive web framework in a fullscreen frame are pretty painful to use. Like, wtf are you doing when I hit back!??? Why is this full screen splash form with two text boxes SCROLLING when I touch it???
tl;dr of my rant: Goddamn people stop trying to make your applications look the same on every device and let me use it how I like on MY device, for the same of a) my wrists and b) my attention deficit brain
I think Android and iOS killed the idea that you're ever going to be able to use a bunch of apps that behave consistently, because nowadays you're always using apps on at least two different platforms (phone and desktop). And it's far more important that Discord on my phone should look and feel like Discord on my desktop than having it match my other phone apps or my other desktop apps. So people have got over the idea that the platform is important and that apps need to match the platform conventions (rightly IMO; the platform is there to support the applications, not the other way around - of course it would be better if the platform makers could come together and agree some consistent cross-platform UI conventions that every app could use everywhere, but they didn't, so here we are).
If an app follows the UI conventions of the system it is running on, there is less cognitive overhead for users. However, with the rise of web apps users have at least become a little more used to interacting with a variety of UIs, though the problem is not entirely eliminated.
We've also eliminated a ton of crappy UI conventions and settled on some common paradigms in all platforms. I remember the four-layer-deep right-click context menus and I kinda shudder now.
There were also some really good ideas that I wish had caught on (I was a huge fan of focus-follows-mouse and I still use the X select-into-clipboard), but the general uniformity of UI patters nowadays is very much calming.
Main benefit to me is deflecting spurious input. All that Drive By Management.
Instead of explaining the history of ergonomics, the philosophy of ethnography, and our reams of data from usability testing, I'd just point at Apple's Human Interface Guidelines.
In addition to Swing also Qt and Gtk spent a lot of effort on this. Not to mention browsers reimplementing look and feel of native controls (not sure if they're still doing it). So it was wider than HN definitely. Other toolkits took the native route from the other direction (eg wxWdigets I think embeds the actual native widgets?).
I remember Karsten Lentzch working in this space on the JGoodies project. I used some of his custom look-and-feels in a couple of projects... I think the had some tools to make layout easier as well.
Right you are. Wiki says since 1.2. It looks pretty good.
I just spotted JavaFX Script. Huh. This is almost directionally correct. So of course it got killed.
If you're curious what The Correct Answer™ is, imagine VRML-97 reimplemented using JavaFX Script like syntax.
Its wiki has a link to the Curl (programming language). That syntax is also directionally correct. But is also missing most of VRML's semantics.
There's also a link to the F3 programming language, aka "form fits function". Great slogan. Alas. Looks like a misunderstanding of Conal Elliot's Fran functional reactive programming language.
Oh well.
Thanks for the tip. JavaFX's Script w/ CSS was about 1/2 the solution. Maybe someday someone will loop back and harvest the good bits.
You 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.
I 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.
Well, 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...
I 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.
You're just inventing your own toolkit, which is going to end in tears for everyone since you will have to recreate every component from scratch, rediscover all the interesting edge cases thereof, fail to reimplement some expected behaviors (triple-click text selection, drag-scroll, whatever), and break every accessibility tool in the process.
I 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.
Well, 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)
When I wanted to write application, I used Swing and I didn’t find it horrible. Quite the opposite. I didn’t care about the looks, though, it was not a major concern. That was before Java 8. I could imagine that writing callbacks would be even easier with lambdas.
When people don’t laugh at Electron applications, I don’t know what could be wrong with Swing. Nobody cares about native toolkits anymore (what is native toolkit for Windows or Linux?).
Yeah well, "
I didn’t care about the looks, though, it was not a major concern"
There is the difference. This post is for people who do care about the looks. (or do care, that their users care)
Some users don't care, which is fine to serve them, what they want, but most actually do.
"When people don’t laugh at Electron applications, I don’t know what could be wrong with Swing"
People do not laugh at electron apps, because they use html which is designed for good looking.
In other words, usually much better looking.
It is just not performant, unless you use native modules etc.
And native toolkits are still a thing. Gtk for linux for example.
Personally I also care about the looks, but I prefer function over form, meaning I want a functioning app first and secondly it should look good. But I like to have both.
HTML isn't designed for good looking. The default stylesheet for HTML is impossibly ugly. Heck look at HN, hardly a thing of beauty.
However, most people do a lot of work to make web sites and apps attractive. You can do that work with Swing or JavaFX too. I've done it before, it was fine, I ended up with a modern web-ish feel to the UI.
It's native to a user's desktop full of Gtk programs.
If there were a complete Swing desktop environment, Swing apps would be native to that environment. But even Sun's Java Desktop System was based on GNOME.
> I want a functioning app first and secondly it should look good
One thing to keep in mind is that you want a functioning app first with less than great GUI but then you also want an app that is "skinnable" in other words it should be easy to replace the look and feel without having to touch the application code. CSS-stylesheets attempt to accomplish that.
Electron performance is a lot better than Swing in terms of latency and startup time. Electron may use a lot of memory or whatever but that doesn't really matter; how fast it feels to the user is what matters. Meanwhile even basic Swing applications tend to come with a splash screen like they think they're Photoshop (remember Azureus, a freaking torrent client that took about 10s to start up?).
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.
I remember how horrible Swing was 10+ years ago I ran to SWT. Along with GCJ trying to compile everything into native executable.
And even SWT was far from perfect. It is one of those thing you can immediately tell by its looks, SWT, Swing, Linux, Mac , Windows. While the looks has been vastly improved, it still remain mostly true today.
You 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.
One of the best examples of this are old POS systems, which are mostly ncurses type applications. The people that use these fly around the interface so efficiently and are very productive.
Most of those old POS systems were actually either 3270 or (more likely) 5250 applications; i.e., block mode terminals instead of character mode terminals. While the difference between block mode and character mode terminals is a fundamental technical difference, that difference impacts the UI in two major ways:
1) Most interaction is local, and therefore quick. All of the editing, jumping between fields, and even basic validation happened on the terminal itself. It was only when you submitted your changes or loaded a new screen that the server would even get involved (much like a web form without Javascript); therefore, even in an installation with a lot of active terminals, these green screen applications would be incredibly responsive.
2) Every screen and application had exactly the same user interface. Even function keys were mostly standardized (ever wonder where F1=Help came from?), so what you learned in one place in the UI would trivially generalize to everywhere else in the UI.
> Every screen and application had exactly the same user interface.
IMO this is an extremely important idea and where I think the modern GUI went off the rails. I also, think it's gotten much worse with web applications.
I agree with the Raskins' that the fundamental issue with modern HCIs are applications. A common UI context in which to run commands would be more preferable in most use cases. I'm thinking of some mashup of the normal social media timeline with Emacs M-X functionality to run commands.
Well many of these do come with their own specialty keyboards, so there's that. The display is really just a display for these: all buttons are actual physical single-purpose buttons. No mouse.
Depends, 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.
> 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.
As far as I can tell, this is a narrative that only exists in the heads of people who never have to use the thing they are insisting "look good". Sales people, managers, developers, etc.
I will accept that I'm wrong when I either experience it in the real world for myself or see some actual evidence.
"I will accept that I'm wrong when I either experience it in the real world"
Well, here in the real world, (because of the need of Windows) I just recently started to use Notepad++ again.
It really pains me to do so. The only way to tolerate it, is by removing all UI and only keeping the text. But even then some ugly, contrast breaking window pops up, when I use search etc.
So I will likely switch to sublime text (even though I only have to work on windows sometimes).
Simply because of aesthetics I choose a solution nicer for my eyes, when I have the choice, which I do.
Anecdotally, a significant number of recent criticisms towards Emacs
and vim are that they’re ugly compared to VS code — that seems
to be a solid counterpoint to your argument that among users,
aesthetics don’t matter.
There is a certain level of professionalism your UI has to reach for people to trust it. If your product looks sketchy, people will treat it as a sketchy product. And if you lock into a look and feel that is 10 years old, people may use your product but they're going to be surprised if it behaves in the most up to date fashion.
The people who care about "looks good" are also usually decision makers and funders, so yes, it does matter - regardless of your opinion on whether it should or shouldn't.
If we're talking about appeasing the bullshit gods, sure, there might be something to that but my experience is that they talk about "looks good" a lot but when push comes to shove they'd rather have something that works.
Case in point: people still use Windows, and I've never had anyone tell me it's because it looks good.
Certainly a good counterpoint! Now that I think of it, I've never heard a single person tell me they use Windows because of good looking UI!
Unfortunately the bullshit gods usually have more influence than should be allowed. But making something 'look good' in a sprint demo where the CEO is present potentially releases a lot of pressure and gives the team more time to build something that works.
Funny. 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.
Indeed. 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.
I'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.)
Sigh. 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.
> 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?
Sometimes 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.
It'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.
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.