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.
Slashdot Mirror
...it was win32 bindings for Java instead? Doesn't either one defeat the purpose of writing a "write once, run anywhere" Java application?
-Karl
Java is awful for gui applications. That's why things like "Corel Office for Java" were given the mercy killing they so desperately needed.
What the Linux desktop really needs is something like Visual Basic.
Wait - hear me out.
I'm not saying that you should code in Visual Basic. I don't do it myself - that's one of the perks of being a systems programmer. All I'm saying is that there should be a language for the non-programmer to quickly design graphical applications that use pre-fabbed components and a minimum of glue code.
Java is object oriented. This makes it a mistake for a general purpose gui language. What you need is something that is object based like Visual Basic.
Any idiot should be able to create usable graphical apps for Linux. Unfortunately, currently even gifted C++ hackers can't make usable gui's for Linux - witness freeciv. Whether you like the language or not, you've got to admit that a language designed primarily for component reuse would be a good thing for linux - espescially for the corporate environment where rapid development is a must.
--Shoeboy
> Java is awful for gui applications...
That's rather the point. Modulo GUI, java is rather fast nowadays [0]. Swing OTOH, is a bit of a bloaty pig, layering far too much code on top of the underlying (native) GUI.
ObFacts: the nightmare corel project was a long time ago in terms of java speed & functionality.
Mike.
[0] Relative to FORTRAN & C, not just relative to "old java"
Tales from behind the Lagom Curtain
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).
The same idea is already underway for GNOME
Mike.
Tales from behind the Lagom Curtain
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!
v em ber/msg00481.html
x _h tml
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-No
http://news.gnome.org/gnome-news/961253384/inde
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.
> the memory-consumtion of KDE + X + everything else is still below 40 MB.
This is funny as hell. This is what is called a resource hog. And YES, gnome is a resource hog too. And Mac OS X also. And win32 too.
A NeXT machine was running fine (in 2.x) with only 8Mb of ram. A color station under 3.3 would run fine with 32Mb of ram. This means the OS + the workspace + edit + a few apps (real apps, like Mathematica or Improv)
And before that, Geoworks ran real fast in extremely low memory conditions.
Still below 40MB before having started any usefull application ? Nothing to be proud of...Of course adding java binding will make 40MB of bloat looking ridiculous...
Cheers,
--fred
1 reply beneath your current threshold.
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.
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")
This became obvious for me when I used the Java version of ICQ which was not truly integrated with my desktop. I would have liked to switch to "away" state whenever the screensaver would kick in, just like in Windows. The java program cannot be aware of all the desktop properties and event. Maybe there should exist an API for this precise purpose.
All humans are mortal. Socrates is a human. Socrates is dead.
No-one seemed to care about this when Apple added these bindings in OS-X. It lets you write non-cross platform apps in more languages. That's OK. Or you can detect if the bindings are available and use them as well as providing work arounds if they aren't giving you cross platform apps which integrate better on some platforms. Not really a problem.
Let me say up front, I couldn't care less about write once, run anywhere, I just want to write cool apps in a language I am comfortable with. The whole idea that Java MUST be used in 'write once, run anywhere' mode has been really holding it (and me) back. I feel that developments like this really open up new possiblities for me to develop applications which interest me. C and C++ are good languages but not everyone is a C/C++ programmer (or wants to be), so it is time for OS and GUI designers to stop acting as if they were.
Now, if only Be Inc. would make it easy to program directly to BeOS using Java...
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
Tales from behind the Lagom Curtain
- Quickly design graphical applications
- use pre-fabbed components
- a language that every idiot can use
- a RAD (rapid application development) tool
You need: kylixI went to a free seminar a few weeks ago, and it looked really impressive.
--
--
If code was hard to write, it should be hard to read
Performance is adequate, but memory management -- oh my god. Check out Tube, a portable Hotline client I wrote last year. Uses anywhere upwards from 19MB of memory. The "official" client needs less than 1MB!
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.
While teaching myself java, my original web page had a 3d vector-ball animator for a pretty nice scroller implemented in java on it.
This app had explosion effects, vector trails, morphing, and of course all the 3d linear algebra crap for moving and rotating the objects on each axis.
Oh yeah, it used double-buffering for smooth animation too, so I was pushing 320x300 pixels in each and every frame. This was on a Tseng ET6000 video card. Nothing radical there.
On my Pentium 133, in a browser window, this used maybe 25% of my CPU tops.
Of course, this was under OS/2, which had a very good java integration with the OS and netscape (netscape for OS/2 used OS/2's system JRE by default, not its own).
Bottom line is a poorly written app, whether it be in java or any other language will be a CPU pig. Just because it's java doesn't make it so, however.
> You rarely need a debugger? Well in that case I wouldn't offer you a job as a programmer
:-)
Thats good - because I wouldn't take it - especially if you only hire coders who code so badly that they need to use a debugger a lot
> It should be mandated by LAW that every programmer steps through their own code at least once. If you don't do that you have no clue what your program really does. You're doing programming by coincidence.
On the contrary. If you're just coding - and saying "ooh, it seems to be doing the right thing", you dont know jack. What you *should* be doing is a design, and then coding from it with test cases. If you need safety, you should generate a proof for the design and then derive the code automatically.
Needing to use a debugger frequently is a sign that something serious is wrong with your habits.
Mike.
Tales from behind the Lagom Curtain
Hi,
:-) (2)
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
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.
A debugger is good for figuring out what your program is doing when it is not doing what you needed it to do. You can't figure out that your code is correct meerly by stepping through it line by line. It is far better, IMHO, to write code that is simple enough to be obviously correct to the extent possible, self testing where reasonable, and with clear intent everywhere else.
If you think that the only way to determine what a program is doing, then you have only the weakest grasp of whatever language you are working with. Ofcourse, there is an exception to that general statement -- I find that exposure to Win32 makes people paranoid about whether code works like they think it should.
However, the types of large-scale programs I write (traffic planning systems, mostly) demand that the code be self testing to a large extent because the data structures are large and complex enough that we have been unable to find effective output/display mechanisms, but we *can* write algorithmic tests that we can trust because they are simple to state, even for complex data.
I say -- debug to dig out info about a misbehaving program, but that is no substitue for clearly written code, and a well thought out design. Do that, and you too will need your debugger less.
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.
Tales from behind the Lagom Curtain
I think it's too easy to end up chasing your own tail trying to identify who's "really" who, since new accounts are easy to create. Just call the trolls as you see them; it makes it harder for them to get a +1 bonus, and so reduces the entertainment value of pissing in the intellectual swimming pool.
--
Xenu loves you!
OK, I'm from old school. I've been at it for 15 years or so, most of that time doing seriously complex programs of the engineering automation sort. McConnell is a nutcase. I have his book on my shelf, and it sucks. He recommends coding styles that only make sense in Redmond.
Remember -- code should follow design. Good code follows a Good Design. Good design handles boundary cases in a normal fashon. Good design is semantically clear. Debugging is a last resort when your code is not working right. Good code behaves in obviously correct ways. Good Designs are self-testing to a large degree.
To sum -- it is *you* who need to learn to design and program, my friend.
Some native compilers for Linux should be here.
Isn't this just allowing the language to use KDE themes and widgets where available, just like it uses Motif and Win32 as well as it's own Metal theme.
I am working with Swing in a database app for a manufacturing company. In an instance where we have many items to select from we use the load on demand approach. For this particular case, we made our on Java Bean that consists of a JTextField and a very small button with the caption of "?" in red just to the right of it. So, if a user doesn't know the part number off the top of their head, they click the "?" next to the TextField. Then and only then does the application poll the database for the whole list which is then displayed in a new modal frame. This design results in the initial frame loading quicker up front because it's not waiting to for a combobox to load up all it's values first. It also makes for a more efficient use of memory.
Borland JBuilder does this as well. The first time you go to help it takes a little longer because they wait until it's needed to create the object. The designer is coded the same way. Again, the result is more efficient use of memory and the distribution of work so that everything doesn't have to be loaded at the same time when the application first launches.
-----
> 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
1 reply beneath your current threshold.
So somebody coded a bad applet that eats up all resources by not yielding or sleeping. What's your point? And.. that's on ONE virtual machine (Microsoft's since it's inside IE) so it could also be the case of a poorly implemented VM, though in this case, I would suspect it's the applet.
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
.technomancer
In addition to this, as soon as you start to write non-trivial code in Java you begin using threads, so single stepping becomes a pointless activity. The timing difference means the threads interact differently to the way they would in a real invocation. It's still a useful technique every so often of course, but not for anything bigger than a few classes.
Have you actually written any decent sized Java apps? I would guess you haven't from this comment.
This basically just allows people that want to to write KDE apps in Java. There are no legal issues here.
.technomancer
.technomancer
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.
Tales from behind the Lagom Curtain
Except that the source will be fully available and no-one will be conned into believing that it's pure Java.
Yes, in which case I agree. This is a bit pointless. What's wrong with a Look and Feel that blends seamlessly with the KDE 2 theme.
This is not an excuse not to handle it properly
I completely agree. It was the context and wording of the original post which caused me to suspect that there might be other poor design choices that were the culprit in the poster's perception of poor Java performance.
Hell, with you reasoning, we should suppress any kind of visualisation of log files, as those are basically list of thousands of items.
Begging your pardon, but I did not say or suggest that we suppress any kind of vusualisation of log files. I did not mention log files at all. Please don't distort what I said. Since you brought it up, I will, however, suggest that visualizing a log file in a drop-down list is perhaps a less than optimal design choice.
Again, I did not suggest that one prevent users from looking at data. Actually, I was thinking of drop-down lists as an optimized form of data entry, not visualization, so maybe we are not so much disagreeing as we are misunderstanding each other.
I can use list of 100K items if the list is sorted meaningfully.
This misses the point of the sheer awkwardness of manipulating a drop-down list that large. The list viewport is so small in relation to the total list size that movement in the list is very difficult. The scroll thumb moves tens or hundreds of items with the tiniest of mouse inputs, frustrating even the most dextrous user with overcompensated mouse movements. And often the arrows are either too slow for the size of the list or too fast to read as you scroll. Please understand that I am not suggesting that this is something one should never do. I am just pointing out the tradeoffs of the awkwardness ot manipulating the user interface.
.technomancer
.technomancer
I do agree with you that a Look and Feel that automatically pulls and uses your KDE theme would be nice, as would a set of Qt/KDE AWT peers.
.technomancer
.technomancer
Java bindings for GUI environments is an interesting idea. I once read several years ago that the average application spends about 90% of its time in windowing toolkit routines. I'm sure the real figure, at least today, is a good bit lower, but even at, say, 50%, implementing toolkit routines in native code could have a big performance boost for Java applications. Still, I don't really know if Java is the way to go for quick/easy apps. C++ really isn't hard at all to do, and Java isn't appreciably easier. Sure there less ways to break things, but you can program buggy Java just as easily as buggy C++. I think the main benifet of Java is the huge class library that comes with it. Maybe if a class library like this were created in native code, and put up as kind of a GUI complement to POSIX, the dreams of quick-to-write and portable GUI apps could be realized without resorting to interpreted languages like Java.
A deep unwavering belief is a sure sign you're missing something...
For *years* now I've been saying that Sun should just drop Swing and use QT or *any* other GUI component that is already on the market and proven.
If only we could get Sun to adopt this and replace swing with it, Java on the client side would gain SO much.
Seriously, right now there are only two major candidates for GUI building in Java: AWT and Swing. AWT is clunky and Swing produces the most incredibly bloated code you've ever seen. We need alternatives. Qt is one good alternative, but it has problems (read on). wxWindows is another alternative, not quite as extensive as Qt, but not with the same problems either.
Qt does have the most developed GUI tools I've seen short of those evil MFCs, in addition to some other cool stuff with sockets and XML. The problem is that your code is only portable to Win32 if you use Trolltech's commercial license. (I'm not slamming Trolltech's decision here...there is some delicious irony behind Trolltech contributing to an atmosphere where free software is easier to write for X than for Win32. I'm just saying that this violates Java's "write once run anywhere" philosophy.) Qt also won't work for Mac, at least not as far as I know. wxWindows has ports for Win32, GTK, Mac and Motif, and is distributed under the LGPL for all platforms. While you don't get all the goodies of Qt, you do retain all the flexibility of Java.
ObJectBridge (GPL'd Java ODMG) needs volunteers.
Finding God in a Dog
Oh my, a VB troll. Spawn of Satan? You really overrate yourself. Oh well, at least you did not call that money sucking, point and click activity "programing". If you really do use VB, I'm supprised you could keep a browser stable long enough to post.
Friends don't help friends install M$ junk.
Yeah, uh huh. Like you're *so* much more informed on the topic.
1) Java removed actual powerful functionality from C and C++, and made the whole mess less maintainable , less useful, and far less efficient. No decent way to implement proper tail recursion, no macros, and a broken class/package protection model all spring to mind immediately.
2) I can list other massively successful products that have sucked as well. Success is not a guage of worth, efficiency, or really anything else besides marketing. Java sucks just as hard as Word 6.0 did when it came out. And using "Java" in the same breath as "enterprise software" is a pretty good indication that you have no idea what you're talking about, or are also trolling.
3) We really don't care about your opinions in the Gnome/KDE flamewar. Personally, I hate them both, but I'm not going to let you draw us all into a pointless "GUI War" argument. Just remember that KDE is generally modeled after Windows, so if you like their way of doing things, then maybe you'll find KDE intuitive. I find a command prompt to be more intuitive.
Will the real Bruce Perens Please Stand Up
When all you have is a hammer, everything may look like a nail, but it isn't reasonable to expect that you can play a CD, cook a grilled cheese sandwich or mow the law by smashing it with a hammer just because it's the tool you thought to use.
- 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.
According to this "logic," if I want to use email as a transport for real-time streaming media, it's the fault of implementors of sendmail who are responsible for it not working?I live In the VisualAge debugger. The ability to edit the source, hit save, have the changes linked into the running application, and immediately step over the code I just wrote to make sure it does what I want it to is pretty damn good. If you're unsure of exactly what to do with a method (say you're working with some unfamiliar API or toolkit), you can just leave it empty, set a breakpoint, and then be able to inspect all the objects available to you while you write the method in the debugger's source pane.
Just set the halt contains some very, very good advice for working in this kind of environment. (Okay, it's about SmallTalk, but VAJava is really VASmalltalk with another language kludged onto it)
Charles Miller
--
The more I learn about the Internet, the more amazed I am that it works at all.