
Java Swing comes with "pluggable look-and-feel technology", which essentially boils down to the fact that interfaces can be "skinned" (although this is simplifying a tad) and is therefore, extremely flexible. By default, Java ships with a cross-platform look-and-feel (LAF), which means your apps can look consistent across all platforms, or LAFs that mimic the look of a specific platform, say Windows, for example. However, one of the chief complaints of Java desktop applications is its "look". It basically stems from two issues:
>Well people, java is not slow.
Yes... it is!
Before you can run a Java app, you have to fire up the virtual machine. Then it's got to compile the thing as it goes. That means Java is, and will remain, slower than properly compiled languages.
And it's further crippled by it's constant bounds checking etc - which can be a lifesaver sometimes, true, but often is painful. Read John Carmack's comments on programming Java if you don't believe me.
wow. first of all, it will only "compile as it goes" the first time. secondly, the virtual machine adds a second or so to the boot time, which while it is something, isnt much. java isnt the greatest platform for game development, the john carmack article your referring to was about five pages of the obvious. there are a few disadvantages to the way java does things, but the advantages VASTLY outweigh the disadvantages for the majority of application types (games not being one of them)
In a lot of core OO tasks, java is even faster that C++!
Care to name any of these mysterious core tasks, or provide links?
dude, its not too hard to find definitive proof that anything is faster then anything else. most language benchmarks do nothing but proove the efficiency of data structure x in language n. but the VM languages have surpassed compiled languages in terms of speed at this point. wont be the case for long, the next generation of compilers will pull native code ahead again. that doesnt change the fact that for the vast majority of applications, VM languages are so close to native its not worth mentioning.
In the end, it's not about subjective speed, but about efficiency.
Um yes? One thing Java is not is efficient.
C is efficient. You have to worry about array bounds and pointers and that sort of thing, but it is efficient because it doesn't do things it doesn't have to.
Whereas Java tries to do things for you, so it'll check if you're out of bounds of an array even if you know damn well you're never going to be.
And then there's the VM thing - Java is compiling as it goes, which imposes more overhead than if it's all done ahead of time.
So no, it is NOT efficient.
the only possible way you could say C is more efficient is if you manage to find someone that writes perfect C code. but since we arnt taking development times into account, you could say that C is a bloated piece of crap, and ASM is way more efficient.
java doesnt compile as it goes, that is what the java compiler is for (javac). if you want to, you can even compile to native code with gcj (redhat does this with the java bits of oo.o). stuff like bounds checking or garbage collection is definately overhead, but it also makes developing remarkably painless (when compared to C). you can get a hell of alot more done, in exponentially less time, with fewer bugs in java.