Sure, so do you prefer a Javascript, C#, Java or Objective-C cross-platform library?

This being said, I never appreciated FSX as much as since I got my PPL license. Sure I can't see my house, but I can actually practice and prepare VFR navigations using the default scenery since the stuff that really matters to the real pilots are is there. I also bought X-Plane to compare and it failed completely: it looks prettier but I almost got lost before leaving the CTR. So I can tell you, from a pilot's point of view, FSX really feels like flying over the landscape since I can use my low-altitude map in the game (and this is my Belgian countryside, not some fancy touristic places).

It's called a Java applet: every applet either runs within a very strict sandbox (even stricter than Javascript itself by the way), or the application manifest must declare and request any further access. Even better, this is only allowed if the application has been digitally signed by the software vendor.
In practice it never worked, because:

1. 1) The default rights could be modified by the user, which meant that the vendor never got quite sure what was going to happen practically at run-time;
2. 2) As a consequence, application vendors never bothered to use individual permissions: they requested "full access right" and damnit. Even Sun (I mean Oracle) demo's do exactly that;
3. 3) Anyway, users got not idea what "accessing local files" meant, and just blindly clicked on "agree" as usual;
4. 4) And even if vendors really tried hard to play it nice, what was actually allowed by default, how to practically request additional privileges, and how to provide the signature: all these got modified through each major version of Java during the early days, and therefore everybody just gave up (even though it is very stable by now, nobody cares anymore).

You're right, but reality is never fully black or white. I'm interested into cross-platform compatibility let's say 95% of the time. But I'm perfectly ready to give up the last 5% to please the user and deliver the extra mile in term of platform integration and usesability. This is why we didn't use C# in one of my projects: we wanted cross-platform, but we then selected SWT as we knew (and it turned out the be the right decision) that at some point integration and platform-specific features would be needed.

This is the problem with Java and Swing in particular: to refuse any pragmatism and to sacrifice the end-user experience to the "purity" of the framework. "100% pure Java" is considered to be an ultimate goal within the Java community. This is weird: I've never seen such as thing as "100% pure C# code" or "100% pure C++ code" or whatever. In SWT if I want to use ActiveX on Windows I'm able to do so. Sure this will only work on Windows, but then I'm able to if-then-else my code to offer an alternative implementation on other platforms. I'm able to use application-wide menus on MacOSX. Sure this makes no sense on other platforms but again who cares? Swing prohibits this kind of pragmatism and this is one of the reason, IMHO, why Java never actually took off on the desktop.

This is the whole issue with Swing: this a wonderful piece of software, the best GUI framework I ever worked on. Really. SWT, on the other hand, is inconsistent and difficult to use, brittle at times and indeed full of dirty hacks when you look at the code. And still I'm using SWT because at the end of the day the end-user doesn't care whether the toolkit is nice and neat.

What matters is platform integration: SWT supports Windows 7 jumplists, non-rectangular windows for ages, uses the native file selector (gosh how I hate Swing as a user for this), has a decent native drag&drop, is low on resource consumption, supports other OS plugins such as Windows speech recognition etc... Most importantly, it allows you to get out of the sandbox by directly exposing the underlying platform's APIs. Want to use some Windows-specific effects such as transparency or whatever? Just call OS.sendWindowMessage and you're done. Sure this will cause platform incompatibility but the end-user doesn't care (hint: users don't care whether the application they're using looks the same on their neighbour's computer, what matters in how it looks on theirs).

Pluggable look&feel and cross-platform consistency is almost never part of any requirement, and I'll trade cross-platform compatibility for a Java P-Invoke instead of JNI anytime.

Article dated from May 2010...

Not quite. The root cause here is the thunderstorm. Famous sentence here: “There is no reason to fly through a thunderstorm in peacetime". Any pilot knows that entering a Cb cloud (thunderstorm) is basically comitting suicide. Now, if on top on that you're losing your speed indicator, then you're really fucked up, but you called for it. Losing the pitots in clear air is just annoying. Entering a Cb is suicide. Losing the pitots in a Cb is just going to kill you quicker...

You only use ONE screen? Ok... 1990 called, it wants its hardware back. I typically have my main application maximized on my main screen (Eclipse...), whereas all side applications are left on the secondary screen.

Except that most applications don't care about the kind of GPU being installed. However they care a lot about input devices, screen layout, look-and-feel, available system APIs, network connectivity and so on. All things that have been normalized and didn't change between XP, Vista or Seven making the "fragmentation" of the Windows platform totally irrelevant for >99% of developers.