Comments

The preview is based on JDK 1.5 from Sun and we require quite a bit of the 1.5 language features to work, like generics for type safe signal emittions. We intend to make it work but Gnu Classpath and GCJ, but we haven't begun that work yet.

None of which is relevant, and a sentence like this is only spreading Fear Uncertainty and Doubt (FUD). Please refrain from trolling over an off topic subject.

The feature completion is in fact very relevant, as you can see from the first response. It's not a question of FUD when it is sadly very true that open source java is far behind sun java. It's a problem that we need to solve, and crying FUD only gets in the way.

> The feature completion is in fact very relevant, as you can see from the first response.

Yes, feature completion is relevant, but nobody except Gunnar went into features, everybody else was just talking about works/doesn't work. The QT Java bindings need Java 1.5 and GCJ just doesn't support that yet (gcj-eclipse branch will lead to that). GNU Classpath is on 99.32% Java 1.4 compliance and was over 90% on generics branch for a long time now (but the test suite on http://www.kaffe.org/~stuart/japi/ is down right now {there was talk about integrating generics branch into head some time ago, maybe that's it}) and Google SOC is sponsoring a project to plug one of the biggest missing chunks of code, javax.management.*.
So if you ask me, by the time GCJ can handle Java 1.5 GNU Classpath should be able to handle the QT Java bindings too.

> It's not a question of FUD when it is sadly very true that open source java is far behind sun java.

What exactly do you expect? Java is a Sun programming language.

About GCJ being slower then Suns Java implementation, that is irrelevant. There is lots of potential in GCJ for speed that isn't exhausted right now and there is some interesting embedded work going on were I dont see Suns Java implementation going.

I have programmed Java for many years, and just read through the whitepaper. I think it is a good thing Qt is available for Java - it will make the KDE environment richer over time, when people can contribute with Java apps. However, I am not convinced the signal-slot mechanism is better than the listener pattern used by Swing etc.

This example is given in the whitepaper. The second argument is ugly in my eyes - a String with code in it?

slider.valueChanged.connect(spinBox, "setValue(int)");

That the Qt example is shorter does not matter - the number of lines of code is irrelevant.

I am not convinced that Qt does offer better tools for the programmer. However, hopefully the result for the user is still worth it - Qt apps have a better "feel" than Swing apps for the most time.

This is not true. Code lines matter. If you have less code, there is less code to maintain and the probability of bugs is reduced. And the signal-slot mechanism of Qt is WAY better than the ugly listener pattern in Java. The Listener pattern is just a hack around the missing feature of real events in Java. Nevertheless, the Qt solution is not type-safe which is not so good. A type-safe signal-slot mechanism would be the best solution, but this had to be built into the language I guess, so Trolltech will not be able to fix this.

We felt that the "value(int)" approach was nicer because its less to type and we can give constructive exceptions like NoSuchSlotException which is a runtime exception, so you don't have to explicitly catch it for every connect statement.

Had Java provided a way of getting function references directly, like they have with the .class operator we would of course have used it. In lack of such an operator the string is a good alternative. At least it worked pretty good for Qt for the last 12 years ;-)

The listener pattern is one of the most clumsy and awkward parts of the Java language. Indeed, it injures an already overly verbose language. The signal-slot mechanism is an elegant solution which is infinitely better than writing event-listeners in Java.

Any particular reason you think it is awkward and clumsy? Using the listener pattern (aka Observer) really allows you to split your business logic from your view. Combine observer with Mediator in a Java app and you have a loosly coupled, easily maintainable app.

It is indeed annoying when people put their ActionListener implementation in the same class as their view and differentiate with strings in an else/if to determine which button/menu was used but that is the problem of the programmer, not Java. (Hint: search for "How to use Actions" on Google for a much better way).

The use of listener classes and the use of the MVC pattern are two entirely different things. Listeners are a method of communication between code modules. They can be used in the MVC pattern to connect events in the view to the controller, but so can other methods such as Delphis method pointers or C#'s delegates. However listener classes make it more difficult to use the MVC pattern because they dramatically increase the boiler-plate code necessary to connect a GUI event to a controller's handler.

The only significant difference between this and the C++ API in this case is that C++, thanks to its preprocessor, can beautify the fact that what you're passing in is a String. If I'm not mistaken (and I may well be), the call SIGNAL( setValue(int) ) would simply be turned into a String, as above, by a preprocessor macro.

The "string" you mention is indeed a string. It isn't a method call, it is the *name* of a method call, so the QObject dispatcher can get the message to the right place at run time. The SLOT() macro creates the string in C++, but Java doesn't have a preprocessor.

If the string bothers you, don't think of it as code, think of it as a name. In the example above, you're sending an int value to the slot named "steValue(int)".

Right. That is the only problem you could possibly find with this. Lack of compile time errors for typos. I don't think that is a big price to pay for such a powerful and concise tool like signals/slots, but to each his own.

I hope you're not one of those "if it compiles then ship it" type of people! Most of us out here in the real world at least check to see if it runs first. And when it runs we get a warning message about an unknown slot.

I have programmed Java for many years, and just read through the whitepaper. I think it is a good thing Qt is available for Java - it will make the KDE environment richer over time, when people can contribute with Java apps. However, I am not convinced the signal-slot mechanism is better than the listener pattern used by Swing etc.

This example is given in the whitepaper. The second argument is ugly in my eyes - a String with code in it?

slider.valueChanged.connect(spinBox, "setValue(int)");

That the Qt example is shorter does not matter - the number of lines of code is irrelevant.

I am not convinced that Qt does offer better tools for the programmer. However, hopefully the result for the user is still worth it - Qt apps have a better "feel" than Swing apps for the most time.

There's a free implementation which won't take much longer anymore to be a complete replacement for the official Sun Java, and that one is also going to be open sourced sometime. There's a huge army of Java programmers, and it's really better to have them in than to tell them to do C++ instead.

Out here in the real world we had just slightly over a decade when distributing Java or JRE for FreeBSD was illegal. If you wanted to run someone's Java app you had to bootstrap and build your own Java first. But even with commercial Qt you're still allowed to distribute the complete runtimes with your app.

As far as I know Java will soon be real open source software and I think that KDE could benefit greatly from supporting Java. There really is a vast army of Java developers out there and many of the appreciate open source software like I do. A main advantage of Java/Eclipse over C++/KDevelop or plain C is that greatly improves your productivity as a developer. I've personally worked first with GTK under C which seriously sucked and then with KDevelop which was quite okay for me. When I started to work for a new company I was forced to switch from KDevelop to Eclipse and I must admit that this was a very good decision. I'm now able to implement in the same time twice the functionality than I did before and that with far fewer bugs too. It's really fun to work with Java. In recent years Java wasn't well known for it's desktop applications. The applications were slow and looked pretty awkward. That has drastically changed with Java 5 and will even more with Java 6. Under Windows Java applications look perfectly integrated and on a modern PC you won't notice the speed difference to a native application. Unfortunately, this doesn't work as well under KDE. Currently Java applications use this ugly metal look. To make things worse I believe that the next Java will use GTK to draw the widgets. Anyway, I think it would be a great chance for KDE to fully embrace Java.

This might have made a difference 3 or 4 years ago, but at this time it won't make much difference. Mustang will finally have decent native L&F and SWT/JFace/RCP is already well established. You have to pay Trolltech for non-GPL compatible usage, and open source desktop developers have for all practical purposes ignored Java. Sorry, Trolltech, you're late to market.

Hahaha, is this Mr. Gartner himself or just another frustrated nay sayer? What's your source for "decent native L&F" for Mustang? And if Java has such well established rich client GUI technologies, where are the mainstream rich client applications that use it?

Swing is far away from native L&F, it's designed to be a Java GUI, not to bridge different native GUIs. SWT is nicer, but very simplistic compared to Qt, and at this point far from being cross platform. It's a pure Windows technology, with some 2nd class experimental ports. Run Eclipse on Linux and see for yourself.

"And if Java has such well established rich client GUI technologies, where are the mainstream rich client applications that use it?"

Hehe, and Qt won't change that either. You inadvertantly admitted it's a waste of time.

"Swing is far away from native L&F, it's designed to be a Java GUI, not to bridge different native GUIs."

You're clueless. There's emulation of native L&F and actual heavyweight components for native L&F, and then there's a middle ground like what Mustang is using to use some of the native APIs to get a L&F.

"SWT is nicer, but very simplistic compared to Qt, and at this point far from being cross platform."

Relax, people have very different understandings of "decent" or "fine". If Mustang's "native" L&F is good enough for you, than I might fully believe that for you Eclipse runs fine on your 64bit Linux machine, or on your Mac.

Using some native APIs for painting is not enough for L&F. It isn't even enough for L alone (think geometry management), but it definitely isn't enough for F. It might be good enough for you, but it can hardly fool Microsoft power users.

The Wwing in Mustang will probably be good enough for some in-house tools, but for retail applications? Time will tell. Java is big enough a market for more than one solution.