Harmony project to get a Swing/AWT implementation
Posted May 19, 2006 15:48 UTC (Fri)
by stevenj (guest, #421)
[Link] (7 responses)
The Harmony FAQ states:
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?"
Posted May 19, 2006 16:37 UTC (Fri)
by mjw (subscriber, #16740)
[Link] (3 responses)
Posted May 19, 2006 17:58 UTC (Fri)
by stevenj (guest, #421)
[Link] (2 responses)
Please, someone tell me that I misread the Harmony developers' discussion, and that there is a better reason that is not this stupid.
Posted May 19, 2006 19:45 UTC (Fri)
by nix (subscriber, #2304)
[Link]
Really extreme NIH.
Posted May 19, 2006 20:24 UTC (Fri)
by robilad (guest, #27163)
[Link]
Otoh, GPL3 will fix that at least in one direction, so it's less of a big deal anymore.
Posted May 19, 2006 20:16 UTC (Fri)
by robilad (guest, #27163)
[Link] (2 responses)
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.
Posted May 19, 2006 21:44 UTC (Fri)
by stevenj (guest, #421)
[Link] (1 responses)
Except that Classpath comes with a GPL exception that permits it to be used for proprietary products. Sigh.
Posted May 19, 2006 22:32 UTC (Fri)
by robilad (guest, #27163)
[Link]
Posted May 19, 2006 17:36 UTC (Fri)
by TwoTimeGrime (guest, #11688)
[Link] (7 responses)
This must be a new harmony project. The KDE Harmony project is more than a year old.
Posted May 19, 2006 17:52 UTC (Fri)
by rfunk (subscriber, #4054)
[Link] (6 responses)
Posted May 19, 2006 18:30 UTC (Fri)
by JoeBuck (subscriber, #2330)
[Link] (2 responses)
Posted May 19, 2006 18:36 UTC (Fri)
by rfunk (subscriber, #4054)
[Link] (1 responses)
Posted May 21, 2006 5:46 UTC (Sun)
by cthart (guest, #4457)
[Link]
:-)
Posted May 19, 2006 21:23 UTC (Fri)
by TwoTimeGrime (guest, #11688)
[Link] (2 responses)
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.
Posted May 22, 2006 9:43 UTC (Mon)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted May 22, 2006 15:01 UTC (Mon)
by yodermk (guest, #3803)
[Link]
That movement never got very far AFAIK.
Posted May 19, 2006 23:18 UTC (Fri)
by man_ls (guest, #15091)
[Link] (3 responses)
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.
Posted May 22, 2006 14:50 UTC (Mon)
by lauwenmark (guest, #37754)
[Link] (2 responses)
Posted May 22, 2006 17:13 UTC (Mon)
by philips (guest, #937)
[Link]
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.
Posted May 22, 2006 22:20 UTC (Mon)
by man_ls (guest, #15091)
[Link]
Well, guess what: I just downloaded eclipse for my Ubuntu system, and it runs quite fine. Even though (or maybe because) it uses
Posted May 26, 2006 20:49 UTC (Fri)
by kevinbsmith (guest, #4778)
[Link]
A cross-platform tool that only works on one platform is like a....(insert humorous analogy here).
Kevin
Can someone explain again how Harmony relates to GNU Classpath/Kaffe/gcj?
Harmony vs. Classpath/Kaffe/gcj?
13) Does this compete with Kaffe and Classpath?
The following GNU Classpath thread probably explains it: Where's the love?
Harmony vs. GNU Classpath/Kaffe/gcj?
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:
Please tell me there are better reasons than this....
As I understand it, they don't like working under *anyone's* auspices but their own, for no particularly clear reason.Please tell me there are better reasons than this....
It really is this stupid.Please tell me there are better reasons than this....
Not complementary at the source code level, unfortunately. Harmony vs. Classpath/Kaffe/gcj?
complementarity
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.
I know. Honni soit qui mal y pense.complementarity
> The Harmony Project - which just saw its first birthday Harmony project to get a Swing/AWT implementation
Wasn't the KDE Harmony project the effort to clone Qt or something, and Harmonizing
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.
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
Good idea. But .org is pretty crowded with other stuff too.... new naming rule
Maybe we should petition ICANN for a new .foss TLD. Hey, the museums get
a TLD, why not us?
Except RS will jump in clamouring for .fs instead of .fossnew naming rule
> Wasn't the KDE Harmony project the effort to clone Qt or something,Harmonizing
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
Actually, even after Qt was GPL'd, there were a few that wanted to continue Harmony because they wanted it LGPL.Harmonizing
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.
Swing and AWT, argh
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.Swing and AWT, argh
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.
> Underlining the deficiencies of Swing is one thing - but next time, Swing and AWT, argh
> try not to forget to also underline those of SWT to compare both.
Swing and AWT, argh
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).
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.
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.
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.For what platform(s)?