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
Perhaps they should fix the bugs that they have already have in KDE2.1 before attempting this.
The most annoying one being that konqueror tries to access a requested document on the previous site. It also occasionally will treat every request as a request for some page you've been just been to, as though every link was a back button.
And all this is in what they are calling "Final", not beta. Come on guys, you're gonna give linux a bad name! (no snickering out there)
--posting anonymously in anticipation of poor moderation
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
... check qpt's user info.
cheers,
--
Xenu loves you!
I think this is a good idea to add binding to KDE for the Java plateform.
Sure it could break the WORA promise of Java. This is the bad thing.
But used wisely, it could enable 100% Java application to integrate well with theire desktop environment. A well written application could easily abstract all the desktop integration feature they need and have implementation of these for each desktop environment they run on. If no desktop integration implementation is found then the Java application can still run, it will just not be interopperate nicely with the desktop.
Garbage collection, often touted as Java's biggest advancement over C++ makes Java completely unsuitable for a whole slew of applications. Even the "softest" realtime apps will get an unbearable penalty from the garbage collector spontaneously "kicking in" at more or less random intervals. Even a simple MPEG1 player app eperiences jitter and playback glitches due to garbage collection issues. The only place where java's performance is acceptable is server side apps because the memory footprint is less of an issue and because "the web is always slow" attitude that web users became used to.
Java does not have serious development tools. I've yet to find a reasonable Java debugger. The supposedly "excellent" Borland JBuilder cannot hold a candle to Visual C++ especially when it comes to debugging features.
Last but not least problem with Java is its image. Because of its simpler syntax it quickly became attractive to all kinds of rookies and cowboy programmers and underachievers trying to make big money "hacking" Java after having only marginal exposure to any other programming languages. Hence java programs usually exhibit very low quality compared to C++ based software. This gives the language a bad name to such an extent that many software shops won't even hear about writing anything in Java purely on the grounds of prejudice. Java is was a neat idea executed very badly.
Good day.
--
Ally ourb asear ebel ongt ous
Your pizza just the way you ought to have it.
My first guess was that they were not built in, so that _YOU_ _DON'T_ _HAVE_ to have them installed.
---- [I... See...]
> 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
Far too obvious. Java trolls are passe, please try again. (KDE vs GNOME isn't much better)
--
Non-meta-modded "Overrated" mods are killing Slashdot
Non-meta-modded "Overrated" mods are killing Slashdot
(Hey Ryan! Here's your proof!)
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.
I'm not a big fan of Java, but these applets rocks. Maybe these guys would be able to write a decent Mpeg1 player in Java.
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.
Umm.. have you used any of the recent versions of the JDK & runtime? They are quite fast and greatly improved over the previous releases.
I have JDK 1.2.2 running on a Pentium III 450 mhz, 256 meg of RAM, and Windoze 2000. I would not call that a "wonderbox", but it's not a slow-poke either. Java applications run great on this system- and I mean applications not applets
I'm working on a rather complicated desktop mapping application, written completely in Java and using Swing. It's quite responsive and for most user operations, you would not be able to tell it was an interpreted application or one that was compiled to native code.
I'm quite happy with Java as a programming language and with it's perforance in both desktop and server-side applications.
When the users tested the app they were pleased with the performance as well. On older hardware, performance suffers, but even on a Pentium 166 with NT4 & 128 meg of ram, the application was useable.
--
--
Unscrample my email, win a prize.
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...
- 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!
--
--
Unscrample my email, win a prize.
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.
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.
try starting with java -Xms1m the Java VM defaults to an initial size of about 20Megs, for efficiency. If your app is much smaller than that, it's better to start with an initial size of 1 meg (-Xms1m) and let it grow if necessary.
....today also saw a major release of Java-GNOME, a set of Java bindings for GNOME and GTK. Presently at version 0.6, this project has been going on for quite a while now, and an enormous amount of work has been put into this release. (It's been almost four months since the last major release). Check out screenshots, and lots of doumentation.
--
--
Unscrample my email, win a prize.
On your NT box: bring up the Task Manager, switch to the "performance" tab and the hold down the left mouse button anywhere on the desktop. 100% CPU usage baby!
take a triptonica to subthunk
Shut the fuck up you idiot.
No changes to binary code at all.
The message on the other side of this sig is false.
Ha Ha !
Some native compilers for Linux should be here.
This is good news, except that I would like to see QT (and GTK) peer implementations for the Java AWT. Currently, the blackdown Java implementation uses Motif, so apps built with it tend to be ugly. I know one can use JFC (swing) and use a prettier look and feel, but I'd much rather have a native widget that looks, responds, and acts like whatever desktop environment I have installed.
Just my 2 pennies.std::disclaimer<std::legalese> sig=new std::disclaimer; sig->dump(); delete sig;
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.
Slashdot...
I just accessed one of my swing applets and did a query on a database table for a bit over 1000 rows; it took from 2-3 seconds from the time I pressed the query button to having the JTable entirely populated. I then grabbed the scroll bar and ran it all the way through the entire JTable and it took less than a second, actually; as fast as I could move the mouse. And Java scrolls actually scroll through each row, not freeze the display until you finish scrolling and then show the result (ms excell). I see nothing wrong with this gui response nor the database query response time. Using Java 1.3 runtime plugin, all Swing components. Database is DB/2 on the mainframe accessed via IBM's JDB net driver through a UDB client on a linux apache/jserv server. Your response seems like you dont have any experience programming in java and Swing. The 1.3 runtime responds as fast as native applications. Try it.
(just wanted to get that out of my system, sorry)
Regarding the whole portability thing: yes, using these sorts of native libraries does introduce some platform dependencies to the programs which use it. There are actually a number of widely-used packages which are basically Java interfaces to libraries which, deep down inside, are partially or entirely composed of native code.
For example, Java3D is implemented on top of both Direct3D and OpenGL, and is portable between the supported platforms. If you want to write 3D apps in Java, it is just not practical to go with a non-native solution. Likewise, if someone wanted to write KDE apps in Java, it makes a lot more sense to use the actual Qt and KDE libraries than it does to try and emulate them in Swing (which, as many have pointed out, is pretty big and slow to begin with). Java is still plenty useful even if you're targeting a specific platform. Also, if we ever see KDE on non-UNIX platforms, any Java apps written using these bindings will be portable to them too.
Is there a double-standard here with regard to Microsoft and Visual J++? Yes and no. Yes, because Microsoft added Windows-specific extensions to Java. And no, because what Microsoft was really trying to do was make the Java programs people wrote with their tools specific to Microsoft's JVM. They changed the language itself in some pretty radical ways, they didn't just add a few native libraries and hoped that everyone would use them. And they were quite blatant and pushy about trying to get everyone to use their extensions. Finally, since most people who are doing Java development are doing it on Windows, what MS did could have been far, far more destructive to Java as a whole than some guy adding KDE bindings for Java under UNIX.
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.
-----
It's not just coffee anymore!
Through the perception of illusion, we experience reality.
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
I see that eople are confused what the term java means. This is probably Sun's mistake as Jamie Zawinski explains here:
http://www.jwz.org/doc/java.html
Taken from this url (which is written in 97 I think):
The fact is that there are four completely different things that go by the name "Java":
- A language;
- An enormous class library;
- A virtual machine;
- A security model.
-- Java-the-language is, overall, a very good thing, and works well.
-- Java-the-class-library is mostly passable.
-- Java-the-virtual-machine is an interesting research project, a nice proof of concept, and is basically usable for a certain class of problems (those problems where speed isn't all that important: basically, those tasks where you could get away with using Perl instead of C.)
-- Java-the-security-model is another interesting research project, but it only barely works right now. In a few years, maybe they'll have it figured out or replaced.
After reading this page, I am convinced that it is a good thing for Java and for Linux to have native toolkit.
So in other words, rather like the proprietary extensions that Microsoft got slapped down for, and that Slashdot got all upset about.
Either the pot is calling the kettle black, or am I missing something?
"Life is like a sewer - what you get out of it depends on what you put into it" - Tom Lehrer
This basically just allows people that want to to write KDE apps in Java. There are no legal issues here.
.technomancer
.technomancer
--
--
Unscrample my email, win a prize.
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.
I use Forte for Java v2, Internet Edition, every day for hours on end to earn my living. It's a 100% Swing based app that runs on a 1.3 JVM. It isn't as fast as a native app, but it's the most responsive and useable Java GUI app I've ever seen.
This, by way, is Win2k on a 800MHz Athlon w/512M RAM. The most memory I've seen Forte use is ~150M RAM, and I had the servlet/jsp engine running in debug mode with 25 or so source files open.
Oh, and Forte has a pretty nice debugger, certainly worth checking out (especially for JSP debugging). You can set breakpoints, step through code, set watches, look at the threads, look at the callstack, and look and change variables currently in scope. It's stable and extremely useful, certainly the best Java debugger I've used.
And Forte is based on the open-source NetBeans project, so you can even check out the source if you're so inclined.
-- topher71
.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?RE 1) Like the anonymous poster below anyone who uses those features in a big project needs to be shot.
.
RE 2) Umm excuse me but *you* obviously have no idea of what you are talking about. I do work in an enterprise company, (a telco with >100,000 employees, I think that's pretty enterprise) and we *do* use java. Also, java is very much in demand in the market place. Just ask any corprate recruiter. (One of my best friends is one and tells my this regularly). Success is a factor of marketing? Well I guess it depends on who determines the success, oneline forums? magazines? press releases? How about cold hard cash? Our customers determine whether we are successful and they aren't complaining.
RE 3) Your point? other than to be a nuisance? Don't give me that condescending 'I feel superior b/c I use a commandline' crap. BOTH commandline and gui have their place.
Obviously you are a bigot. Just save it for somewhere else.
This is why I rarely read slashdot anymore. The quality and rationale of the general readership has plummeted from 3-4 years ago,
********************************************
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.
1) Ah, yes. Shoot all those who use proper tail recursion. There go all the good compiler writers.
;)
2) When you said "enterprise", I assumed you meant using Java for enterprise-level tasks. I guess you could mock up an interface with it, and use it as a front-end, if that's what you want. But I wouldn't trust it with anything serious.
3) My point? That I didn't need your opinion. And you obviously don't need mine.
Obviously, we're both bigots, so be careful where you point that finger, sonny. But isn't that what slashdot is for these days?
I agree that slashdot isn't as good as it was 3-4 years ago; I was there too, before User Accounts, even. But I think that owes more to the sheer scale of things than it does to the quality.
Even the Slashdot story submissions have gotten somewhat better, though not by much. However, whatever was left of a community on slashdot has been lost.
Will the real Bruce Perens Please Stand Up
Why not a PLAF that interfaces to the running KDE and adopts it's look?
I'm not talking about writing tail-recursive code in Java; I'm talking about *implementing* tail-recursion decently on top of Java.
:)
And I did indeed refer to it in my post, which is what he replied to... so... wrong again!
Will the real Bruce Perens Please Stand Up
I agree that most existing Java2D implementations are sub-optimal, and this contributes to Swing's inefficiency. I'm amazed at how Smalltalk-ish Swing's approach to creating a GUI is. (Then again, many Java developers are Smalltalk expatriates who saw a way to take what they were already doing and move it to a more popular language/platform. It's no accident that Java's object model owes more to Smalltalk and Objective C than to C++.)
You really can't blame all of Swing's problems on Java2D, however. There are many who'd claim that its architecture lends itself to certain inherent inefficiencies. Not being a Swing expert myself, I can't rightly comment on those in depth. But I believe that much of its architecture was done more with theoretical concerns than practical matters in mind.
One thing I do know is that some Java2D implementations rock, and as a result, Swing performs very acceptably on those systems. One such implementation is Apple's, under MacOS X. Under MacOS X, Java2D is peered onto the Quartz drawing engine, giving you great speed at drawing vector graphics in addition to freebies such as anti-aliasing. (This also means the G4's AltiVec unit is leveraged whenever possible to improve rendering speeds even more.) I've run Swing apps on an iBook running MacOS X beta, and can report that they ran fabulously even though the iBook was under-spec (96 MB of RAM instead of 128, slower G3 processor with no AltiVec to take advantage of, beta OS with debug assertions still in place, etc.).
The only disadvantage of Java2D on MacOS X is that, because of the anti-aliasing, some types of vector-based animation that work on most other Java2D implementations leave "trails" or "turds" on your drawing canvas in the Apple implementation. It's that darned anti-aliasing working against you, in that case, because over-drawing a spline (for example) with the same spline in the background color will not fully erase all the pixels that were originally drawn. The pixels bordering the spline will remain a blend of the spline's foreground color and the canvas background color.
As I recall, memory use balloons rather quickly no matter what you do. Worse, it never really comes down again. There was also some discussion at the time (Swing has "built in" memory leaks); don't know if that is still pertinent.
This is really nothing new to anyone who has done Java on Mac OS X and it's also very simeilar to the Java-GNOME project too. Mac OS X has Java bindings in Cocoa in addition to allowing you to do Mac specific things. For example, if you use the MRJ classes, you can do things like set the type and creator codes for files (Mac's son't rely on file extensions for file types). That's something that Java doesn't do by default and it's something you don't need to do on other platforms. Apple has had to add those classes to do Mac specific things so that Java apps feel comfy on the Mac. Similarly, with these KDE bindings, it allows developers to add some KDE features that make it feel more like a KDE application.
In my experience with Java, I have found that things like the JFileChooser aren't quite the same as the native file chooser dialogs. With the MRJ classes on Mac, I can use a Real Mac OS X file chooser as well as use sheets. With the KDE bindings and Java-GNOME, I can do the same things on any OpenSource Platform. It looks like MS is left out on this one.