Linked by Eugenia Loli on Sun 29th Jan 2006 23:52 UTC, submitted by Anonymous
Java 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.
Order by: Score:
...
by kamper on Mon 30th Jan 2006 01:15 UTC
kamper
Member since:
2005-08-20

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.

Reply Score: 4

Qt-SWT?
by MamiyaOtaru on Mon 30th Jan 2006 01:45 UTC
MamiyaOtaru
Member since:
2005-11-11

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

Reply Score: 2

RE: Qt-SWT?
by Emerson on Mon 30th Jan 2006 04:21 UTC in reply to "Qt-SWT?"
Emerson Member since:
2005-09-19

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.

Reply Score: 2

RE[2]: Qt-SWT?
by vektor on Mon 30th Jan 2006 07:12 UTC in reply to "RE: Qt-SWT?"
vektor Member since:
2005-08-07

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).

Reply Score: 5

RE[3]: Qt-SWT?
by Noodles on Mon 30th Jan 2006 14:58 UTC in reply to "RE[2]: Qt-SWT?"
Noodles Member since:
2005-08-12

Switching perspectives is noticably faster on Windows then GTK.

Reply Score: 1

RE[2]: Qt-SWT?
by Stephmw on Mon 30th Jan 2006 12:23 UTC in reply to "Qt-SWT?"
Stephmw Member since:
2006-01-30

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

Reply Score: 1

RE[3]: Qt-SWT?
by BryanFeeney on Mon 30th Jan 2006 16:59 UTC in reply to "RE[2]: Qt-SWT?"
BryanFeeney Member since:
2005-07-06

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.

Reply Score: 2

good idea
by Mr. Tan on Mon 30th Jan 2006 01:47 UTC
Mr. Tan
Member since:
2005-07-08

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

Reply Score: 2

Small platforms
by SamuraiCrow on Mon 30th Jan 2006 02:04 UTC
SamuraiCrow
Member since:
2005-11-19

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).

Reply Score: 1

java's reach
by Mr. Tan on Mon 30th Jan 2006 02:31 UTC
Mr. Tan
Member since:
2005-07-08

would also extend java's reach to other operating systems which gcc supports.

Reply Score: 1

RE: java's reach
by kaiwai on Mon 30th Jan 2006 06:44 UTC in reply to "java's reach"
kaiwai Member since:
2005-07-06

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.

Reply Score: 1

Gcjx explained?
by bubbayank on Mon 30th Jan 2006 06:34 UTC
bubbayank
Member since:
2005-07-15

For the uninformed, what exactly is a "java compiler"? Does this mean that one can run java applications without Sun's JRE?

Reply Score: 1

RE: Gcjx explained?
by Matzon on Mon 30th Jan 2006 06:45 UTC in reply to "Gcjx explained?"
Matzon Member since:
2005-07-06

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.

Reply Score: 3

RE[2]: Gcjx explained?
by BryanFeeney on Mon 30th Jan 2006 17:08 UTC in reply to "RE: Gcjx explained?"
BryanFeeney Member since:
2005-07-06

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.

Reply Score: 2

RE: Qt-SWT?
by anda_skoa on Mon 30th Jan 2006 12:50 UTC
anda_skoa
Member since:
2005-07-07

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.

Reply Score: 1

RE[2]: Qt-SWT?
by Morty on Mon 30th Jan 2006 15:08 UTC in reply to "RE: Qt-SWT?"
Morty Member since:
2005-07-06

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...

Reply Score: 2

RE[3]: Qt-SWT?
by collinm on Mon 30th Jan 2006 14:24 UTC
collinm
Member since:
2005-07-15

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

Reply Score: 1

RE[4]: Qt-SWT?
by ecko on Mon 30th Jan 2006 15:41 UTC in reply to "RE[3]: Qt-SWT?"
ecko Member since:
2005-07-08

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.

Reply Score: 2

RE[5]: Qt-SWT?
by rivasdiaz on Mon 30th Jan 2006 16:37 UTC in reply to "RE[4]: Qt-SWT?"
rivasdiaz Member since:
2005-07-07

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

Reply Score: 1