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?
- Why should you be ready to accept a degraded user experience? because the alternative is often to go entirely without the experience, or to pay considerably more for it. It's that simple. Are you willing to accept a complete lack of said application for <your platform of choice here>, or to pay 3-4 times as much for it, because the developers can't easily port it? If <your platform of choice> has a monopoly and is always the first to receive development, perhaps you consider the question irrelevant - you can say: "I don't care, I don't care, I don't care" like Philippe does here. But all the other potential users "care" about portability, and really "don't care" for the sort of snub arrogance shown by the people who dismiss other platforms with a smug wave of the hand.
- So what you say is that applications written in Swing are better and cheaper on the client side? Please name some. Popular web browsers are not written in Swing. Popular FTP clients are not written in Swing. Popular InstantMessenging? tools are not written in Swing. Popular mail or news agents are not written in Swing. Popular RSS aggregators are not written in Swing. Popular text editors are not written in Swing. Popular media players are not written in Swing. Actually I'm not even able to think of any popular application that comes with a Swing-based UI. And if I remember correctly, the only popular Java application that made its way to the desktop is Azureus, using... JavaSwt. Call it arrogance if you wish, but as a user (and most specially when I'm a paying user), I don't accept that the product I'm using is deliberately ignoring my platform of choice. Arrogance is when hardware vendors don't consider Linux when creating their drivers. Arrogance is when a web developper is assuming everybody's using InternetExplorer. Arrogance is when a software vendor doesn't care about what the users want or like and are imposing their GoldenHammer to everybody.
- I made no judgment about Swing. I answered your question: "why would I be ready to accept a degraded user experience?". That question can (and should) be answered on far more general principles than Swt vs. Awt vs. Swing - it's a question of economy of customization vs. mass production. Why should you accept a mass-produced car rather than one hand-crafted to your taste? because it's cheaper, and you're more likely to get a car. Why should you accept a degraded user-experience with less integration with your personal environment? because it's cheaper, and you're more likely to get access to the software. IT'S THAT SIMPLE! And users show 'arrogance' when they expect developers to cater to their tastes at the expense of other users. That is also very simple.
- When the vast majority of your customers are requesting something, the sane business approach is to deliver the feature, not to blame them about not respecting the 5% other users that don't share their preferences.
- Sure. But don't forget the 'potential customers' in that list. You keep alienating 5% of the customer population, and you'll be whittling your customer base down to 95%, 90.25%, 85.7%, 81%, ... also not a sane business decision.
- Anyway, I'm not ready to accept to drive a car that needs 25l/km just because the designers decided that it would cost less to design a car that is both able to road the highway AND ride offroad. I'm not ready to accept driving a right-wheeled car in Beligum just because the english factory though it would be more cost-effective to create one single model for the whole world. You design software based on your intended audience. And, I'm sorry, but mass-market entry software users are on Windows, so you must take this fact into account if you intend to enter that market. By the way, the customer never shows arrogance. The customer is giving you requirements.
- If you honestly believes the customer "never shows arrogance", you've probably never designed a product for more than one customer... or sat in on a design of such a product (e.g. the standardization of a protocol or programming language, or even the stop signs at an intersection). Once politics and different motivations are involved, so, too, will be arrogance. Remember that EVERY SINGLE USER who pays for your product IS a customer (and every single entity that might pay is a potential customer). In my experience, there is rarely a "single" customer who gets to be the sole arbiter of requirements, and there are often many 'potential' customers that also have requirements, and these requirements are very often contradictory or expensive to combine into one package (and nobody wants to pay for the combination). Further, often you cannot just split the 'product' into two 'products' because either maintaining the fork is too difficult/expensive (something the customers also don't want) or is explicitly rejected by the customers (no forks!!!) or you otherwise require interoperability. As to your car example: it isn't throughly considered; if a car needed 25 liters/kilometer, you probably WOULD drive it if you (a) had a need, (b) could afford it, and (c) there existed no competitive alternatives that met your requirements.
- Yes I would, but the fact is that I don't have to since there are plenty of very competitive alternatives that work for highways only, thanks to the guys that decided to alienate the 2% offroader customers and target a specific platform. If cars were to be written in pure Java (it's an image, ok?) it couldn't be that case. Now, I won't keep discussing this topic unless you give me examples of popular mass-market Swing-based applications.
- "If cars were to be written in pure Java (it's an image, ok?) it couldn't be that case." - that's just patently false, akin to saying that "you can't write a compiler in Java unless it's also a web-browser, a music-player, an Operating System, and blah blah blah". All cars DO run under the same platform: the same Earth, the same rules, the same laws of physics. And Swing vs. Swt is completely irrelevant to answering a question as to "why would I be ready to accept a degraded user experience?". If you're unwilling to continue the conversation without turning the discussion into a popularity contest, then I bid you good riddance.
- I think we need to make a distinction between custom B-to-B and intranet apps versus "packaged tools" such as word processors and HTML browsers. The ideal tool for one is not necessarily the ideal tool for another. I think SWT may be fine for custom B-to-B, but not necessarily for mass-audience apps.
- Then name any popular Swing-based mass-audience application. I'm not sure HTML browsers fall into the B2B category.
- [I agree 100% with the above comment, though I would probably choose Swing for custom B-to-B and intranet apps, in order to provide maximum consistency across platforms. I do use Swing for developing educational software that has to run on a variety of platforms -- consistency across platforms and supporting a maximum number of platforms is the priority here. For mass-market apps, where the user is more likely to be concerned about consistency with the OS look-and-feel, overall functionality and speedy response, and less likely to care about cross platform issues, SWT seems a reasonable choice. However, in general, this is a debate that is probably best decided on an application by application basis, depending on the specific requirements.]
(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?
- I think this is something we will have difficulties to agree on. My user base is 98% on Windows. Therefore, yes, I'm ready to alienate the 2% remaining to please the others. Unless I'm willing to target a niche market of Mac or Linux users (which I could do thanks to the easy port that JavaSwt is offering me), the CostVersusBenefit? ratio definitively tells me not to bother with CrossPlatformCompatibility?. It seems we're not living in the same IT world. My customers are the guys that are using a computer as a tool, not as an end. I'm not targetting a professional IT audience. They don't know what Java is, they don't know what cross-platform is, they barely know that Internet is something they can browse onto, and they really don't care about all the markting noise around WebTwoDotZero? or WriteOnceRunAnywhere. Think about how our parents are using computers. They make their buy decision about the product ease of use, the fact that the UI is neat and goes to the point, that the sofware is just one double-click away etc. Our business is to make the software, but their business is not about using it.
- It seems you're admitting to arrogance as a developer under the standards you described above ("Arrogance is when hardware vendors don't consider Linux when creating their drivers. Arrogance is when a web developper is assuming everybody's using InternetExplorer." Arrogance is when a developer or vendor assumes or forces his users to utilize a particular platform because they can't be bothered to support multiple platforms even indirectly.) As to the rest: you're dreadfully off-topic. This page IS about the tool called "JavaSwt" and its relatives (JavaSwing, JavaLanguage, etc.). These tools ARE intended for professional IT customers - the programmers - and these tools DO assume the customers know something about Java. It is NOT about your product. If you choose to use JavaSwt for your project, you can relate your experiences with it here... but it isn't otherwise more relevant to this discussion than would be a statement: "I implemented a GUI with C++, and it meets my user's requirements!". The fact is that Java was designed for WriteOnceRunAnywhere, and tools like JavaSwt run contrary to that goal... and that is why JavaSwt will not become a 'standard' Java library. Paraphrasing your earlier statements: as for any tool, JavaLanguage should do what it is intended to do, and JavaLanguage should help you deliver the product that the users (the programmers) are expecting. No more, no less." Making platform-specific stuff falls under the the "No more" aspect of what "Java is intended to do" because the users (the programmers) were told to expect WriteOnceRunAnywhere.
- What are you talking about anyway? How can you, for one single microsecond, disregard the user experience perspective when discussing about a GUI framework? Had the entire IT community gone mad?
- The user experience for JavaLanguage and JavaSwt is the programmer experience, NOT the experience of the application user. The application-users experience what is built with the JavaSwt tool, not the tool itself. Are you unwilling or simply unable to understand this? If you wanted a highly platform-integrated user-experience, you'll use all sorts of ForeignFunctionInterface stuff... which is essentially stuff written in a language that is NOT Java.
- {The user experience for JavaLanguage and JavaSwt is the programmer experience, NOT the experience of the application user.} If you really believe that, then we'd better stop discussing, we'll never agree on anything. {Oh? Well then feel free to leave the discussion. Logical discussion doesn't help someone incapable of understanding that programmers are (almost by definition) the 'users' of programming languages and their libraries.}
- [I'm afraid I'm not following the argument here... Are you saying programmers should categorically not use SWT?]
- {No. But I might say that programmers utilizing JavaSwt aren't really utilizing pure or 'true' Java. Programmers should use languages that get the jobs done. Saying someone shouldn't use JavaSwt because it's not pure Java would be like saying that someone shouldn't use C++ because it's not pure Java... a rather silly idea, I'd think.}
- [That SWT isn't "pure" Java is true by definition. So what? I can only see that being an issue if a developer foolishly uses SWT expecting it to be "pure" Java, which is about as likely as a soldier driving a VW Beetle into battle and expecting it to be a tank. (This whole page strikes me as being a desperate quibble-urge in search of a hot topic... Was it really worth it?)]
- {It isn't true by definition. That JavaSwt isn't "pure" Java is true only by implementation and design. JavaSwt could have proscribed or wrapped/emulated ALL 'platform dependent' code (out to some abstraction of platform capabilities) and still leveraged the native widgets... and still have been JavaSwt. It just didn't. And if you dove into this conversation thinking that the discussion is about 'issues' with JavaSwt or confusion about it, you should take more heed of the conversational context in the future, lest you step into line of fire during a HolyWar. This discussion is about ideals and about some rather fundamental questions (e.g. why might a user be willing to accept reduced personal service and integration? in the context of Java, is it better (more 'ideal') to offer users (-programmers-) a platform-specific-highly-integrated-proprietary-impossible-to-port solutions for GUIs (one for each platform), or is it better to offer cross-platform/platform independent solutions that are WriteOnceRunAnywhere, or is it better to offer something in between (like JavaSwt) that is fairly portable so long as you're careful?).}
- [Sorry, I was unclear: It's true by the definition of "pure Java". As always, the requirements -- rationally evaluated and prioritised by all users (including the developers) -- should be the deciding factor in such matters. Of course, that may spawn debate, but it's only reasonable in the context of a specific set of requirements; it makes no sense in general. That this should be considered a HolyWar, in abstractia, is reminiscent of various pointless pseudo-academic arguments over software ideology that I've sometimes had flung through my ears by those who don't actually write software for people.]
- [WriteOnceRunAnywhere was certainly a good UniqueSellingPoint in the early days of Java, and it's still a good selling point when it's required, but Java is now used as a general-purpose language like any other. As such, it is perfectly reasonable to use it to develop platform-dependent software when the requirements warrant it. If my users demand platform-specific behaviour (whether GUI-related or not), and cross-platform deployment isn't required, and Java is otherwise a suitable choice, it wouldn't be logical to discard Java as a possible implementation language simply because of some ideological slant.]
- Most platform-dependent software developed in Java isn't actually made platform-dependent by code developed in Java. It uses ForeignFunctionInterface, or is part of the virtual machine which (itself) is developed in another language. The keepers of the Java language shouldn't embrace those libraries as 'standard'. Plain Java should continue to be WriteOnceRunAnywhere.
- Sure it should. JavaSwt is not, and shouldn't be part of the standard Java platform. But that's not a reason to say that it "was a HUGE mistake of the NIH variety and I sincerely wish it would somehow get retracted".
- I'm not the one who said it was a huge mistake. What I said is: "JavaAwt and JavaSwing would better meet the 'WriteOnceRunAnywhere' philosophy." and "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.". Java has certain 'ideals' that are part and parcel to the language. JavaSwing and JavaAwt better align with those ideals than does JavaSwt.
- That I can agree with you to some extend. JavaSwt is highly portable per se, but since it is offering direct OS access, it won't be part of the lib and you won't be able to use it within in an applet for instance. My point is that JavaSwt is actually a better approach for a mass-market platform-specific applications where CrossPlatform? is not part of the requirements. Now you can pretend that such a requirement is foolish, or that you can beat a platform-tuned application with a Swing-based one, but my experience (and the observation of the Windows software market) doesn't make me thinking so (You could have a different experience, hence my question about popular Swing-based applications). You can also pretend that Java shouldn't be used as a ProgrammingLanguage for such applications, but I'm not sure this is a limitation that Sun's ready to accept. So my question is and remains: would you try to compete Firefox using a Swing-based application? Would you use Java at all? I pretend that while you can create a popular web browser in Java, it cannot be done using Swing if you really want to get a decent user base because users will be reluctant to use a non shell-integrated GUI. Therefore the only alternative (beside playing JNI by yourself) is JavaSwt. I also pretend that such a situation occurs very frequently in mass-market client-side software. Does this clarify?
- It clarifies. However, it's just as relevant to note that Java wasn't designed for mass-market platform-specific applications where tight platform integration is part of the requirements. Languages are tools designed and intended to certain purposes, and that is not among the purposes for Java. This is just as true as the fact that BrainfuckLanguage wasn't designed for any serious application programming at all. JavaSwt is allowing you to use leverage Java to a purpose for which it was neither designed nor intended, but it's still a bit hackish... a bit less of a hack than would be putting a memory-mapped ForeignFunctionInterface into BrainfuckLanguage just so you can do full GUI and network programming, but still a hack. Now, would I use Swing to compete with Firefox? or with EclipseIde (perhaps IntellijIdea)? I don't know. I'd probably not use Java at all. I'm not particularly fond of any of the modern GUI environments (my own GUI work is more in line with the idea of ZoomableUserInterface and ObjectBrowser and I'm a proponent of NoApplication). But I wouldn't automatically dismiss Swing as incapable... it runs fast enough (and can be optimized further if necessary) and if integration with environment is necessary it could be made context-aware when choosing its skin. If I needed really tight integration (e.g. Java on bare-metal and VGA), I'd probably create a module and use FFI for C or assembler directly. There are often many hackish approaches to meeting user requirements, and if JavaSwt does it for you, then that's fine. However, you seem to be saying that JavaSwt is the only approach - an idea I find ludicrous. Does this clarify?
- ["If I needed really tight integration (e.g. Java on bare-metal and VGA), I'd probably create a module and use FFI for C or assembler directly." Must be nice to have the luxury of an unbounded budget...]
- It would be nice. Of course, lack of 'unbounded budget' was part of what started this whole conversation: why might a user be willing to accept that an application isn't developed and wholly integrated for his/her particular environment or platform? Limited budget. Java on bare metal and VGA is of value, though, e.g. to those folks writing themselves an OS in Java. If you have a need, you pay for it or you fail.
- It does. This said, if for some reasons the selected language happens to be Java (because we DID want easy portability across platforms, but not at the expense of OS integration), I believe JavaSwt is a very reasonable choice in term of cost/benefit in this context (mass-market blah-blah-blah). This is why I say that JavaSwt was a great idea, and I thank IBM for having initiated this project. Without it, the project would have been .Net-based, and much less portable.
- That's reasonable.
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.
OctoberZeroSeven
CategoryJava PlatformIndependentGui, BuildJavaGuiBrowser
Java Swt