Java Swt

The Java Standard Widget Toolkit (SWT) is part of the EclipseIde, an alternative to JavaAwt and JavaSwing. (I.e., "standard" refers to "The nice thing about standards is that there are so many to choose from.") Effectively, if there is a native widget, it's used (the common ones at least), otherwise it's emulated. Much faster than Swing, more elegant than AWT.

Now, if only I could use a good ol' awt.Image in it without the 50 lines of translating code.

Relevant Comments (extracted initially from EclipseVsIdea)

Don't get me wrong.. I think JavaSwt was a HUGE mistake of the NIH variety and I sincerely wish it would somehow get retracted. SunMicrosystems originally did this in JavaAwt and they paid the price, then invented JavaSwing; SWT pales in comparison to Swing and splits the Java developer community in a way that must have Microsoft salivating.... and quite honestly, IBM is not such a great company to work for for those over 40 or those prone to getting cancer, if you believe the newsgroups, but nevertheless, Eclipse is snowballing in a way that has to have the CEOs of other IDE makers staying up late trying to map out how to dump their stock and not have it seem suspicious.

Well... I'd rather work with SWT any day of the week. AWT was a failure because it got rushed. E.g.: my touchpad driver does some ugly things to emulate scrolling... ugly things that do work with windows apps, effectively anything using a native widget. The emulation works transparently with SWT. Swing, on the other hand, sticks out like a sore thumb. Swing is itself a NotInventedHere error: why would anyone want a window system which has zero integration with which ever windowing system is native to the host?

RE: "why would anyone want a window system which has zero integration with which ever windowing system is native to the host?" - an initial hypothesis would be: anyone who wants a window system that is consistent across platforms independent of the host. In this sense, at least, JavaAwt and JavaSwing would better meet the 'WriteOnceRunAnywhere' philosophy.

Ideally, such a tool should offer a choice of native versus built-in. Native usually runs faster and follows familiar conventions to OS-specific users, but built-in allows consistency and reduces platform-specific testing.

"Ideally"? - I'm not so sure. If all you had to do (to bounce between native and built-in) was flip a switch based on some configuration bit in a registry, that'd be fine. However, this talk of "follows familiar conventions to OS-specific users" has me worried a bit. I may be reading you wrong, but the users of the tools discussed here are the programmers. If it is the programmers following "familiar conventions" because the tool offered said choice, that might conflict with Java's own 'ideal' of WriteOnceRunAnywhere. Sometimes ideals do conflict (e.g. security and freedom), but there's a clear choice to be made here (in the context of Java): 'ideally', such a tool shouldn't make it easy to make platform-dependent code by accident. Am I misunderstanding you?

anyone who wants a window system that is consistent across platforms independent of the host

This is where the interresting discussion begins: who wants that? The programmers of course, because it's easier to port. But does the user wants that? Why does he care? When I'm running a Windows application (being Word or Winamp), I don't care whether the display is similar on, say, MacOSX, Linux, HPUX11i or even OS400. I really don't. So why would I be ready to accept a degraded user experience (no shell integration, no standard LookAndFeel?, no nothing) just because developers want to ease their life? This is the same question with WebApplications. This is so easy to maintain, this is so easy to port, no upgrades to be pushed on the client side... But did anybody thought about asking the users whether they liked it or not? (in the context of Java): 'ideally', such a tool shouldn't make it easy to make platform-dependent code by accident.

As for any tool, it should do what it is intended to do, and it should help you deliver the product that the users are expecting. No more, no less. I think it is perfectly acceptable to design a Windows or Linux-only Java application that won't even start on the other platform. Why not? If the requirements contain very deep platform-specific features, will you drop Java just because you won't be able to make it cross-platform? If I want Java for its security, maintainability, library etc, but if I don't care about portability, then I most probably require the tool to make it easy to make platform-dependent code, by accident or not. This is where I think JavaSwt is so great: it is so easy to port (I didn't say it was transparent), and yet it allows you to do OLE on Windows. Sure that part won't work Unix, but the remaining will, and what is portable and what is not is clearly documented.

Java was created and developed with the concept of WriteOnceRunAnywhere as a major design goal. That is what the tool (the Java language) is intended to do - to deliver the product that the users (the programmers) are expecting, No More, No Less. Therefore, it is NOT perfectly acceptable that Java make it easy to program Windows or Linux-only Java applications... especially not on accident. Something being "acceptable" is always a matter of opinion, and in this your opinion runs contrary to the opinion of those who designed Java. If you require a tool that makes it easy to make platform-dependent code, then JavaProgrammingLanguage? isn't intended to be the best tool for the job. JavaSwt is at least more portable than a hypothetical Microsoft library designed to penetrate your code and make it impossible to port, but it is still less portable than JavaAwt or JavaSwing... and, as such, is less ideologically aligned with Java.

Ideology doesn't sell. If your user base is on Windows and asks for Windows-specific features, you will provide these features to them or die. Now, if your language of choice happens to be Java, because C/C++ is a nightmare and C# is not mature enough, are you going to tell your customers that you're not going to deliver what they expect just because you're using Java, and that Java must be cross-platform and that would be a shame not to port on Linux? The fact is that, as a client-side vendor, I care less about portability than user experience. If, once I get that useability, I can get an easy port to other platforms, that's a bonus, but that bonus musn't come at the expense of my customer's satisfaction. And my customers are average Joe's, not fellow programmers. They don't even know what Java or Linux is. But they pay. The fact is that the soft is 99,9% cross-platform. The remaining 0,1% is not, but that part makes the difference. Should I drop Java to C++ just because this 0,1% seems incompatible with the so-called 'purity' of Java?

"Ideology doesn't sell" - I'm curious as to which histories you've been reading. Take a moment and look up the number one bestselling book in the world.

Ideology is certainly part of what sold Java - I remember the ads and propaganda used by Sun. The user-base of Java is programmers, who benefit from the whole idea of WriteOnceRunAnywhere. And experience proves that customers will take what you give them; if your product needs to compete on look and feel alone, chances are that you are ALREADY going to die. If you need integration with platform-specific stuff like the OS or bare metal, it can be achieved, but JavaLanguage is not designed for it. Should you drop Java because of 0.1%? probably not - in making a decision on a language, you must consider many things. As to your other point: "I can get an easy port to other platforms, that's a bonus, but that bonus musn't come at the expense of my customer's satisfaction" - that's just silly-talk. If you get more customers as a result of something being easy to port, then of which customer's satisfaction do you speak? How 'satisfied' with your product is the potential customer whose platform you can't afford to support because you made some shitty design decisions early in the process?

By the way, it is very easy to write platform-specific code in pure Java or in AWT. I got more trouble managing to get an AWT LayoutManager work consistently accross platforms than I have on SWT. And I guess everybody forgot to use the File.separatorChar at least once in their life.

Indeed. Java's handling of filenames is something that was poorly implemented. It should have utilized a filename object (more like C++ Boost's filename libs). However, I'd note that the "should have" here can only be stated as a value-judgment, and that there must be a reason behind it if it is to be at all objective. (There are no unconditional oughts.) The reason behind this 'should have' is founded in the Java ideology of WriteOnceRunAnywhere.


CategoryJava PlatformIndependentGui, BuildJavaGuiBrowser

EditText of this page (last edited October 4, 2007) or FindPage with title or text search