Harmony project to get a Swing/AWT implementation [LWN.net]

The Harmony Project - which just saw its first birthday - is working to develop an entirely free Java implementation. At JavaOne, Harmony hacker Geir Magnusson announced that Harmony is about to received a substantial code donation from Intel: a complete implementation of the Swing/AWT user interface toolkits. This code takes Harmony much closer to its goal of creating a fully compatible Java environment. (See also: Danese Cooper's post on Sun and Java).

to post comments

Harmony vs. Classpath/Kaffe/gcj?

Posted May 19, 2006 15:48 UTC (Fri) by stevenj (guest, #421) [Link] (7 responses)

Can someone explain again how Harmony relates to GNU Classpath/Kaffe/gcj?

The Harmony FAQ states:

13) Does this compete with Kaffe and Classpath?
People from Kaffe and Classpath are helping start this project! Their experience in the open source VM and class library is invaluable, and they bring problems that the larger architecture community discussion can help solve.
We will have an implementation under the Apache License, but we think of this as complementary rather than competitive. And when we solve a few small license interoperability issues, we expect we'll be able to complement each other even more.

This makes no sense to me, however. Harmony seems to be progressing towards a complete duplication, from scratch, of Classpath and Kaffe/gcj, with no shared code. How is this "complementary?"

Harmony vs. GNU Classpath/Kaffe/gcj?

Posted May 19, 2006 16:37 UTC (Fri) by mjw (subscriber, #16740) [Link] (3 responses)

The following GNU Classpath thread probably explains it: Where's the love?

Please tell me there are better reasons than this....

Posted May 19, 2006 17:58 UTC (Fri) by stevenj (guest, #421) [Link] (2 responses)

Looking at that thread, and also reading the threads Re: classpath on the Harmony mailing list when the project started in 2005, it seems that their main reasons for re-inventing the wheel are:

Not Invented Here — they don't like working under the auspices of the FSF.
Vague concerns about the Classpath license being "viral" — despite the fact that it is GPL with an explicit exception allowing linking to proprietary code.

Please, someone tell me that I misread the Harmony developers' discussion, and that there is a better reason that is not this stupid.

Please tell me there are better reasons than this....

Posted May 19, 2006 19:45 UTC (Fri) by nix (subscriber, #2304) [Link]

As I understand it, they don't like working under *anyone's* auspices but their own, for no particularly clear reason.

Really extreme NIH.

Please tell me there are better reasons than this....

Posted May 19, 2006 20:24 UTC (Fri) by robilad (guest, #27163) [Link]

It really is this stupid.

Otoh, GPL3 will fix that at least in one direction, so it's less of a big deal anymore.

Harmony vs. Classpath/Kaffe/gcj?

Posted May 19, 2006 20:16 UTC (Fri) by robilad (guest, #27163) [Link] (2 responses)

Not complementary at the source code level, unfortunately.

That's not necessarily a bad thing, though. ASF's project attracts an audience that cares about using it as a certified as compatible base for open source components from/for their prorietary VMs. That audience (IBM & Intel) does not seem to want to have to deal with having anything GPL-related in it. Any mention of the GPL is apparently a hair raising stimulus in the proprietary Java audience. :)

As Harmony's fast progress so far shows, that audience has some pretty deep pockets, too.

So these days the 'complementary' stands more for the different audiences the projects cater to: FSF to those wanting a free software implementation to run free software, ASF to those wanting to build their proprietary, certified Java(TM) products off an open source implementation.

As an unforeseen side effect, Sun got caught between two fires, and the value proprosition of keeping their code proprietary is going down even faster.

complementarity

Posted May 19, 2006 21:44 UTC (Fri) by stevenj (guest, #421) [Link] (1 responses)

So these days the 'complementary' stands more for the different audiences the projects cater to: FSF to those wanting a free software implementation to run free software, ASF to those wanting to build their proprietary, certified Java(TM) products off an open source implementation.

Except that Classpath comes with a GPL exception that permits it to be used for proprietary products. Sigh.

complementarity

Posted May 19, 2006 22:32 UTC (Fri) by robilad (guest, #27163) [Link]

I know. Honni soit qui mal y pense.

Harmony project to get a Swing/AWT implementation

Posted May 19, 2006 17:36 UTC (Fri) by TwoTimeGrime (guest, #11688) [Link] (7 responses)

> The Harmony Project - which just saw its first birthday

This must be a new harmony project. The KDE Harmony project is more than a year old.

Harmonizing

Posted May 19, 2006 17:52 UTC (Fri) by rfunk (subscriber, #4054) [Link] (6 responses)

Wasn't the KDE Harmony project the effort to clone Qt or something, and
didn't it die when Qt adopted the GPL?

My memory is fuzzy, but the name has definitely been used once or twice
before in the free software / open source community.

new naming rule

Posted May 19, 2006 18:30 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] (2 responses)

When naming a new FOSS project, always pick a name for which projectname.org is available. Then we won't have naming conflicts.

new naming rule

Posted May 19, 2006 18:36 UTC (Fri) by rfunk (subscriber, #4054) [Link] (1 responses)

Good idea. But .org is pretty crowded with other stuff too....
Maybe we should petition ICANN for a new .foss TLD. Hey, the museums get
a TLD, why not us?

new naming rule

Posted May 21, 2006 5:46 UTC (Sun) by cthart (guest, #4457) [Link]

Except RS will jump in clamouring for .fs instead of .foss

:-)

Harmonizing

Posted May 19, 2006 21:23 UTC (Fri) by TwoTimeGrime (guest, #11688) [Link] (2 responses)

> Wasn't the KDE Harmony project the effort to clone Qt or something,

Yes. I remember it. When I read the summary I thought "What does QT have to do with Java?" but this is clearly something different. I guess the other Harmony project is dead.

Harmonizing

Posted May 22, 2006 9:43 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

Given that its raison d'etre was to produce a GPLed Qt implementation because Qt wasn't GPLed, and Qt is now GPLed, it would be a bit of a waste of time to continue with it...

Harmonizing

Posted May 22, 2006 15:01 UTC (Mon) by yodermk (guest, #3803) [Link]

Actually, even after Qt was GPL'd, there were a few that wanted to continue Harmony because they wanted it LGPL.

That movement never got very far AFAIK.

Swing and AWT, argh

Posted May 19, 2006 23:18 UTC (Fri) by man_ls (guest, #15091) [Link] (3 responses)

Sun controls the Java specification. This means that they can say what is Java and what not; this power came in handy to stop Microsoft from subverting the language (and earn a lot of money in the process). But, as the linked post says, the spec contains the brain-dead AWT and the doubly brain-dead Swing. Let me rant a little.

Many Java libraries should have been optional; having Swing support on a machine without X Window is not very useful. But no, everything went into the spec and everything had to be there. This is not about Microsoft adding its own classes into the mix, but about people removing what they don't need. Sun wanted to have everything there, always, so developers could depend on the features at runtime. But this is hardly useful most of the time; having java.sql on a machine without an installed database is not going to help.

The Abstract Windowing Toolkit or AWT was an attempt to make a graphical environment that could be used on any system. Sadly, it was very limited in scope; in its day multi-platform graphical toolkits were still beginning to take shape. (Remember when it was cool to run an "applet" within your browser?) Very soon Sun wanted to add new functionality, but the need to maintain backwards compatibility made it difficult. Around 1999 and the misleadingly called Java 2 (officially it was 1.2), Sun engineers came up with an utterly stupid solution which solved a problem that nobody had. The all-Java (or pure Java in Sun parlance) graphical toolkit was built on top of AWT: with it the interface could sport a Windows look-and-feel on Solaris and viceversa. Very useful. In the process they created a slow, highly bloated environment and a memory hog, which needed endless optimizations to be barely useful. By the way, all look-and-feels were ugly. This monstrosity was called Swing.

So now we are stuck with it forever. In fact, gcj and GNU Classpath are mostly complete except for AWT and Swing. Meanwhile, IBM (and later the Eclipse project) found the time to build a much lighter and faster environment, called Standard Widget Toolkit or SWT. It uses the novel (yeah, right) idea of using platform-specific code internally to display controls, and still presenting a uniform API. It's good stuff. The bad news is: even if you only want to use SWT applications, you still have to carry the burden of Swing.

This latest addition to Harmony must therefore be useful to some people. I cannot figure out why did Intel have a Swing/AWT implementation to donate, but I guess we will find out soon.

Swing and AWT, argh

Posted May 22, 2006 14:50 UTC (Mon) by lauwenmark (guest, #37754) [Link] (2 responses)

Sun engineers came up with an utterly stupid solution which solved a problem that nobody had. The all-Java (or pure Java in Sun parlance) graphical toolkit was built on top of AWT: with it the interface could sport a Windows look-and-feel on Solaris and viceversa. Very useful.

The problem it solved was that the way AWT behaved and looked like changed a lot between its various implementations. The goal of using Swing was to provide an abstraction layer that made possible for an application to display and behave exactly the same on all platforms - a goal the limited design of AWT was unable to fullfill.
Let's also not forget that Swing provides a MVC model which AWT lacked - that too was a rather important progress.

In the process they created a slow, highly bloated environment and a memory hog, which needed endless optimizations to be barely useful. By the way, all look-and-feels were ugly. This monstrosity was called Swing.

Given that the current implementations of Swing are able to use underlying accelerated graphical capabilities (D3D/OpenGL) where available, the lack of speed Swing had in the past seems hardly relevant nowadays. Now, maybe you have some benchmarks to back up your facts ?
As for the Look-and-Feels, it is mostly a subjective point - and nothing prevents you to develop and use your own LnF if you don't like the provided ones.

So now we are stuck with it forever. In fact, gcj and GNU Classpath are mostly complete except for AWT and Swing.

AWT and Swing are large libraries with lots of classes to implement. And they weren't the most needed classes to implement first. Moreover, no compatibility test suite existed for Swing/AWT, so it is not easy to guess the correct behavior in all cases.

Meanwhile, IBM (and later the Eclipse project) found the time to build a much lighter and faster environment, called Standard Widget Toolkit or SWT. It uses the novel (yeah, right) idea of using platform-specific code internally to display controls, and still presenting a uniform API. It's good stuff. The bad news is: even if you only want to use SWT applications, you still have to carry the burden of Swing.

Other bad news related to SWT: only the Windows implementation is decent performance-wise; the documentation is far from the level of what's available on Swing; SWT programming requires manual ressource-management; portability is inferior, some features not being available on all supported platforms.

Underlining the deficiencies of Swing is one thing - but next time, try not to forget to also underline those of SWT to compare both.

Swing and AWT, argh

Posted May 22, 2006 17:13 UTC (Mon) by philips (guest, #937) [Link]

> Underlining the deficiencies of Swing is one thing - but next time,
> try not to forget to also underline those of SWT to compare both.

Well, I'm not sure what kind of platform you run, Swing examples run dog slow and unresponsive on my Linux box (AMD64 X2). Anything more complicated than simple text editor is unusable due to very high latencies. (*). GVIM with syntax highlighting open on busy remote server over X protocol tunneled over ssh runs snappier than localy run Swing demos from Java SDK.

On side note, SWT thou not perfect, quite usable - here I'm judging by Eclipse - on both Windows and Linux. I personally use vim - but most of my friends use solely Eclipse with plug for C/C++ as their primary development environment. (**)

Probably Swing is designed better than SWT. It doesn't matter to me much since I haven't seen single worthy Java GUI application using Swing. And I have on network bunch using SWT.

(*) Okay, I'm touchtypist and quite sensitive to such stuff. Probably others are okay with the delays and flickering.

(**) Just recalled. Azureus - BitTorrent Java client - uses SWT and runs on Windows, Linux & Macs. I used it on many occasions on all of the aforementioned platforms. In other words, SWT much more portable than parent tries to imply.

Swing and AWT, argh

Posted May 22, 2006 22:20 UTC (Mon) by man_ls (guest, #15091) [Link]

The goal of using Swing was to provide an abstraction layer that made possible for an application to display and behave exactly the same on all platforms - a goal the limited design of AWT was unable to fullfill.

Yes, that is exactly what I was talking about: a problem that nobody had. People wanted their programs to look different on different operating systems, not uniformly ugly. That is why all the other toolkits (Qt, GTK, wxWidgets, the old OPENSTEP) look different on different targets. And still some people don't get it.

Given that the current implementations of Swing are able to use underlying accelerated graphical capabilities (D3D/OpenGL) where available, the lack of speed Swing had in the past seems hardly relevant nowadays.

Hardware acceleration does not magically solve all problems. In fact 3d hardware acceleration solves very specific problems; it does nothing for bloat.

Now, maybe you have some benchmarks to back up your facts ?

Not really, since the question is not that hot any more. Right now I can offer you some home benchmarks which you will not accept anyway (and with good reason).

Hello world: Swing 21 MB and .5 sec, SWT 10.0 MB and .1 sec.
Window with 100 buttons: Swing 24 MB and .55 sec, SWT 10.3 MB and .1 sec.
Table with 1000 rows: Swing 26 MB and .6 sec, SWT 13.3 MB and .3 sec.
Window with 1000 buttons: Swing 24 MB and .7 sec, SWT 13.6 MB and .35 sec.

This on Windows 2k with Sun's JDK 1.5. None of them is particularly stellar, but Swing is a hog.

[...] nothing prevents you to develop and use your own LnF if you don't like the provided ones.

Let us see... Yes, boredom prevents me. SWT looks good (or as bad as the rest on my OS) without any efforts.

Other bad news related to SWT: only the Windows implementation is decent performance-wise;

Some years ago I tried eclipse on my old iMac DV, and it barely run at all (whereas other Swing programs just refused to even try). On my old Linux machine running Sun's JRE it worked, not very fast but usable.

Well, guess what: I just downloaded eclipse for my Ubuntu system, and it runs quite fine. Even though (or maybe because) it uses gcj. It is not as snappy as on Windows, but to tell you the truth Gnome is not either as snappy as KDE.

the documentation is far from the level of what's available on Swing;

In my limited experience I don't have complains.

SWT programming requires manual ressource-management; portability is inferior, some features not being available on all supported platforms.

The rest of your concerns should be answered by people more knowledegeable than myself, like Chris Grindstaff. There are one other aspect of SWT which is probably of interest in this forum: SWT is free software. Swing is not, at least until this Harmony thing came along.

For what platform(s)?

Posted May 26, 2006 20:49 UTC (Fri) by kevinbsmith (guest, #4778) [Link]

I couldn't find any mention of whether this new code would be cross-platform, or target only one environment. One project I work with won't invest the time to become compatible with Free Java tools until a Free Swing is available for MS Windows, and classpath has shown no indication of wanting to do that.

A cross-platform tool that only works on one platform is like a....(insert humorous analogy here).

Kevin