Linked by Eugenia Loli on Fri 7th Dec 2007 06:25 UTC, submitted by poundsmack
Qt Jambi ships as a single Java library, or JAR (Java Archive) file, plus a handful of tools, including an interface layout and design tool, and an Eclipse plug-in. Trolltech uses its vaunted Qt C++ library as the GUI engine and puts Java wrappers around it. This approach uses the JNI (Java Native Interface) to call the necessary functions from Java. More here.
Thread beginning with comment 289418
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[11]: Unconvinced
by mikeurbandz on Fri 7th Dec 2007 21:17 UTC in reply to "RE[10]: Unconvinced"
mikeurbandz
Member since:
2007-10-29

> You are comparing Qt to some magical free
> alternative that you believe has equal features

Well, if you are going to limit yourself to C++. Then yes, there might not be anything out there with equal features.

> See here for examples of widgets:
> http://doc.trolltech.com/4.3/gallery-windowsvista.html

Those look ok. So maybe I just haven't used an app built with the latest version of Qt on Windows. The current crop of Qt apps on Windows, for the most part, looks pretty awful. Apparently many of them haven't been updated for Vista support.

> So why are you arguing based on the pricing of
> the C++ version of Qt?

Because it was the version in question. Qt Jambi is still pretty expensive. Considering what it is competing with.

> Java is a nice option with excellent IDEs, but
> once you get outside the Java world and have
> to interact with the underlying system, things
> get ugly fast.

Well, it depends on what you mean. if you mean for desktop integration? (things like system tray icons, popup messages, and such), than interacting with the native Windowing environment in Java is pretty easy using JDIC. If you mean calling underlying system APIs? Well, it's possible in Java. But discouraged. Because once you start calling underlying system APIs, your cross platform capability becomes pretty much non-existent.

> Performance and memory consumption is not
> fantastic either.

Performance is on a par with C++ these days, and in some cases even exceeds C++. Java can do what are called speculative optimizations at runtime based on how an application is actually being used that are impossible for a static compiler to perform.

As far as memory consumption, most Java apps I write don't consume any more memory than a complex C++ app would. And it's not a big issue today anyway with RAM as cheap as it is.

> Haven't used a scripting language like python
> yet, mostly because of problems with deployment and
> I don't consider a weakly typed language suitable
> for complex app development.

The deployment problems can be solved with tools like freeze, and py2exe. As far as weakly typed, I agree with you on that point. I don't use Python for complex applications because of the weak typing. I usually use Java then. But for smaller jobs, I will often use Python, and then just use py2exe on the app and package it up with a native installer. The end user never even knows the difference, or even that it is written in Python.

Reply Parent Score: 1

RE[12]: Unconvinced
by leos on Fri 7th Dec 2007 21:38 in reply to "RE[11]: Unconvinced"
leos Member since:
2005-09-21

Well, it depends on what you mean. if you mean for desktop integration? (things like system tray icons, popup messages, and such)


Yeah that's pretty much what I mean (also more complex things like sending messages to other windows or launching default apps for certain filetypes). It seems things have been getting a lot better lately with Java 6. However it still seems like it's an addon, rather than built-in functionality. Perhaps this perception is based on my lack of knowledge about updated versions of Java, but have a look at the screenshots on the JDIC page (under demos). https://jdic.dev.java.net/ They are all terribly ugly with no anti-aliased fonts, bad widget spacing and margin problems. I'm sure all of these things can be fixed, but it seems like it all requires work to make it look half decent, instead of just being good out of the box.

Well, it's possible in Java. But discouraged. Because once you start calling underlying system APIs, your cross platform capability becomes pretty much non-existent.


Yes, sometimes one has no choice ;) It's just more complicated than it would be in C++.

Performance is on a par with C++ these days, and in some cases even exceeds C++. Java can do what are called speculative optimizations at runtime based on how an application is actually being used that are impossible for a static compiler to perform.


I know the theory. But the reality is that complex Java applications tend to use a lot of RAM and act a big sluggishly. This is becoming less and less of a problem as time goes on, resources become cheaper, and Java gets faster (1.6 has made great strides here).

Overall though I'm not against Java. It is definitely a fine language and right now my second choice, and may eventually even become my first choice (especially now that it is starting to get open source goodness).

The deployment problems can be solved with tools like freeze, and py2exe.


I'll have to look into those. If they don't impact the exe size too badly it would be great to try them out.

Reply Parent Score: 3

RE[13]: Unconvinced
by mikeurbandz on Fri 7th Dec 2007 21:49 in reply to "RE[12]: Unconvinced"
mikeurbandz Member since:
2007-10-29

> a lot better lately with Java 6. However it still
> seems like it's an addon, rather than
> built-in functionality.

It is an addon right now. It's scheduled to become part of the the Java core at some future date. But right now, it's a SwingLabs project. SwingLabs is always a good thing to watch. It's sort of an open source community driven playground for new desktop development features that have a chance of becoming part of the Java core once they mature enough. There's a lot of nice components and such you can get from from SwingLabs, things like tree tables, find/search components, etc.

As far as Java applications feeling sluggish, more often than not, that can be blamed on the programmer of the application not understanding the Swing threading model, or other things (not understanding that Strings are immutable for example, so they use a String instead of a StringBuffer (which is mutable) in a loop, and then end up creating and destroying thousands of objects for example).

> I'll have to look into those. If they don't
> impact the exe size too badly it would be great
> to try them out.

Well, they do impact the exe size significantly, because they bundle the interpretor within the exe. But then again, if you are currently statically linking Qt, your exe files are probably huge anyway.

Another thing to be aware of, is that py2exe doesn't actually produce native code. It just bundles the Python source inside an exe with an interpretor that runs in. In other words, if keeping your source is a secret, it's a problem. Cause anyone who knows how to take an exe apart can get at the original python source.

Reply Parent Score: 1