We are probably not talking about the same applications then... Look at "azureus java" or "azureus screenshot" on Google Images and tell what reminds you of Eclipse from that.

I couldn't disagree more: I've been doing SWT development for many years, and I can tell you that SWT applications are impossible to distinguish from native applications, on any platform. Sure Eclipse looks like nothing but Eclipse, but if you take well-written SWT applications (Azureus for instance), no-one would be able to tell you that it is made out of Java. From a user point of view, SWT is just invisible. On a programming point of view, I would agree though: SWT is extremely low-level and the first think you need to put in place is a higher-level API. It has nothing to compare with Swing, which is a real pleasure to develop with. SWT is a pain in the ass, difficult to extend and very difficult to use. So it really depends what matters more to you: the integration of your application with the user desktop and preferences, or the convenience of the development framework itself? One of the (many) reasons why Java never really took off on the desktop is because, unfortunately, many developers chose the latter.

Well it depends, observe how the package explorer tree is actually the native tree widget. How the tables are actually native tables with proper look&feel for the sorting and column resizing. Observe how the menu bar on OS X is actually properly positionned. Observe how the buttons in the configuration sreens, all the scrollbars are native. Notice that drag&drop from and to the desktop or the Windows Explorer actually works, and also proper copy/pasting of files from external applications. These are all these smalls details that make a big difference at the end of the day.

Note that in Java you can get something similar by using SWT, which uses JNI to call the native underlying platform widgets. Used by Eclipse but can be used in a small standalone J2SE application. http://eclipse.org/swt/

Fixed it for you. This represents roughly 0.5% of the World's population. The Internet is meant to be also relevant for the remaining 99.5%...

This requires self-signed applet with full privileges so by using this new security solution I will put my computer at risk. Isn't that great? I would have expected that people working in the security domain would not have the "I don't bother about actual rights I need so let us request full access" attitude.

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.