The "One Laptop Per Child" project has a great device ready to ship, but there's no Java on there. Let's think about working together to put Java on OLPC!
Replies:
48 -
Pages:
4
[
1234
| Next
]
Threads:
[
Previous
|
Next
]
Ok, every flame-war about Swing vs SWT and how IBM is trying to sink Sun's boat aside, SWT is a pretty interesting toolkit. It's one of only two major Java GUI APIs available today (I'm not counting AWT as "major" anymore). Also, it's really only the second cross GUI development toolkit in any language which seems to have gotten native peering right (wxWidgets being the other one). Yet, despite all this "cool ooze", SWT adoption remains fairly low.
Eclipse itself is really the biggest application to use the toolkit. However, since SWT was originally built for Eclipse, we can pretty much discount Eclipse as factoring towards our mini mental poll. So, with Eclipse out of the way, I can think of two fairly popular apps (just off the top of my head) which use SWT: Azureus and RSSOwl. One of these applications (RSSOwl) is using the RCP as the basis for its architecture, and since using the RCP entails usage of SWT, we probably should demote RSSOwl down to ¾ of a vote.
But even weighting all things equally, that's still only two applications. Now, there are more that I wasn't able to remember right off the top of my head. And of course, there are a number of commercial and internal offerings utilizing the Eclipse RCP (I should know, I just spent the last month and a half helping to judge them for the Eclipse Awards). But while these are significant applications, and the RCP (and by proxy SWT) wouldn't be where it is without them, they don't really count as "major" end-user desktop applications.
Now, looking at SWT's main competitor, Swing, we read quite a different story. A large number of desktop applications exist which use Swing as the foundation for their UI. Just to pick a few examples: LimeWire and Columba. LimeWire being of course the wildly popular music sharing application, while Columba is a slightly less well-known email client (really nice client, just doesn't seem to work right on Windows). I just picked these applications out of thin air. Since we considered Eclipse for weighting on SWT's side of things (discounted because of SWT's origins), we should probably consider the two other majors IDEs, NetBeans and IntelliJ.
We can't actually "throw away" either NetBeans or IntelliJ simply because they are IDEs. Remember, we only discounted Eclipse because it is the reason SWT exists. NetBeans - while it is a Sun product - had nothing to do with the creation of Swing. Additionally, it really had no more to do with its growth and development as an API than any other major Swing-based application. Therefore, we have to throw both NetBeans and IntelliJ into the mix of Swing applications.
In fact, if we were to tally it all up (which I won't), we would find that Swing adoption so far outstrips SWT adoption that comparing the two is almost ludicrous. SWT really has a long way to go before it's a serious threat to Swing in terms of the "first choice" GUI API on Java. I guess the main question to which I keep returning is: Will SWT ever make it?
Please don't misinterpret this post. I love SWT as a toolkit. I think its API has some quirks, and it is limiting in some ways in which it doesn't need to be, but overall I think it's pretty cool. I also really like applications that are built using SWT - on the whole. I mean, Romain Guy is fond of saying that all SWT applications have to look like Eclipse. And while this is by no means true, I can see how he arrived at that conclusion. A lot of RCP applications neglect their look and feel a little bit since "the RCP handles it all" or some such excuse. All this does is hurt the application's adoption and spreads misconceptions about SWT in general.
Perhaps this is why SWT can't seem to break into the big time: there's just too much FUD surrounding it. If your employer were considering a new application and started asking around regarding SWT vs Swing, he'd get a hundred different answers; all of them passionate and (in some cases) very inflammatory. No one seems to be able to give a straight answer regarding either SWT or a comparison between SWT and Swing. This probably scares managers off a bit. And since Swing is bundled with the JRE, people are more prone to trusting it, and so its adoption will always remain high, and SWT will always trail it in mindshare. Thoughts?
Also note that Swing is probably more comparable to SWT+JFace rather than SWT on its own. In terms of functionality, the list probably goes something like AWT > SWT > Swing > JFace in terms of power ...
Lastly, RSSOwl isn't an RCP application. It's a Java application that uses both SWT and JFace. Witness the complete lack of plugins and OSGi engine ...
Those nit-picks out of the way, you raise a good point; what is the market share for SWT (and/or SWT+JFace apps) that aren't based on RCP? Whilst it's possible, it seems to me that there's relatively few people who've invested time in learning either SWT or JFace and who haven't been bitten by the OSGi dynamic bug. Other than size constraints, why wouldn't you build something on top of OSGi; and if you're doing that, why not build it on top of Eclipse RCP too?
The fact is that every RCP (or Eclipse-IDE derivative) uses SWT+JFace for their base layer. Discounting almost the entire set of users just to see what's left over doesn't seem to be a good test of the UI toolkit; without SWT, they wouldn't exist. You have to include all the users of SWT -- whether directly or indirectly -- to know whether it's a success.
And hey, if you're going to discount swathes of people just because they're not using solely the base libraries, you might as well throw out the entire Swing-using universe, because that sits on top of AWT.
What would be more interesting is including the Eclipse RCP numbers and seeing what the stack is like, both in terms of the number of individual apps and the number of users of those apps.
> And hey, if you're going to discount swathes of
> people just because they're not using solely the base
> libraries, you might as well throw out the entire
> Swing-using universe, because that sits on top of
> AWT.
Oh yeah, I absolutely agree. This is why I threw out AWT as a toolkit. Technically, Swing is entirely based upon it and depends on its native integration to work at all, but when you write your application using JFrame and JButton, you don't say that you're using AWT. Likewise, if I were to build an application based on the RCP/JFace, I wouldn't say that I'm using SWT. Rather, I'd say that I'm building on the RCP.
Though, that analogy breaks down a bit because to use Swing, you don't actually have to directly touch AWT anywhere. To use JFace or the RCP, you do have to directly use SWT a lot. So maybe we should count RCP apps. Still, it's no where near a long list by Swing adoption standards.
> I would choose Swing over SWT/JFace for a couple
> reasons:
>
> 1 - lightweight rendering
> This makes it way easier to write custom
> components, effects, and animations.
>
> 2 - better tool support
> Matisse
> 3 - more options for enhancements
> GlazedLists, JGoodies, FoxTrot, to name a few.
> 4 - I like the API design of Swing over that of
> SWT/JFace.
> That's just my opinion, but it factors in a
> decision on
> hat toolkit to use.
>
> I would choose SWT/JFace over Swing if:
>
> 1 - I was writing code for an Eclipse plugin
I didn't really intend to start a "Why I use X and why you should too" debate, but I suppose that is what's on trial to some extent. You generally use the toolkit you think is best for the job, regardless of market saturation.
On the subject of looking like Eclipse... there's an interesting quote by Romain Guy (from an
interview on InfoQ
):
The good thing with Swing is that it looks bad by default so you're going to have to change it to have a good-looking application
Yes that's right -- it's a good thing that Swing looks rubbish out of the box! Because it forces us developers to spend time fiddling about to make it look reasonably good (read: like a normal application for the user's platform). Whereas SWT/RCP already looks pretty good, if a little Eclipse-like, out of the box, so unless you have a pressing need for your application not to look anything like Eclipse (e.g. you're building the next version of Lotus Notes) then you can just get on with something more productive, like the actual features of your application.
Incidentally, I played about a little with NetBeans recently for an OSGi presentation I did with Alex. The point of demoing with NetBeans was simply to show that OSGi is universal, you don't need to be an Eclipse-head to use it. Anyway, I found myself incredibly frustrated that I couldn't just drag-and-drop or cut-and-paste files from Windows Explorer or Mac Finder directly into NetBeans. Native platform integration still matters a lot!
Really, SWT and Swing are two different animals. If you are interested in tight native integration, being first class on the desktop and being indistinguishable from native applications, then SWT is for you.
Over the years, there's been a lot of people with political agendas pouring scorn on the toolkit. SWT is a tremendous technical achievement in terms of API, performance and memory footprint. I'm proud of what we've achieved and more interested in fixing bugs than arguing philosophy.
> Daniel,
>
> If I ever get my $@%@$@$ hands on you ...
>
> Really, SWT and Swing are two different animals. If
> you are interested in tight native integration, being
> first class on the desktop and being
> indistinguishable from native applications, then SWT
> is for you.
>
> Over the years, there's been a lot of people with
> political agendas pouring scorn on the toolkit. SWT
> is a tremendous technical achievement in terms of
> API, performance and memory footprint. I'm proud of
> what we've achieved and more interested in fixing
> bugs than arguing philosophy.
>
> Steve
You know I was kidding, right?
SWT's technical merits aren't in doubt. As I said, it really "oozes cool" from a geeky side of things. If anything, I was lamenting that it *hasn't* reached a higher level of adoption amongst the masses. And unfortunately, the political side of things is a large reason SWT hasn't hit a high adoption level (as I said, a hundred different responses). I'm pretty sure SWT would be more commonly used if it wasn't so controversial.
And this really is through no fault of its own. I think the only real reason it stirs up so much angst is a) it was IBM's conception, and b) (related to a) is in direct competition with a Sun API. If it weren't for those two facts, I'm convinced that SWT would be quite widely used today.
Though excluded by the criteria given, IBMs SameTime, Notes 8 and the Expeditor client are worthy of mention. The Expeditor toolkit has its own look and feel. It's certainly not just SWT+UIStyle but it will be a large ecosytem on which to build.
An open source layer with several UI themes and just a few of the Expeditor functions would be nice but I don't know that it would ever gain significant mindshare against Swing.
If we look at a broader perspective, C# and VB.NET (and to some extent web apps) are still the "real" alternatives to both of them. Now if Java is eventually chosen for the project, I believe that all other things being equal, the choice between SWT/JFace/RCP based app and a Swing app should be in terms of UI requirements: clean/simple/standard look vs. components customization. I think SWT/JFace is (still?) not a "good for everything" combination, although new widgets and capabilities are being added all the time.
However, companies choose their UI framework based on a variety of factors, including training options and costs (swt courses are rare, at least where I live), ease of getting help (but it really depends on the skills of the developers), the desire to stick to a single ui framework for the entire company, the fact the decision makers are more familiar with either of them because they learned/used it themselves in college/project/etc. and feel more comfortable managing a project that uses technology they know well.
Some of the answers in favor of swing are be due to the fact that Swing was there first. In the next few years this differences will become more and more marginal.
Will SWT Ever Break the Big Time?
At 1:16 PM on Feb 19, 2007, Daniel Spiewak
wrote:
Eclipse itself is really the biggest application to use the toolkit. However, since SWT was originally built for Eclipse, we can pretty much discount Eclipse as factoring towards our mini mental poll. So, with Eclipse out of the way, I can think of two fairly popular apps (just off the top of my head) which use SWT: Azureus and RSSOwl. One of these applications (RSSOwl) is using the RCP as the basis for its architecture, and since using the RCP entails usage of SWT, we probably should demote RSSOwl down to ¾ of a vote.
But even weighting all things equally, that's still only two applications. Now, there are more that I wasn't able to remember right off the top of my head. And of course, there are a number of commercial and internal offerings utilizing the Eclipse RCP (I should know, I just spent the last month and a half helping to judge them for the Eclipse Awards). But while these are significant applications, and the RCP (and by proxy SWT) wouldn't be where it is without them, they don't really count as "major" end-user desktop applications.
Now, looking at SWT's main competitor, Swing, we read quite a different story. A large number of desktop applications exist which use Swing as the foundation for their UI. Just to pick a few examples: LimeWire and Columba. LimeWire being of course the wildly popular music sharing application, while Columba is a slightly less well-known email client (really nice client, just doesn't seem to work right on Windows). I just picked these applications out of thin air. Since we considered Eclipse for weighting on SWT's side of things (discounted because of SWT's origins), we should probably consider the two other majors IDEs, NetBeans and IntelliJ.
We can't actually "throw away" either NetBeans or IntelliJ simply because they are IDEs. Remember, we only discounted Eclipse because it is the reason SWT exists. NetBeans - while it is a Sun product - had nothing to do with the creation of Swing. Additionally, it really had no more to do with its growth and development as an API than any other major Swing-based application. Therefore, we have to throw both NetBeans and IntelliJ into the mix of Swing applications.
In fact, if we were to tally it all up (which I won't), we would find that Swing adoption so far outstrips SWT adoption that comparing the two is almost ludicrous. SWT really has a long way to go before it's a serious threat to Swing in terms of the "first choice" GUI API on Java. I guess the main question to which I keep returning is: Will SWT ever make it?
Please don't misinterpret this post. I love SWT as a toolkit. I think its API has some quirks, and it is limiting in some ways in which it doesn't need to be, but overall I think it's pretty cool. I also really like applications that are built using SWT - on the whole. I mean, Romain Guy is fond of saying that all SWT applications have to look like Eclipse. And while this is by no means true, I can see how he arrived at that conclusion. A lot of RCP applications neglect their look and feel a little bit since "the RCP handles it all" or some such excuse. All this does is hurt the application's adoption and spreads misconceptions about SWT in general.
Perhaps this is why SWT can't seem to break into the big time: there's just too much FUD surrounding it. If your employer were considering a new application and started asking around regarding SWT vs Swing, he'd get a hundred different answers; all of them passionate and (in some cases) very inflammatory. No one seems to be able to give a straight answer regarding either SWT or a comparison between SWT and Swing. This probably scares managers off a bit. And since Swing is bundled with the JRE, people are more prone to trusting it, and so its adoption will always remain high, and SWT will always trail it in mindshare. Thoughts?
48 replies so far (
Post your own)
Re: Will SWT Ever Break the Big Time?
What's wrong with Qt as a cross-platform toolkit?Also note that Swing is probably more comparable to SWT+JFace rather than SWT on its own. In terms of functionality, the list probably goes something like AWT > SWT > Swing > JFace in terms of power ...
Lastly, RSSOwl isn't an RCP application. It's a Java application that uses both SWT and JFace. Witness the complete lack of plugins and OSGi engine ...
Those nit-picks out of the way, you raise a good point; what is the market share for SWT (and/or SWT+JFace apps) that aren't based on RCP? Whilst it's possible, it seems to me that there's relatively few people who've invested time in learning either SWT or JFace and who haven't been bitten by the OSGi dynamic bug. Other than size constraints, why wouldn't you build something on top of OSGi; and if you're doing that, why not build it on top of Eclipse RCP too?
The fact is that every RCP (or Eclipse-IDE derivative) uses SWT+JFace for their base layer. Discounting almost the entire set of users just to see what's left over doesn't seem to be a good test of the UI toolkit; without SWT, they wouldn't exist. You have to include all the users of SWT -- whether directly or indirectly -- to know whether it's a success.
And hey, if you're going to discount swathes of people just because they're not using solely the base libraries, you might as well throw out the entire Swing-using universe, because that sits on top of AWT.
What would be more interesting is including the Eclipse RCP numbers and seeing what the stack is like, both in terms of the number of individual apps and the number of users of those apps.
Alex.
Re: Will SWT Ever Break the Big Time?
Daniel, sometimes I think your purpose is to incite Steve Northover :Pj/k
Re: Will SWT Ever Break the Big Time?
I would choose Swing over SWT/JFace for a couple reasons:1 - lightweight rendering
This makes it way easier to write custom components, effects, and animations.
2 - better tool support
Matisse
3 - more options for enhancements
GlazedLists, JGoodies, FoxTrot, to name a few.
4 - I like the API design of Swing over that of SWT/JFace.
That's just my opinion, but it factors in a decision on
what toolkit to use.
I would choose SWT/JFace over Swing if:
1 - I was writing code for an Eclipse plugin
Re: Will SWT Ever Break the Big Time?
> And hey, if you're going to discount swathes of> people just because they're not using solely the base
> libraries, you might as well throw out the entire
> Swing-using universe, because that sits on top of
> AWT.
Oh yeah, I absolutely agree. This is why I threw out AWT as a toolkit.
Though, that analogy breaks down a bit because to use Swing, you don't actually have to directly touch AWT anywhere. To use JFace or the RCP, you do have to directly use SWT a lot. So maybe we should count RCP apps. Still, it's no where near a long list by Swing adoption standards.
ActiveObjects: an Easier Java ORM; Fuse: Resource Injection for Java
Re: Will SWT Ever Break the Big Time?
> Daniel, sometimes I think your purpose is to incite> Steve Northover :P
>
> j/k :)
lol Steve's comments make good copy. What can I say?
ActiveObjects: an Easier Java ORM; Fuse: Resource Injection for Java
Re: Will SWT Ever Break the Big Time?
> I would choose Swing over SWT/JFace for a couple> reasons:
>
> 1 - lightweight rendering
> This makes it way easier to write custom
> components, effects, and animations.
>
> 2 - better tool support
> Matisse
> 3 - more options for enhancements
> GlazedLists, JGoodies, FoxTrot, to name a few.
> 4 - I like the API design of Swing over that of
> SWT/JFace.
> That's just my opinion, but it factors in a
> decision on
> hat toolkit to use.
>
> I would choose SWT/JFace over Swing if:
>
> 1 - I was writing code for an Eclipse plugin
I didn't really intend to start a "Why I use X and why you should too" debate, but I suppose that is what's on trial to some extent. You generally use the toolkit you think is best for the job, regardless of market saturation.
ActiveObjects: an Easier Java ORM; Fuse: Resource Injection for Java
Re: Will SWT Ever Break the Big Time?
On the subject of looking like Eclipse... there's an interesting quote by Romain Guy (from an interview on InfoQ ):Yes that's right -- it's a good thing that Swing looks rubbish out of the box! Because it forces us developers to spend time fiddling about to make it look reasonably good (read: like a normal application for the user's platform). Whereas SWT/RCP already looks pretty good, if a little Eclipse-like, out of the box, so unless you have a pressing need for your application not to look anything like Eclipse (e.g. you're building the next version of Lotus Notes) then you can just get on with something more productive, like the actual features of your application.
Incidentally, I played about a little with NetBeans recently for an OSGi presentation I did with Alex. The point of demoing with NetBeans was simply to show that OSGi is universal, you don't need to be an Eclipse-head to use it. Anyway, I found myself incredibly frustrated that I couldn't just drag-and-drop or cut-and-paste files from Windows Explorer or Mac Finder directly into NetBeans. Native platform integration still matters a lot!
Re: Will SWT Ever Break the Big Time?
Daniel,If I ever get my $@%@$@$ hands on you ...
Really, SWT and Swing are two different animals. If you are interested in tight native integration, being first class on the desktop and being indistinguishable from native applications, then SWT is for you.
Over the years, there's been a lot of people with political agendas pouring scorn on the toolkit. SWT is a tremendous technical achievement in terms of API, performance and memory footprint. I'm proud of what we've achieved and more interested in fixing bugs than arguing philosophy.
Steve
Re: Will SWT Ever Break the Big Time?
> Daniel,>
> If I ever get my $@%@$@$ hands on you ...
>
> Really, SWT and Swing are two different animals. If
> you are interested in tight native integration, being
> first class on the desktop and being
> indistinguishable from native applications, then SWT
> is for you.
>
> Over the years, there's been a lot of people with
> political agendas pouring scorn on the toolkit. SWT
> is a tremendous technical achievement in terms of
> API, performance and memory footprint. I'm proud of
> what we've achieved and more interested in fixing
> bugs than arguing philosophy.
>
> Steve
You know I was kidding, right?
SWT's technical merits aren't in doubt. As I said, it really "oozes cool" from a geeky side of things. If anything, I was lamenting that it *hasn't* reached a higher level of adoption amongst the masses. And unfortunately, the political side of things is a large reason SWT hasn't hit a high adoption level (as I said, a hundred different responses). I'm pretty sure SWT would be more commonly used if it wasn't so controversial.
And this really is through no fault of its own. I think the only real reason it stirs up so much angst is a) it was IBM's conception, and b) (related to a) is in direct competition with a Sun API. If it weren't for those two facts, I'm convinced that SWT would be quite widely used today.
ActiveObjects: an Easier Java ORM; Fuse: Resource Injection for Java
Re: Will SWT Ever Break the Big Time?
Though excluded by the criteria given, IBMs SameTime, Notes 8 and the Expeditor client are worthy of mention. The Expeditor toolkit has its own look and feel. It's certainly not just SWT+UIStyle but it will be a large ecosytem on which to build.An open source layer with several UI themes and just a few of the Expeditor functions would be nice but I don't know that it would ever gain significant mindshare against Swing.
Re: Will SWT Ever Break the Big Time?
java.awt.Font and java.awt.Color are pretty heavily used throughout the Swing codebase.Alex.
Re: Will SWT Ever Break the Big Time?
And you can see the demos on-line at http://www.eclipsezone.com/files/jsig/ as well as download the code and presentationAlex.
Re: Will SWT Ever Break the Big Time?
If we look at a broader perspective, C# and VB.NET (and to some extent web apps) are still the "real" alternatives to both of them. Now if Java is eventually chosen for the project, I believe that all other things being equal, the choice between SWT/JFace/RCP based app and a Swing app should be in terms of UI requirements: clean/simple/standard look vs. components customization. I think SWT/JFace is (still?) not a "good for everything" combination, although new widgets and capabilities are being added all the time.However, companies choose their UI framework based on a variety of factors, including training options and costs (swt courses are rare, at least where I live), ease of getting help (but it really depends on the skills of the developers), the desire to stick to a single ui framework for the entire company, the fact the decision makers are more familiar with either of them because they learned/used it themselves in college/project/etc. and feel more comfortable managing a project that uses technology they know well.
Some of the answers in favor of swing are be due to the fact that Swing was there first. In the next few years this differences will become more and more marginal.
Finally, here are some RCP articles and usage examples:
http://www.crn.com/showArticle.jhtml?articleID=192600126 - 23% of developers use RCP(?)
JPMorgan - http://www.eweek.com/article2/0,1895,2027415,00.asp
Get the RMI Plugin for Eclipse
Re: Will SWT Ever Break the Big Time?
> Daniel,>
> If I ever get my $@%@$@$ hands on you ...
>
If you both go to EclipseCon, I'll be looking forward to the pictures...
Get the RMI Plugin for Eclipse