Tom Tromey (Red Hat) who wrote the GCJx as a extension to GCC to support Java 1.5 features among other changes has proposed a merge with ECJ, the Eclipse compiler from the Eclipse Foundation. The ramifications of this change are rather interesting.
Reconsidering gcjx
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Sounds pretty big of him to suggest scrapping something that he likes making in favour of something better from elsewhere. It would be nice to see this happen from two perspectives:
-getting stuff closer to current java specifications (1.5)
-demonstrating that people with differences of opinion over licensing can still share code
Personally, the idea of integrating a java compiler written in java into a native compiler written in c hurts my head and I certainly respect the people who do this stuff.
So.. assuming gpl3 is compatible with the epl (as Tom believes), if Qt is released under gpl3 could we see Qt-SWT?
If Qt-SWT existed, would anyone still be interested in Trolltech’s upcoming Qt bindings for Java?
I’d love to see a Qt-SWT. I wrote a java app (just for myself) a while back which can use different frontends. On Windows, I use the SWT frontend. On Linux I use the KDE frontend (since I use KDE). There is also a Swing frontend for more cross platformness. If I could use the SWT frontend on Windows and and the SWT(Qt) frontend on Linux, I’m not sure I’d want to keep up the KDE frontend (documentation is a bit lacking yet for the KDE/Qt bindings, though that would surely change when Trolltech releases their own version).
Basically, it would be cool if SWT would offer ‘native’ widgets for KDE users as well as Gnome users; up until now, license issues have precluded that.
Then again, if Trolltech’s Qt bindings work well crossplatform, maybe I’d just use that, though that would leave Gnome users out in the cold (but since my app isonly used by me it doesn’t really matter). I venture though that more people would be familiar with SWT than with Qt though, so I still think Qt-SQT would be a nice way to get some apps like Azureus looking better in KDE. Be interested to see where this goes.
Edit: the possibility of gpl3 Qt would of course have to wait a while, at least until ’07 or whenever the final gpl3 is released. Trolltech’s bindings may come a little quicker, though that leaves me to wonder how long KDE4 will be in coming (to Debian lol). It’s a slow race to ’07! Guess I’m glad only that one program I use frequently is a GUI enabled java app
Edited 2006-01-30 01:50
My interest in QT for java Vs. Qt bindings for SWT would depend mostly on performance. On the machines I’ve used most often, the linux versions of swt applications have been orders more laggy than OSX or Windows. Partially I’d like to see azureus and eclipse blend in better with KDE, but mostly I’d just like them to run better on the computers I use.
Emerson: if you have any cases where an SWT application is more laggy under Linux than Windows or OSX, please post a bug at bugs.eclipse.org/bugs against SWT and I will investigate it, or find me on IRC (#eclipse on irc.freenode.net).
Switching perspectives is noticably faster on Windows then GTK.
I also think that Tom is being brave to look at the replacing GCJX with ECJ – it’s always hard to be objective about these kinds of choices when you’re so closely involved with one of them. Kudos.
Having read the gcc mailing list threads on this, I think that switching to ECJ is a worthwhile endeavour. I believe that we would gain more than we would lose – and indeed we don’t have to lose much; the good gcc front-end that GCJX illustrated is still in CVS and can be picked up by other front ends as a great example for future works.
Also, as far as I understand it, the Qt Bindings from Trolltech are just that, bindings.
They essentially just provide a thin Java adaptation layer to Qt. Things like Qt-SWT add quite a lot more code than that to the stew.
[edit] Added comment on the actual story, not just the Qt angle
Edited 2006-01-30 12:29
SWT is a GUI framework, Qt is an application development framework, there’s a whole load of classes for lists, data-access and networking in there if you want.
SWT/Qt won’t happen as it would force SWT to be licensed under the GPL, which isn’t going to happen.
Personally I don’t see why, if you’re willing to ditch Swing, you wouldn’t just move over to Qt entirely. Qt 4.x is available under the GPL for all platforms, and I imagine the same is going to be true for the bindings. It’s a whole lot easier to pick up than SWT, and it’s just as fast, if not faster.
any plans to bring the implementation closer to Sun’s specification is always a good idea. Provides more choices for developers. Choices are always good
Small platforms would benefit from such an arrangement since GCC in often one of the first things ported to a new OS. Being able to use Eclipse natively and compile Java classes to native code would be a great advantage brought in from the GCJ code since not all new operating systems are written to take advantage of the latest hardware (processors in particular).
would also extend java’s reach to other operating systems which gcc supports.
True – the BSD’s would finally get some first class Java support rather than being constantly hand strung by SUN and their maze of time wasting red tape.
For the uninformed, what exactly is a “java compiler”? Does this mean that one can run java applications without Sun’s JRE?
a java compiler compiles java source code into java bytecode – which can be run by any Java VM.
In this case however, gcj will compile the bytecode into native code, thereby enabling it to run without a Java VM.
Not quite:
GCJ can
1) Convert Java source files created by programmers to bytecode (this is what the Java compiler does)
2) Convert Java source files created by programmers to native code
3) Convert byte-code created by itself or other Java compilers to native code
Byte-Code is an instruction set for a virtual machine. Native code is the instruction set used by an actual machine (e.g. the x86 code used by Intel and AMP chips)
gij is an interpreter that executes a Java byte-code program by converting each individual byte-code instruction to its equivalent native code instruction(s)
This is fairly inefficient, most byte-code runtime systems use “Just-In-Time Compilation”. Here, a portion of the byte-code is converted to native code, and the application starts executing. When it finishes with that portion of code, another portion of code is compiled to native code. Some of this native code is cached. As programs tend to do the same thing all the time, they’ll tend to use the same native code all the time, so instructions won’t have to get compiled that often.
To answer the grandparents post, a traditional compiler takes human-readable instructions entered by a programmer in a programming language like C++, and converts it to the machine code. This is the the set of numbers fed to a CPU like Intels Pentium that consitutes a program.
Because Java compiles to a virtual machine, developers differentiate between “Java compilers” which compile files written by programmers in the Java language to byte-code programs (the machine code of the virtual machine), and the other systems like interpreters and just-in-time compilers that actually convert that to machine code for the maching on which the program is currently running.
if Qt is released under gpl3 could we see Qt-SWT?
That might help, though the lack of Qt-SWT is more a matter of developer resources than licencing.
Qt-SWT makes most sense on X11, and Qt3/X11 is multi licenced, including QPL, which is compatible with almost any open source licence
If someone had felt a strong enough need to Qt-SWT for Unix/Linux, they would have implemented it.
If someone had felt a strong enough need to Qt-SWT for Unix/Linux, they would have implemented it.
And they do, like Kaffe’s Qt AWT backend or Classpaths Qt4 based AWT peers.
http://www.kaffe.org/screenshots_qte.shtml
http://developer.classpath.org/mediation/ClasspathShowcase#head-f83…
just try eclipse under linux and windows….
eclipse is faster on windows….
use netbeans, intelij or jbuilder… you get similar performance on linux and windows
Very true. I’m personally a linux guy but I own a Windows laptop. Eclipse is very very slow to respond on Linux and very snappy on Windows running the same version of the JVM’s. Every other Linux app written in gtk/qt runs beautifully. Even C# apps are remarkably responsive, I’m suprised the fact that eclipse is so slow isn’t brought up more often.
PS: I’ve used eclipse for a lot of course work across many different versions of Linux and it’s never been close to Windows in terms of speed.
My employer has bought Rational Software Architect 6, which is based on Eclipse.
In my experience, the modeling part (wich is extensively graphics based) works a lot better in linux than in windows. Then probably what makes Eclipse slower on linux is not related to SWT?
Rivas