Qt Jambi, Trolltech releases Qt for Java

Hardingfela writes "Trolltech has released a preview of its 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 license (final release will be also available under an open source license) and download."

Comments

Please Wait... Okay? (Y/N)

[Doomedsnowball]

From the white paper:

The Qt Jambi Generator is a command-line tool that reads class definitions written in C++ and generates code that maps a C++ library onto an equivalent Java API. The generated code ensures that method calls made in Java are redirected to the corresponding method in the C++ library. The generator supports a selected subset of C++, covering the most common constructs such as multiple inheritance and operator overloading.

Well, I for one welcome our new void setText(String overlords);

Mekka Lekka Hi...

[Reverend528]

Mekka Hiney Ho.

Re:Mekka Lekka Hi...

[glarvat]

Me without my mod points... I actually found this quite funny rather than offtopic. I guess the moderators never watched Pee-Wee's Playhouse.

Re:Mekka Lekka Hi...

[Reverend528]

I'm glad to see someone got the reference.

Re:Mekka Lekka Hi...

[BenjiTheGreat98]

The only reason I even opened this story was to see if anybody would make a PeeWee joke.

Great..

[Ramble]

So now I get to see Java apps using the ever horrible QT as well as compiled binaries?

C bindings?

[mrsbrisby]

When will we see bindings for the most popular language?

Re:C bindings?

[Anonymous Coward]

When will we see bindings for the most popular language?

Everytime when their C++ bloat becomes *.o ...but why do you care about Qt?

Re:C bindings?

[Anonymous Coward]

+3 Insightful? I'm guessing the ones who modded that aren't programmers.
  GUI programming in C is a *pain*, it's awful beyond words. I hate GUI programming, but python + qt (pyqt) actually works very well for that, Qt with C++ requires that awful moc, but at least it's survivable.
  If the parent knew anything about Qt and C, he wouldn't have suggested it at all.
  For the record, yes, I have done Qt programming with C++ and python, a lot of C coding (for about 10 years), so I'm familiar with all the different aspects in this, unlike, obviously, the parent.

Re:C bindings?

[The Snowman]

GUI programming in C is a *pain*, it's awful beyond words.

Nah, it isn't all that bad. See, all you have to do is make a structure for your window. Then you set all the properties using preprocessor constants. Next you call some function and get a handle, which is like an object, but isn't. And, since it's a primitive, you can even use your window handle as a mouse handle, icon handle, etc. so it's really versatile! Also, creating a simple GUI in C is a short 50 lines of code, anyone can recite that from memory. Plus, you have the added advantage that C GUI code is tied to your architecture, so you can't port it from Win32 to X to MacOS without a lot of trouble. See? It isn't all that bad!

Re:C bindings?

[Bill Dog]

+5 Insightful? I agree that GUI programming in C is a pain (and I speak from past experience on this), but GGP was simply asking a question. How come just because you don't want to do GUI programming in C means that someone else shouldn't be allowed to?

Trolltech is obviously trying to branch out and expand the uses of their toolkit to other popular languages. Java is a no-brainer. I wouldn't be surprised if they targeted C# after that. And support for C, which is still very popular, seems like it could be added via the precompiler that's required for their C++ binding.

Re:C bindings?

[conradp]

I wouldn't be surprised if they targeted C# after that.

There's already an open source project called QtSharp http://qtcsharp.sourceforge.net/ that does just that, but it looks like the project has been dormant for a couple of years.

Even without using QtSharp, Qt provides a way to write ActiveX wrappers around Qt objects, which can then be dropped into C# forms and applications.

Re:C bindings?

[mrsbrisby]

+3 Insightful? I'm guessing the ones who modded that aren't programmers.

Fortunately the C++ fanboys swooped in to -1 me.

GUI programming in C is a *pain*, it's awful beyond words.

Maybe you need practice. Much of GNOME is written in C. My own schism tracker is written in C. I don't know what you find intolorable about C, but Java programmers are the erotic furries of programming, and C++ programmers seem to be completely oblivious as to what's wrong with their favorite language.

I hate GUI programming,

Probably because you're not any good at it.

but python + qt (pyqt) actually works very well for that,

You are completely detached from reality, aren't you?

Qt with C++ requires that awful moc, but at least it's survivable.

Never mind that MOC isn't C++. It's a completely different (and incompatible) language designed to make up for an enormous deficiancy in C++. The fact that the QT people chose C++ for it's popularity instead of it being "a good language" should tell you something.

If the parent knew anything about Qt and C, he wouldn't have suggested it at all.

Post hoc...

For the record, yes, I have done Qt programming with C++ and python, a lot of C coding (for about 10 years), so I'm familiar with all the different aspects in this, unlike, obviously, the parent.

So you've been wasting your time because you're still a mediocre programmer living in a fantasy world. And we're supposed to take your word at it? I'm not suggesting anyone take my word for anything- I can or do back up everything I have to say on any subject, including the one about you being nearly incompetent.

Consider for a moment that GNOME is a very large, very complicated, and very strongly backed interface, set of guidelines, libraries, applications, and a desktop. Now consider that the gross majority of it is written in C. Presume all you will about my professional history, are you really saying that you're smarter than everyone at SUN, IBM, Novell, Red Hat, and all the people who have made GNOME what it is today?

QT is a piece of shit. It's a terrible user interface that has had to be completely reinvented incompatibly four times in a language with perhaps the smallest imaginable user base, and by singing its praises, you expect to be taken seriously?

On the off chance I'm completely wrong about you, take a twenty minute tour of Objective-C, Xcode, and Interface Builder, and then tell me that you still want to bear QT's children.

Re:C bindings?

[mrsbrisby]

+5 Insightful? I agree that GUI programming in C is a pain (and I speak from past experience on this), but GGP was simply asking a question. How come just because you don't want to do GUI programming in C means that someone else shouldn't be allowed to?

Actually, no, I really was just being a dick. :)

Because QT is written in a fictional programming language (called MOC) - something that makes it different from almost every other toolkit or GUI out there, it's very hard to take it seriously. Think about it: Rather than use a language that is actually good at object-oriented and event-driven programming, (like Python, or Objective-C, or Java), they chose to hang on the popularity bandwagon- they targetted C++ users for the sake of targetting popularity.

That mindset is extremely frustrating: I like to use the best tool for the job, and I've never found a job where C++ was the best tool for technical reasons- only ever because ``that's what the rest of the team is used to/trained with/proficient at'', and I'm sorry, that's a mind-blowingly stupid reason to keep those illiterate programmers around.

Targetting C (or even Objective-C) means that the toolkit or GUI actually has a real interface for programming and interoperability, and not some gross kind of preprocessor or glue code...

Finally

[oever]

The combination of fast, good looking Qt widgets, the clean way of writing applications with Qt and the ease of coding that java and Eclipse offer make for a very attractive platform for clean and fast development of graphical applications and great alternative to pure java or mono applications. As long as the Qt library can be easily distributed with the applications that use it, the fact that you're more than one framework should not be a problem.

If version 6 of java will not bring the improvements to the GUI that are promised, Qt + Java is a very attractive alternative for crossplatform development.

Personally, I like Qt's widgets a lot (even though version 4 has a few funny regressions) and the logic used for building the GUI is much nicer than what I know from Swing and AWT. I wish the trolls the best of luck and hope that KDE and free software in general may benefit from this development.

Re:Finally

[Anonymous Coward]

The combination of fast, good looking Qt widgets, the clean way of writing applications with Qt and the ease of coding that java and Eclipse offer make for a very attractive platform for clean and fast development of graphical applications and great alternative to pure java or mono applications.

You must be in marketing.

"The clean way of writing applications with Qt"?!? You mean with its own required precompilation step in lieu of using modern C++ language facilities? You must not be a developer.

Re:Finally

[The Snowman]

"The clean way of writing applications with Qt"?!? You mean with its own required precompilation step in lieu of using modern C++ language facilities? You must not be a developer.

Just run "qmake" whenever you add a new compilation unit (i.e. .cpp file) and then regular "make" to compile. Qt handles the rest. It really isn't all that complex. Also, the MOC is in addition to the precompiler. The MOC runs first, then the standard C++ compiler stack.

Re:Finally

[Tanuki64]

even though version 4 has a few funny regressions

What do you mean?

Re:Finally

[oever]

E.g. the disappearance of QHBox and QVBox. They were used a lot.

Re:Finally

[Tanuki64]

Strange, when I used Qt 3.x I never noticed those classes. For some reason I always coded like Trolltech proposes it for 4.x:

QWidget *vbox = new QWidget;
QPushButton *child1 = new QPushButton;
QPushButton *child2 = new QPushButton;

QVBoxLayout *layout = new QVBoxLayout;
layout->addWidget(child1);
layout->addWidget(child2);
vbox->setLayout(layout);

Wonder why QVBox and QHBox existed in the first place. They don't even inherit from QLayout, but 'emulate' a QVBoxLayout/QHBoxLayout. Maybe if you ask Trolltech they reimplent it in 4.2.x based on the layout classes as convenience classes? I noticed TT is very open for that kind of requests.

Re:Finally

[oever]

I've heard some core KDE devs complain about it so maybe it will return. I'm not that disturbed about it that i'll harass them about it. I'm amazed that Q[HV]Box did emulation.

Only a TOOL would use this

[Anonymous Coward]

It will take 10,000 days to code anything useful.

Never.

[Penguin Programmer]

Never. Those of us who use C are smart enough to know that QT is fucking ugly and that GTK is far superior.

Re:Never.

[Zephiris]

Now only if GTK+ decently supported Windows operating system versions, actually used native style/widgets, and weren't so mind-numbingly bad at performance. The native Java 6 Swing GUI stuff is actually faster than GTK+ now, despite still being in beta (try it yourselves and see!). "GTK+ enthusiasts" tend to be rabid about 'everyone should use this!', but it's overwhelmingly lackluster in performance and memory usage. People should make their own analysis and look into alternatives, not just take the GTK+ word for it. Qt is very well performing, very well behaving (it effectively wraps around native platform widget/engine stuff), and looks like a dream. GTK+ is (disclaimer: in my personal opinion) almost as bad as old X11 apps that just use ancient versions of Motif or Athena. GTK+ just doesn't blend in very well, and (again, opinion) leaves everything to be desired over more robust and compatible libraries.

Re:Never.

[abigor]

C is a terribly inefficient language for GUI programming - it's all about time to market. How many commercial products can you name that use GTK? Meanwhile, Qt is successfully used all over the place, from Google to Adobe to all that phone stuff.

Re:Never.

[Almahtar]

I appreciate (and not sarcastically) that you took the time to designate that this is your opinion. I'm no GTK+ fanboy, but I think it's cool that you had the class to state your opinions as just that: opinions.

Re:Never.

[The Snowman]

I think GTK+ looks fine, but performs slowly. In Linux it isn't bad, not as quick as QT (and I'm not talking KDE bloat but the underlying QT libraries), but sucks in Windows. FYI this is based off my impression of the only GTK+ app I have used in Windows, GIMP, but GIMP was much slower in Windows than Linux. The GUI just seemed laggy to me. Moving palettes around, menus, etc. just wasn't as snappy as in the Linux version or in other Windows apps (including QT apps).

Re:Never.

[Anonymous Coward]

He wasn't showing class, he was being a wimp. He only threw that part in there to try to appease all the tightly-wound sphincterheads around here who would fly off the handle and mod him down. Everything here is opinion.

Dereference

[glarvat]

Subject: Only a TOOL would use this
by Anonymous Coward on Monday July 31, @01:31PM
It will take 10,000 days to code anything useful.

Another, although not as funny, reference to Jambi from Pee-wee's Playhouse.

Re:Dereference

[Anonymous Coward]

Actually, I believe this is a reference to the Tool song "Jambi", from their recent album "10,000 days". Unless you were intentionally dereferencing incorrectly to be funny, in which case, you should try harder to be funny next time.

Windows Primitives

[XenoBrain]

So will Qt Java be supporting widget primitives in Windows like it does for other languages? I'll bet it does, and that will be quite cool, as we will finally see Java apps that truly look & feel native!

Been Using This

[miyako]

I've been playing around with this for a few hours. Running some of their demos, things seem very snappy, and the applications look better than most Swing/AWT applications. I've always been fond of the way Qt works, and I think it will be nice to have the option of using it with Java.
Of course this is still a developer preview. After playing around with it for about 4 hours, I still can't get an application to launch, except for the demos that it ships with. This is probably due to my own ineptitude, but if I'm having trouble with it, I'm sure other developers will as well. I suspect that once there is an official release, things will be made easier (or the documentation will be made clearer) and there won't be so many problems.
PS: If anyone has played around with this and had success, maybe you can help me out. I created a project in eclipse, added the qtjambi.jar file into the classpath, set the PATH to qtjambi-linux-preview/bin and LD_LIBRARY_PATH to qtjabmi-linux-preview/lib, whenever I try to launch an application, I get
failed to load library: 'qtjambi'
Exception in thread "main" java.lang.UnsatisfiedLinkError: no qtjambi in java.library.path
...
Anyway, I think it will be really nice once I can figure out how to use it properly.

Re:Been Using This

[Anonymous Coward]

You can get info about the actual library path like this:

System.out.println(System.getProperty("java.librar y.path"));

If the library path is no ok, you can set the property to a better value.

Re:Been Using This

[mmusson]

I would try setting java.library.path to qtjabmi-linux-preview/lib using the -D command line argument when you run your test program.

Re:Been Using This

[Anonymous Coward]

This is probably the kind of thing you can ask about on their feedback list, as mentioned at the bottom of this page:

http://www.trolltech.com/developer/downloads/qt/qt jambi-techpreview

Just one question...

[kaffiene]

Why?

Re:Just one question...

[usidoesit]

yes, why when you could use the python bindings?

Re:Just one question...

[UngodAus]

Didn't you even take time to read the FAQ? Why? Because customers have been requesting it. What better way for a company to make money than to supply something that..... wait for it. The Customers Have Requested.

Re:Just one question...

[Tanuki64]

Why not?
No serious as I explained in another forum on a similar question:

For a Java guy? Don't know. For me? Easy to explain. Due to my job in the last 5 - 6 years I hardly had the chance to code in Java. Everyting was C/C++ + Qt. For quite some time I felt a bit sorry that I was more and more losing my Java knowledge. Oh, from time to time I decided just for practice to start a little private Java project. But sooner or later I came to the conclusion: 'Why bother? What I do now can be done so much easier with C++ and Qt'. That alwas was the time when this 'project' died. A few days ago I installed QtJambi and it felt comfortable. I am quite experienced in Qt, its layout manager, widgets. Knowing them I started coding in Java/QtJambi as if I had done so for years. I'd say an experienced C/C++/Qt developer, who has never written one line Java can do serious development in Java after a few hours skimming through a beginners Java book.

Design flaws in QT?

[Anonymous Coward]

Has anyone using the QT API noticed that its behavior when it hits an error isn't well-defined or easily detectable by the user of the library? For instance, look at QFileInfo's size member function.

Returns the file size in bytes, or 0 if the file does not exist or if the size is 0 or if the size cannot be fetched.

So, if it returns a zero, that could mean that there is a problem that your application may need to do something about or report, or the file does not exist, or the file exists but is zero bytes. How incredibly uninformative. But at least that member function documents its behavior it something bad happens. As I glanced through the other member functions, it became apparent that most of them do not bother to say what happens when the shit hits the fan. No return codes, no exceptions, no nothing.

Sadly, many of the classes in the library are like this. Sure, I could write an application using QT, but I wouldn't know how to handle failures simply because QT doesn't document the behavior in those cases. This is surprising, considering that QT is considered a quality library that is worthy of use in commercial applications. Granted, most of the time, we'll only execute the "happy path", and there will be no problems with this lack of documentation. However, we shouldn't throw caution to the wind and assume everything will be OK.

I can't help but think that this could have been avoided if QT would have embraced exceptions. Then, the API could avoid using C-like return codes and maintain its elegance but still report errors in a manner that is convenient for handling and documentation. QFileInfo::size() could be documented to throw QFileNotFoundException and QIOException, for example, making it easy for the user of the class to tell what happened. But they would have to rethink some of their code if they did this, because the naked-pointer-filled code that they have now would not be exception safe at all. I doubt that they will make the switch any time soon because everyone seems to be so happy with it the way it is today.

whats the point in yet another, public void foo()

[gnufied]

For those of us, who want to be more productive or rather expressive, can try ruby bindings: http://developer.kde.org/language-bindings/ruby/in dex.html Its still doesn't works on M$ Windows(and if you managed to compile it on Windowz, then kindly send me howto?), but is a joy to develop on Linux.Just don't forget to throw in http://rubyforge.org/projects/rubyinline/ , when you want to do something that really takes CPU cycles and memory. I can't really see the point of Java(yuck) bindings.Though people at KDE camp were happy, finally they can have fully functional java plugin for konqueror. bless them.