Trolltech has released a preview of the long awaited Java bindings for Qt 4. "Qt Jambi technology integrates Qt with the Java programming language, providing new possibilities for both Java and C++ programmers. This technology enables Java developers to take advantage of the powerful features of Qt from within Java Standard Edition 5.0 and Java Enterprise Edition 5.0." More information on the Jambi press release and tech details in the Jambi whitepaper. To get your copy sign up to the preview licence (final release will be also available under an open source license) and download. There is an FAQ
and Trolltech wants to get your feedback on the qt-jambi-interest list.
Update: Trolltech developer Gunnar Sletta provides more details in his blog.
Trolltech Releases Preview of Qt for Java
Dot Categories:
Comments
And does it support Gnu Classpath/GCJ?
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.
Bernhard Rosenkraenzer from ArkLinux has already made a version of GCJ that draws graphical objects using Qt.
That is a very different topic. Using Qt as a toolkit for drawing the native version of Swing calls is not what we're talking about here.
> And does it support Gnu Classpath/GCJ?
No it does not. The original Java is faster, more stable and more feature complete than classpath
> No it does not.
Mind if I believe the previous poster, who is the main author, over your black/white opinion?
> The original Java is faster, more stable and more feature complete
> than classpath
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.
Thanks.
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 dont see Suns Java implementation going.
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html
99.32%
Archive.org
* Oct 2004: 67.25%
* Mar 8 2005: 77.38%
* end of march 78%
http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-classpath.html
92%
http://www.klomp.org/mark/classpath/LinuxTag2006.odp
http://developer.classpath.org/mediation/ClasspathPresentations
http://developer.classpath.org/mediation/ClasspathShowcase
http://developer.classpath.org/mediation/FreeSwingTestApps
> The original Java is faster, more stable and more feature complete
> than classpath
>>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.
Of course it's relevant and true. Just because it doesn't jibe with your political ideology is what is irrelevant. You need to stop trolling.
May this ease the integration of Java applets in Konqueror? Currently it uses Lesstif/Motif for display...
No, it won't. Applets can't use Qt unless its on a company intranet or something where everyone can have the library installed.
Corrected: Applets can't use Qt unless you have the library installed.
Nobody said anything about company intranets being a prerequisite for installing the library.
I think it only uses Lesstif/Motif if the Applet use AWT instead of Swing. So it's not up to Konqueror how Applets will be displayed.
Bindings for C#/.NET/Mono were great ...
Read the FAQ. These bindings show that they are possible and Trolltech will probably do them if a business case makes sense.
This is nice news. I don't really care much for Java personally, but I can see the advantages of having Qt Java bindings, and how others find this as a welcome addition.
Off topic a little, but it's an interesting product name. Jambi is also a name of a song on the new Tool album. Also a province in Indonesia. So I am not sure I get how they came up with it.
"So I am not sure I get how they came up with it."
Jambi is the island just to the northwest of Java.
nitpicky_mode_on:
Sumatra is the island. Jambi is a province in Sumatra.
http://ariya.blogspot.com/2006/07/jambi-and-java.html
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.
Java has the ability to reference a method through its reflection API. I wonder why this wasn't used - my guess it so that the interface better matches the C++ interface.
The Qt mechanism *is* typesafe. It's not statically typed, but that's something entirely different. And most certainly it uses Java`s reflection API.
Java's way of providing access to methods using reflection is through java.lang.Class.getMethod(String name, Class argsTypes ...). This means that to get to value(int) you would have to write
try {
button.connect(x, QSlider.class.getMethod("value", Integer.class);
} catch (Exception e) {
// Handle exception
}
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)".
You have just demonstrated a problem with this, spelling. :)
So if you get the method name wrong, what happens then? I guess there is no way to find out at compile time?
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.
yeah... but who cares about java?
after all its not free.
I care.
> yeah... but who cares about java?
> after all its not free.
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.
>yeah... but who cares about java?
>after all its not free.
Java is more free than Qt.
hahahahahahaha,
Ah, needed a good laugh. Which part of the GPL makes QT less free than Sun's 'the source is closed' Java, of Kaffes GPL Java?
john.
Hahaha, I'm talking about the real world and not your little fantasy GPL world.
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.
It uses Metal by default but you can change the look and feel. There is a very nice looking and free one called Looks at:
http://www.jgoodies.com
Don't be to quick to dismiss KDevelop. We plan on having excellent Java support for KDevelop 4. Jakob has already written us a great parser for the language.
How about IntelliJ support?
Ignore the above post, was meant to be a response to another post...can't seem to delete/edit posts here.
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.
"What's your source for "decent native L&F" for Mustang?"
A recent Mustang build on my hardrive
"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."
What's the point of your lies?
"Run Eclipse on Linux and see for yourself."
I have and it runs fine.
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.