Java Binding in KDE2.1

Some folks pointed out an interview on Dot.KDE with Richard Dale. Richard is the author of the code which adds bindings to KDE and Qt for Java. What does this mean? Well, the interview has more details, but the simple answers is "KDE/Qt apps written in Java". Hopefully this means more programs.

Comments

Re:Wouldn't everyone flip if...

[Emil Brink]

Maybe they just like Java, the language, and don't give a fsck about Sun's visions about Java as a platform? I sure could agree with that, if only the compiler wasn't so darn slow... ;^) I couldn't read the interview though, it seems to have been /.ed or something.

Re:Not really useful

[mbyte]

I think you are wrong ..

If its anyway simmilar to the excelent java/GTK bindings then they use JNI to call the GTK/QT/whaterver functions. Ok .. you get some perfomance penality from JNI, but it still should be magnitudes faster than swing.

if you want speed in java, use the IBM 1.3 JDK .. its REALLY fast ... java is gaining much ground in backend and server programming .. its nice, easy threads and is quite immune against buffer overflows ;)

Re:Use Gnome?

[Fnkmaster]

Ding, ding! You don't know what the fuck you're talking about. I know I shouldn't bother with a troll like this, but every single one of your comments is without basis.

1) Java removes so-called "powerful" functionality from C++ because while great for developing apps yourself those features generally result in morons shooting themselves in the foot. Have you ever built software applications in a large team environment with extremely tight deadlines and minimal time to track down bugs? No, I didn't think so.

2) Java has been massively successful because of the above. Think again. Primarily in backend server apps and web applications. Not in client applications or applets. This is an attempt to make it more viable in those areas because a fully cross platform library with graphically rendered widgets doesn't work well yet. If you think Java has failed you must not work in anything remotely related to enterprise software.

3) I love Gnome as much as the next guy. But it's neither clean, stable, nor intuitive. This gives away your troll because frankly KDE is generally more intuitive than Gnome, somewhat more stable (clean is arguable... and aesthetic, I think Gnome takes the cake).

GNOME already working

[Mike Connell]

The same idea is already underway for GNOME

Mike.

Excellent news!

[benmhall]

What is it with people on Slashdot lately? Did anyone READ the article, or did you all just denounce it as "evil" before you lost patience waiting for the (now slashdot'd) server to go down? Seriously!

This article has been up on dot.kde.org for a few days now, and (while I initially wasn't too excited about the idea) is a very interesting read. What the author has basically done is lay the foundations for good solid bindings for any language. His initial cut was for Objective-C , and now Java.

There are no licensing issues here, as these are simply language bindings that allow you to use KDE and the very capable Qt to write GUI apps that integrate well with the rest of KDE. As was pointed out at the dot, this is meant for java the language, not java the platform. As was also pointed out, the possibility of gcj+kde bindings could eventually make for a fast compiled app in an easy to write for language.

Oh, and for the record, this was started for Gnome back in 1998:

http://mail.gnome.org/archives/gtk-list/1998-Nov em ber/msg00481.html
http://news.gnome.org/gnome-news/961253384/index _h tml

One of the things that Gnome-toting Slashdotters often criticize QT and KDE for is the lack of language bindings. Well, now they have Python, Java, Objective-C, C, Perl (in some state) and more on the horizon. So now that this has been addressed you feel you have to blast them for doing precisely this?

The page also praises GTK for it's portability. When was the last time you read a Gnome page that made reference to anything done by KDE in a good light?

Come on, everybody needs to grow up here. KDE doesn't suck, Gnome doesn't suck, Java doesn't suck. They all have their place. Java is a fun language to program in. A nice compromise between C and SmallTalk. Be nice here.

Re:Why are they doing this?

[Fnkmaster]

Completely uninformed. There is a lot of GPLed, LGPLed and BSD licensed code out there written in Java. Java is not a "closed language". Some of the implementations of some of the APIs that are released by Sun are licensed under varying degrees of closedness. Generally they are freely available, and nobody forces you to use them (they aren't part of "Java" per se, but libraries for Java, such as the J2EE APIs). There are free implementations of many of these as well, for example, look at (JBoss. It's an LGPLed implementation of the J2EE APIs.

Also, with respect to Java itself, there are free implementations of the Java compiler and the Java runtime environment as well. But using Sun's Java compiler and Java runtime IN NO WAY affects the licensing of code that has been compiled with it.

There is sometimes confusion over what "linking" and similar concepts referenced in some Free or Open Source licenses mean in the context of Java. I won't seek to open these arguments up here. I'm just pointing out that your points are completely off base and the two issues - Java bindings for KDE and Freeness are orthogonal to each other.

Replying to everyone at once..

[Stormie]

Why would you add Qt/KDE bindings to Java? Doesn't that just limit the crossplatformness of Java?

(a) Some people see merit in Java beyond its crossplatformness. Some people think it is a nice language, easy to develop in, easy to write maintainable code in. (b) Objectively, the existence of bindings for any language is a good thing for any toolkit. The absence of such bindings is a bad thing. Hence this is good.

can you say sludge? I would imagine the speed of these apps running on anything less than a Wonderbox would be like watching snails.

You are aware that Java code can be compiled to a native executable, using a compiler such as gcj? You are also aware that much of the blame for slow Java applications has been placed upon the Swing toolkit, which you wouldn't be using if you were using QT?

Why not just stick with C++ or something?

Perhaps because you are a Java programmer who is not experienced with C++ (or who doesn't like C++), and yet still wish to develop for KDE

this is all we need, kde apps that need to start a jvm to run.

Not if they're compiled to native executables..

What was the KDE developement team thinking..

Maybe that.. oops! nearly replied to a qpt troll!

KDE has had problems in the past with licensing issues..

oops! nearly replied to an Ananova troll!

Disclaimer: I'm not a Java programmer, or a KDE developer. I actually get paid for writing VB (OK, feel free to moderate me -1, "Spawn of Satan")

Re:Replying to everyone at once..

[Stormie]

Not if they're compiled to native executables..

Then you wouldn't need the bindings, stupid FUCK.

I see no reason to reply to this beyond the sheer joy of posting (and the fact that I'm bored at work), but you don't actually know what a binding is, do you, AC?

Or do you think that gcj is some sort of magic toolkit pixie that compiles all the Swing references in your Java code into calls to whatever toolkit library you happen to be using? (I hear that the next version will be able to guess which you prefer out of QT and GTK+ if both are installed!).

p.s. When you grow up, you'll realise that trolling is more fun than flaming. But it also takes more skill (even in an article involving Java and KDE!), so maybe it's out of your reach..

Re:Java is simply unusable on the desktop

[Mike Connell]

Just to correct a few points:

> Java is simply unusable on the desktop
No. Badly written Java is unusable on the desktop, especially if it uses Swing. Swing is definately a pig. OTOH I run JBuilder every day on a P2-350: it's very usable.

Debuggers: Check out visual age, it is meant to be excellent. However, having used both VC and JBuilder, I don't find any limitations in the java debugger. Why? Because I spend much less time using it. In fact I rarely need it at all.

Image: I don't see that as a problem at all, and I doubt this you can back up this line: "Hence java programs usually exhibit very low quality compared to C++ based software." with anything other than "in my experience". It's rather FUDish.

I guess if you're used to seeing so many low quality unusable Java programs maybe you should start to mix with better programmers ;-)
0.02, Mike

Re:Java is simply unusable on the desktop

[shaper]

Even simple dropdown lists will not scale beyond several hundred items...

A drop-down list with (several) hundred items is sheer lunacy. Lists, drop-down, scrolling or whatever, are inappropriate GUI elements for selecting from hundreds of items. Indeed if you find the user having to select from an unfiltered set of that many items, then you probably need to reexamine the design of that portion of the application. Just going on this one clue, it appears that your more fundamental problem might be immature abilities in your designers.

Excellent Idea

[Anonymous Coward]

Hi,

I know that most of the slashdot readers are java haters and have the impression that java is unusable for GUI applications.

While it is true that most current java GUI programs are slow as hell, this does not mean that java (the language) is slow. Run something like a well written quicksort on a java 1.3 VM, and it will be as fast as a C++ implementation(1). Try it out for yourself before you flame me. The implications of this are huge: It means that bytecode languages like java or C# can be as fast or even faster as compiled languages! This will change computing forever, even if you don't like it.

Now if java is that fast, why are GUI applications written in Swing so slow? The reason is that all the 2D rendering is currently done in java using the CPU using an api called java2d. The main bottleneck is not that it is done in java, but that for the sake of platform independence and garbage collection, java 2d has no efficient way to access fixed position memory like the graphics card memory, and that all calculations like blitting are done by the CPU. This will supposedly change in the java 1.4 (merlin) release, but like every intelligent software developer, I believe it when I see it with my own eyes on my own machine :-) (2)

But sometimes you do not need platform independence. If you write a java application using KDE, it will run on all unix machines where you can compile KDE. And contrary to popular slashdot belief, java is a very good language even if you do not need "write once, run anywhere" style platform independence.

So to all you java haters: Stop wasting your time by flaming about java performance and instead run a simple non-gui java benchmark.

greetings,
Anonymous java nerd

(1) Depending on your choice of compilers/jvm you might not get identical performance. But you will get within a factor of 2.

(2) It would be nice if all the C# followers would have the same attitude instead of blindly believing microsoft promises.

Re:Java is simply unusable on the desktop

[Mike Connell]

CC is an OK book (IMO). However, I suspect the actual reason why you aren't reiterating any of his points is that they don't contradict what I've said. A deubgger is a last resort. Everytime I end up having to use it, I always ask myself - why? Why didn't this get caught earlier?...

This wasn't even fresh when I was taught it all those years ago at school ;-)

Anyway, here's a quote from a book perhaps you might like to read: The Practice of Prgramming, Kernighan & Pike: "Debugging is hard and can take long and unpredictable amounts of time, so the goal is to avoid having to do much of it.[...] An ounce of prevention really is worth a pound of cure."

I couldn't agree more :-)

Mike.

Re:Java is simply unusable on the desktop

[f5426]

> A drop-down list with (several) hundred items is sheer lunacy

This is not an excuse not to handle it properly. (I don't know why, but this recall me the mswindows combox boxes where you have about 3 of 4 lines of avalaible data, probably because someone decided that using a combo with a few dozen of lines would be 'sheer lunacy')

> Indeed if you find the user having to select from an unfiltered set of that many items, then you probably need to reexamine the design of that portion of the application.

Nonsense. You have a number in the interface. You click on it, and want to drill through. Unfortunately, there are 6000 facts hidden behind it. The user *want* to see them, probably because he want to sort them and find a particular one. Sure, he could do a quety for that, but scanning in a list is sometimes easier/more confortable. I can use list of 100K items if the list is sorted meaningfully. There are user hitting the 65K lines limit in excel spreadsheet every day ?

Hell, with you reasoning, we should suppress any kind of visualisation of log files, as those are basically list of thousands of items.

> Just going on this one clue, it appears that your more fundamental problem might be immature abilities in your designers.

Nope. Its problem is that he is using a toolkit that doesn't scale to the user needs. Sure, and application that _requires_ the user to dig into list with hundred of elements is severly ill-desgined, but one that _prevent_ a power user to look at its data is plain broken.

If a developer want to make anything resonable (like a scroll list with 1000 items sorted by date), he should not be prevented because the toolkit implementors are using o(N^2) algorithms.

Cheers,

--fred

Re:What's the point?

[technomancerX]

Nope, but I'll give a brief explanation. Java basically has 2 GUI toolkits, AWT and Swing. The main difference is that every component in AWT corresponds to a native system component while in Swing the only system dependent components are very low-level, like a window. So in AWT if you create a checkbox, it will ALWAYS look like whatever a checkbox looks like on the platform it's being run on because it actually calls a native component. Under Swing, checkboxes and such are rendered and controlled by Java through Look And Feel classes. Metal is an example of a Swing Look And Feel (there are a bunch of them out there). So a Swing app will look like whatever Look And Feel you tell it to use (although some Look And Feels like Windows and Mac will only run on those platforms because Sun doesn't want to risk a legal battle).

The KDE bindings don't use AWT or Swing. They actually let you program using a Java variant of the actual QT/KDE APIs. Another big difference is that code written using these bindings can only be run on platforms that have the QT/KDE libraries and a JVM, while AWT and Swing programs can be run wherever there is a JVM.

Hope that makes sense.

.technomancer

Re:Java is simply unusable on the desktop

[Mike Connell]

I was so intrigued by your "Even simple dropdown lists will not scale beyond several hundred items before becoming unusable speedwise." comment, that I just created a drop down list (JComboBox) with 5000 (five *thousand*) entries - there were absolutely no problems at all. This was with stock 1.3.0 on NT4 on a P2-350 with 192M.

Then I created one with 50000 (fifty thousand!) entries - this took a while to create the 50000 objects to put in the list, but as far as using it is concerned - it was just as fast.

Whatever problems you're having with this stuff, well, I'm not sure it's all down to Java...

Mike.