OSNews

especially j2ee apps. the problem is, no one ever uses the right language for the job anymore. they just always use java. and i'm *so* sick of hearing people say java is just as fast as c++. its not true, i don't care what benchmark you show me, it just not true.

there are two really easy test to prove this.

1. write a program to parse a large xml file in java, and then one in c using libxml. the one in c (or c++ for that matter) will crush the java one (i know, i've done it). this is even bigger issue because java people (i am one, sigh) use xml for *everything*. the same way they use java for *everything*.

2. Create a simple object that just has one member, a string. do this in c++ and in java. now write two mains, that just create 1000 of these objects. Time it.

Sorting ints, or accessing a hash may be just as fast, but the applications people write are not.

Right now bea workship is taking 100M of ram (and it has the least features of any java ide that i've used). If i start the weblogic server, i'm up to about 300megs...

Speaking only for my personal experience most of the Java Apps I have used sucked. You can rant till you are blue in the face but untill I see good fast quality java applications I am going to still have the same opinion.

How do you think so many people independently formed the same opinion of Java in the first place?

Also, didn't Sun buy an Apple app like Watson with the intent of re-writing in Java and releasing as freeware to show the world just ho easy and fast Java can be?

What ever happened to that project? This was not easy or fast even for Sun Microsystems?

run on many platforms straight away without modification ?

> run on many platforms straight away without modification ?

this is true. and this is a case where java is the right language for the right job. my beef is with all the j2ee development going on where the people coding control the hardware they deploy to.

Being able to write once, run anywhere is great, but it has a cost...speed and memory usage.

In 1) are you using DOM(Object Model) or SAX(Event Model) for parsing XML?

If it's DOM then both (1) and (2) are stressing the same issue with Java which is Object creation. Object creation performance has always been one of the things holding Java back, Sun have made large leaps in improving it but there is still a way to go before it could get to C++ speed and it will never quite reach it as Java has extra overhead to keep track of object for later garbage collection. I think this is an area Sun should look at in future JVMs

If it's SAX I am suppressed, if you are purely looking at parsing performance and not the complete time from application start-up then I think the performance will be very similar with C++ and Java.

Another aspect which tends to make Java apps ugly is widget layout. Java along with a few other GUI kits use the concept of layout managers (note that Windows developers don't use layout managers), unfortunately if one isn't very careful with these (for example, the programmer is lazy) then it is all too easy to create ugly layouts. How often has we seen a row of edit boxes right up against a window margin and positioned one beneath the other with out any spacing? Couple that with poor look and feel, ugly fonts and with a little bit of performance drag (yes even today on GUI apps) and bingo, Java gets a bad name.

> Java is dead. Long live .Net!

I hate MS just as much as the average osnews reader. I don't use windows at home, only at work.

But, I have had to write some .NET code (in C#). Here's the thing, and it pains me so much to say this...C# is a more powerful language than Java. Now, I'm talking C# vs. Java, not .Net vs. the Java Foundation classes. I think the .NET framework is a hack compared to the java class libraries which actually seem thought out, as .NET is just another wrapper around win32. I think they rushed .NET and it shows in the API.

Yes, libxml is dom, and the java was dom too. I haven't tried it using a sax parser, but since we're talking about object oriented code here, and we both agree object creation is slow...

Good point though.

"SAN FRANCISCO--As part of its push to boost Java on personal computers, Sun Microsystems has licensed software called Watson that's used to find and present information from the Internet."

Article from 6/30/04 can be found here:
http://news.com.com/Sun+licenses+search+software+for+desktop+push/2...

In general, the user experience exhibited by most of the Java applications I have used, both on the desktop and via Web browsers, can be characterized as frustrating, irritating, sluggish and just annoying. I do not understand how anybody can claim with a straight fast that Java applications, at least the desktop/GUI ones, are fast. In my narrow experience, they aren't and have never been. Heck, to add insult to injury, I run several GUI applications written with Python that run faster than any GUI Java app I have ever used.

Also, I don't care if Java developers suck. I don't care if nobody knows how to code Java GUIs. All I know is that it will take pounds valuable gems for me to consider contemplating installing a Java application, talk little of actually using one.

The only exception is if the user experience is compelling enough, or if the functionality the said Java app provides is unparalleled. SUN has a lot of work to do. Why won't Java advocates admit this so that SUN can at least fix this issue?

1. Java is a compiler and people don't understand that . It takes time to compile code.
2. Java memory usage can kill older PC's. I had a 32 meg pc and the virtual memory/pages usage was 'terrible' .
3. Java startup time used to be slow. Now it's ok.

Java even has an OS out now.
http://jnode.sourceforge.net/portal/


Java maybe should copy Euphoria language. A fast interpereter with a C compiler. Pretty cool even if they copy C a little too much.

I use these Java applications everyday. The first two I find very responsive and are my favourite in their class on Windows. The last one has some responsiveness problems, but I still find it very useful.

FreeMind
jajuk
Ganttproject


Another Java application that I use occasionaly that I find very responsive ans useful is jalbum.


Based on my experience with these applications, I find there to be no significant speed problems with Java, for me.

Sometimes I feel that people misunderstand Java. Personally I like C++ better, but Java has a big advance definitelly. Beyond the language it provides a proper infrastructure (network, thread management, GUI etc.).

Just let's assume that you're a developer and you would like to create a general application with UI, networking etc. in C or C++. Probably it should be portable also. At this point you start to find proper libraries for these things. In C and C++ world this is a big headache, but not in Java world.

So don't complain. Java provides safe and portable way of the application development but it has a price of course...

I have not much idea about Java internals, and I don't code in Java.
Speaking as a user only, there are nice application written in Java, but their interface and loading times feel incredibly sluggish.
As a previous poster said, the author can rant all day long, because this slowness is all I have to judge.

What about those of us who want to use it, but can't because of licensing issues. I think most of us understand the benifits of Java and we would love to be able to use it, but Sun just doesn't seem to understand the problems we see with the license.

With how bipolar Sun can seem to be at some points it's no wonder we want a more open license, what if tommorow they decided, we want to do the most damage we can to every app out there that uses Java. This may not seem like a smart idea on Sun's part, but that's not the point. If they did do this, could they cause problems? Would different licensing help to resolve this? What if Sun got bought out by another company that could benifit from causing problems for Java in general?

I think a lot of us are much more concerned with these issues than the techinical aspects of Java.

http://www.idiom.com/~zilla/Computer/javaCbenchmark.html


How can that be true ?

>Another aspect which tends to make Java apps ugly is widget layout

I do not agree. It's easy to make poor looking applications in ANY language. Although the GridBagLayout in Java may be hard work for new commers to Java once you have a firm grasp of it you can make some very nice looking apps.

The alternative is to us a GUI layout tool such as the one that comes with IntelliJ.

Azureus is the only Java application I've knowingly used that
doesn't make me want to vommit. And it still seems somewhat sluggish. But it's got lots of features, looks relatively nice, etc.

Mostly I've only used Java as a web-app and usually they only work on MS/IE and generally suck or don't behave correctly with the wrong JVM or any number of other issues.

I tried out OpenNMS once... it's reliance on Tomcat and Java made it unusable on the system I tried it on. It started swapping almost immediately and never quit.

My opinion of Java will improve when the Java apps I use don't make me want to die...

> http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
> How can that be true?

Because its straight math, no real IO, threading, object creation, etc. The JIT compiler can compile that to pretty good machine code. It just sucks at doing everyhing else.

"run on many platforms straight away without modification ?"

I can run my C/C++ apps on more platforms than my Java apps. Who cares it it needs a recompilation if Java is not supported at all. Take the Sun JVM--it only runs on Windows, Solaris and Linux. You know that virtually every platform has at least a C compiler available. Java is very limited in this regard.

Commenting on the article...

Its the GC and the omnipresent JVM that are responsible for the huge memory demands of Java. C++ or Ada are OO as well and don't need that much memory. And guess what the alternative to GC is not C style free() -- its destructors (the real ones) in C++ or controlled types in Ada. Java is also slow compared to C, C++ and Ada. And where it isn't it needs much more memory to achive speed.

It's not. The only way Java outperforms C++ is if virtual methods are overused in the C++ code, as the JVM can inline virtual methods on the fly. Furthermore the tests do not take into account the overhead of the JVM itself.

Here were some benchmarks I did on Java vs. C from awhile ago:
http://fails.org/benchmark.html

>Object creation performance has always been one of the things holding Java back

Object creation is expensive, but actually Java beat c++ here... Manual memory optimization for c++ could lead to better performance, but in real life gc makes pretty well.

...is the fastest Java IDE out there and uses Swing. Netbeans on the other hand, also uses Swing and continues to be, despite large improvements, relatively slow. Clearly Swing/Java is NOT the problem here.

If built in garbage collection and a virtual machine made application front-ends slow then VB would be slow.

Here's a real test for java, write the same gui-heavy app in Java and VB compare the performance of the interfaces. Or, if a single person isn't qualified to do both get two people qualified to create the apps.

if java isn't made to be fast but to run everywhere, WHY ISN'T THERE A SUN JAVA RE 1.5 FOR Linux/PPC ? they have 1.3 for linux/ppc and there's an IBM jre 1.4.2 but this is old. even .Net runs on linux/ppc using mono.

Object creation, as noted is costly for Java. Reusing objects to avoid the initialisation cost will help dramatically. There are many articles (see Google!) One that caught my eye was this one:

http://www-106.ibm.com/developerworks/ibm/library/it-kelby_tips/

But like any language it has its niche's and it shouldn't be brought outside of them until its problems can be hidden by rediculously powerful machines and tasks with constant complexity (non-increasing at least).
Java can be great on the desktop, if you use a lot of Java programs. If one can assume you will use many java program then loading the jvm can be a part of system startup (much like how the common c libraries are going to be loaded while booting most any OS).
In a sense, you now have ALL your libraries sitting in RAM. Where with c++ you have 150 different libraries where some of them may only be used by a program, and they'll have to be loaded when that program runs the first time! This is a small task if you have a computer that was made in this millenia; but loading a JVM is still a noticeable task (about 10-20 seconds now?),

But the next thing to keep in mind is the garbage collector. They're great for quick application development and letting you have less strict memory practices. However, if your program would leak more than a few percent of the system RAM a second without the collector... Well, that collector is going to be using a LOT of cpu time. Where does this happen anyway though right? Well, we all know that Java is not the language of choice for video editors!

If you're still on a PII like me, you probably don't much care for using a Java program. But, if you've moved into this century, and bought a proper amount of RAM; then you shouldn't mind the extra 30MB of RAM used and the cpu time taken...

That said, Java keeps it's old lore from back when PC's weren't quick enough to make Java snappy...

.Net runs on PPC by virtue of Mono. Therefore, it's not Microsoft's efforts that are helping you here. Likewise, you can use a Free Java implementation, rather than Sun's, to get your Java app running.

Kaffe lead dev, Dalibor Topic, told me that Kaffe (a Free VM) has been ported to ~70 different platforms.

So, just like you use 3rd party apps to get .Net to run on unsupported platforms, the can be applied for Java.

Isn't this a matter of personal preference? What is too slow for you may not be too slow for someone else, and vice versa. So if I say it is too slow for me personally who are you to argue? If you think it runs just fine for your needs, than who am I to argue?
The fact remains that some people think it's too slow, and this is not really up for debate. You can try to make excuses if you want as to why Java is as slow as it is, and you can even try to convince people to still run Java apps even though that person thinks it is slow, but to sit and argue that "it's not slow" is kind of pointless isn't it? You can think what you want to about Java's speed, but I think it's slow - case closed, end of discussion. It runs slower than any other native app I use.
Hell, it probably runs the same speed on both of our computers, just that I am a bit less patient than you. As I said, it's just a matter of personal preference.

Swing still looks like crap...but, there is a build coming out this week of Mustang (B39) that will address the font problems (subpixel rendering).

Swing really isn't slow anymore. Both Netbeans and IDEA are pretty zippy on modern machines, but Sun had been pretty content to have Java live in server-space (which its been a success) and not concentrate on the desktop.

I've only used Java for half of its life, and I've never seen it take 10-20s for a JRE to load up. It's not like I've had really fast PCs either.

I've used Moneydance (http://www.moneydance.com) for personal finance for a while, now, and it is 100% Java. It runs fine on Solaris, even though the Moneydance folks don't list it as a supported platform. It's performance is fine, too, even with big check registers open. While Moneydance isn't as feature complete as Quicken, it beats the pants off of GNUCash (Moneydance: unpack and run; GNUCash: uncompilable and unportable and quirky).

Using apps like these remind me why Java is a good thing. Java portability is real, and even the little things Java programmers sometimes have to do for portability pale in comparison to C and C++. C and C++ portability is hell, especially when I see programs dictating a specific point release of g++ or C programs with pages of #ifdef blocks.

I completely agree with you, as performance is subjective. The point is, I've heard directly from people who haven't tried Java for years (as a user) and yet are still convinced that Java is slow. How people can make their mind up with out actually trying it out (considering how quickly technology progresses) is beyond me, and was one of the reasons why I was appealing to readers to scrub what they "think" they know and find out properly. Things have improved a lot.

Naturally, some people still want their buttons to click quicker than Java's buttons, and there may never be a time when those users will be satisfied.

I was thinking the same thing. Generally I don't mind Java apps. I also realise that Java or the JRE is just going to get better and better.

So taking all that into account and knowing that I change OS's and computers regularly I really like the idea of using all Java apps so I can change OS without having to worry about how I am going to get all the data in. Just need a good Java PIM or email app and I am set.

>> http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
>> How can that be true?
>
>Because its straight math, no real IO, threading, object >creation, etc. The JIT compiler can compile that to pretty >good machine code. It just sucks at doing everyhing else.


To make matters worse, as usual, odd-ball logic from these Java guys even come to the wrong conclussion. No real surprise. The crowd that those benchmarks apply to tend to run simulations which can run for days or even weeks. Their conclussion? A 20% performance impact is close enough. Puke. At a day, that's 24-hours versus 28.8 hours. At a week, that's 168 hours versus 201 hours; that's an extra day and half!

Anyone that wants to pretend Java is anywhere near as fast as C or C++ can do so, just stop lying to me about it.

Simple fact is, every benchmark I've seen that compares java to C++ either has really crappy C++ code and very well optimized Java code and/or finds optimial corner cases which do not reflect real world conditions and build a benchmark around it. Worse, almost every benchmark you'll find purposely avoids collection, which completely hides GC-overhead and the associated overhead associated with memory management, that all programs must pay. Once again, a dirty lie.

These are THE primary reasons why Java has not respect. The developers constantly lie, cheat, and steal in attempts to gain mindshare. Stop it. No one is buying.

Sure Java is often fast enough. Leave it at that. Java is not a good general purpose tool and that's the real problem. There are much, much, better general purpose tools available that come with far less bagage. This is the problem Java has.

For the last 2 or 3 years, I've been firmly planted in the C/C++/native code/QT/GTK camp for desktop applications. I've even been in that camp for enterprise development.

However, all along, I always saw many of Java's virtues like J2EE, automatic memory management, easy cross platform support, developer productivity, massive killer APIs, etc.

At the same time, as an IT professional / programmer (how I earm my living and support my family), I've seen how C/C++ development jobs have been becoming increasingly scarce, while Java/J2EE jobs have been becoming increasingly abundant. In fact, Java/J2EE is nearly ubiquitous for all development jobs (except for Windows specific ones, which often go with .Net). And the C/C++ job postings are quite often actually Java/J2EE jobs, where the legacy C/C++ code is being converted to Java. Just do searches on Dice.com, Monster, Hotjobs, or craigslist, and you'll see the multitude of Java job postings greatly outnumbering the C/C++ ones.

So with my desire to have continued success in my IT/programming career (and make more money ), I therefore have a natural attraction to Java. Sure, I would love to be paid hamsomely to write QT/C++ or GTK+/C code (I love both of those environments for desktop apps), but the amount of job postings for those is zero. So I've been learning/brushing up on Java the last few years.

In this process I've been discovering some things about Java, shattering some of my preconceived notions:

a) It's not slow FreeMind, as mentioned by another poster, runs great. JBuilder X Foundation runs great on my 300MHz, 228 meg memory machine.

b) It's not as terrible of a memory hog as everyone makes it out to be - above apps did not cause swapping

c) Java apps can look great - JBuilderX looks terrific

d) Java app load times are usually acceptable FreeMind loaded nearly instantly. JBuilder takes a while to load on the 300MHz, 228meg machine, but once loaded it's quite zippy

e) Many C++ apps are slow, or use lot's of memory, or have slow load times - OO.org, a C++ app takes forever to load, and uses tons of memory. Same with Mozilla/Firefox

f) Apps I write myself, using AWT, Swing, applets, or just command line, are plenty fast and don't take long to load, even on the 300MHz, 228meg memory machine.

So, while I remain a fan of C or C++ compiled code, as well as GTK and QT, my negative stereotypes about Java speed and memory usage are vanishing. I suggest that other posters here give some Java apps a try.

A good place to start is: http://www.java.com/en/

What benefit is there to writing a desktop application in Java over C++?

I have experience in writing desktop apps for both languages, I'll list the common pro-Java arguments along with what I've found:

Write once, run anywhere -
I can do this just fine with C++ and a multiplatform GUI toolkit (e.g. Qt, wxWidgets...) Sure, I have to compile for separate platforms; but I'm also not restricted to only run on platforms that Sun supports.

Java is better for rapid development than C++ -
If anything, I've found the opposite to be true. Java forces some conventions (everything's a class) that turn the most simple application into a novel. If you want rapid development, go with Python and Qt.

Java has great support libraries -
Sun has included a lot of functionality in the JVM, no doubt about that. It is nice to have it packaged and ready to go. That being said, one would be hard-pressed to not find a C++ library that corresponds to every Java library.

Something that seems to be always forgotten when comparing java or .net to c++ is the speed of the compiler. I found that the java compiler is around factor 100 (yes you read correctly) faster than gcc. This makes it possible for IDEs like eclipse to compile as you type! These are features that make me more productive as a programmer, which is far more important than pure speed of the environment.

I have done my own tests and can say that java is pretty fast. I rewrote once small python app in java and java version was 5x faster. Sometimes java is even near as fast as C/C++ or even faster.

We have a server running totally on tomcat, it had been on a commercial j2ee server before.

With both the previous j2ee server and tomcat we have to cycle all of our java apps about once a day otherwise the performance heavily degrades.

A big problem with our server is that it does lots of heavy memory allocation and deallocation sometimes in very large chunks. We're very seriously looking at reimplementing critical portions, if not all of the server in c++ in addition to some other redesigning.

The problem with java is that everything except primitives is a heap based object. A simple example:

PointF[] data=new PointF[1000000];
//Fill with some points

This array will consume 8 megabytes in languages with value types such as C++ or C#, but 24 megabytes in java. Every single point in the array has the overhead of a heap based object which is usually around 16 bytes on a 32bit architecture.

Probably even worse: in languages with value types iterating through this array will access the memory in a very ordered manner so that the CPU cache can prefetch everything. In java there are 1000000 objects on the heap, and while the memory allocator tries to allocate objects close to each other the java program will never have as good memory locality as the value type version.

There are ways to optimize this, but the java VM does not make any effort to do this. It does not even allocate locals that don't escape the local scope on the stack even though that would be relatively easy.

The decisions sun made with the java 1.5 generics implementation even increase these problems.

> A large factor is simply the JVM itself. A simple "Hello world!" class of say a kilobyte will still require the entire JVM, and the several megabytes that entails. Yet, you must think about what you get for your money, so to speak. The JVM and the Java runtime classes are feature packed.

http://www.smalltalk.org/smalltalk/history.html
Smalltalk was invented in 1972; today's Smalltalk is based on Smalltalk-80. In front of me, I have a book, called "A Taste of Smalltalk", which has screenshots of a complete implementation of Smalltalk running on an IBM PC AT, as well as one of Apple's implementations of Smalltalk running on a 512K Macintosh. These were all graphical systems (a fair amount of concepts we take for granted today were invented for the smalltalk ui).

Smalltalk is cross-platform - several implementations exist for all the common platforms, such as Squeak and Cincom VisualWorks. Squeak is less than 20 megs zipped, including both the VM and 'image' file; the full image comes with several games, a paint program, a music player and recorder, a movie player, support for 3d graphics, and a lot of other stuff. Smalltalk code is much more compact than Java code. When there's a bug in a Smalltalk program, a dialog box pops up (this can be overriden by the programmer), which allows you to debug the code, evaluate arbitrary expressions, and then continue as if nothing had ever gone wrong - starting from an arbitrary point in the backtrace. With Java, you generally get a one-line error message and your program exits unrecoverably - you can work around this to a large degree, but it's the default behaviour.

Smalltalk is a JIT compiled language (I believe the whole JIT conecept was invented for it). It has a virtual machine, and cross-platform graphics and sound libraries. It is garbage collected.

In raw performance, it's not the fastest language out there, by any means - but every Smalltalk app I've used has felt much snappier than even trivial Java apps. Modern Smalltalk implementations are certainly lighter on memory usage than modern Java ones. I currently have to use Eclipse, which is much, much clunkier than VisualWorks; try both for a while and compare them.

There are many languages which provide serious advantages over C and C++; some of the functional ones even have comparable speed. Garbage collection is great, but one does not need to use Java to have it. Aside from the advantages of having a large community and recognition, Java has few advantages over some of these languages.

>I have done my own tests and can say that java is pretty
>fast. I rewrote once small python app in java and java
>version was 5x faster. Sometimes java is even near as fast as
> C/C++ or even faster.


That generally means the C++ code was very poorly written. Comparing Python and Java is generally unfair as Python is not generally compiled. Did you try comparing your Python implementation against a Py -> C exe? How did it do with Psyco (a basic JIT for Python)?

What was the nature of your application? Was it a utility (run briefly and exit?) or did it run for hours at a time, allowing and accounting for collection? Remember, Python generally collects after each object falls out of scope.

Don't get too obsessed about benchmarks because it's nearly impossible to do a fair test between two languages. When Java comes on top in a benchmark it's because the C++ code was rubbish, and the same is often true when it's the other way around. I've seen tests where they compare gcc with varous optimisations, Intel's compiler, and then Sun's JRE. Java often came ahead of gcc but practically always beaten by Intel C++. Yet, if they had also tried the faster IBM JRE, they would have been likely to see a very similar speed. But they didn't, and so they concluded just on their observations.

I never believe the benchmarks. I never expected to see any that reported Java being faster than C++, but I did, and when you look in to it, you seen that JIT has some great advantages. The point is, with so many benchmarks, giving varying results mean that it's probably much closer than you think. If you look at graphs, you'll notice that the axes are scaled so that very small differences look massive.

One of the best recent articles about java performance

finally

** Warning// Personal preference and selfishly biased comment inside

Just to add my two cents.

While Java might be fast, I have yet to see the first java application that runs fast (I tried a lot of them so far, and not even one has become the tool I would continue to use) and does not consume all the memory after running for a while.

For now all I can see about Java applications is:
- they aren't fast (at least I haven't seen one yet)
- after running day or two memory consumptions go over the limit (scratch disk goes crazy)
- looks like sh**
- usability feel is completely another universe than underlaying system

So,... I can't help my self but to say that I don't see Java as viable solution (for me at least).

I agree. The java crowd needs to stop crowing benchmarks. The performance difference between C/C++ and Java is almost always huge in real world applications. I can remember reading a Java vs C++ benchmark not long ago where the Java benchmark was faster. Why? Because the benchmark purposely avoided collection, thusly hiding a huge performance effect. Solution, I obtained the author's C++ code, slapped in a GC for C++. Results? C++ was 500% faster.

Time and time again, Java developer's prove that they do not even understand how to benchmark. And frankly, comparing the two languages on an even balance is a tough nut. They need to stop the lies and misrepresentation and tought the strengths that Java REALLY does have. As soon as someone brings performance into the mix, and the phrase, "good enough", isn't used, a lie is almost certainly to follow. Please guys, stop the lies and simply be honest. Tell people what's great about Java. Stating that Java is on par with languages like C and C++ is simply not true.

Actually, that's not true. The 500% improvement was for removing his delete's from the code, which mirrored the behavior of what Java was doing, as it never collected. Using the GC resulted in somthing like a 300% performance improvement and that was without tuning the GC at all.

The developer of Imagery was quoted in the article. I am really looking forward to trying that software to see if it is responsive.

It looks great!

Andrew

Does the app perform acceptably fast for the user? And if a server app, does it perform acceptably for each user under a given load? Does it scale "well" (app and environment dependent)?

That is the ONLY criteria.

Java GUI looks are utterly irrelevant as not five users on the planet care. Not to mention being utterly irrelevant vis-a-vis performance.

Quality of design is the only criteria of significance in determining performance, with code quality being second. Language choice is a distant third.

Finally, C++ is hardly a PLATFORM. It is a LANGUAGE. Sure, it probably has tons of freely available libraries, too, after many years (and more non-free ones since that sort of thing preceded OSS). But c++ is NOT a PLATFORM the same way Java is. How many OSS workflow managers do you see written in C++? Web application servers? Business rule engines?

When's the last time you wrote an applet in C++?

When's the last time you heard about connecting Web browsers to C++? Perl? Yeah. Java? Yeah. Python? Yeah. C++? Gimme a break.

The main reason people trash Java is because they're Windows Visual Basic or Windows Visual C++ programmers. Take a hike!

Here were some benchmarks I did on Java vs. C from awhile ago:
http://fails.org/benchmark.html

I had a quick look at the java code for the I/O benchmark and made some adjustments. The result is... interesting:

Old code: Reader/Writer, average of 10 runs: 4220
New Code: Input/OutputStream, average of 10 runs: 1365

Converting it to use streams instead of reader/writer made it more in line with the other results.

>> http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
>> How can that be true?
>
>Because its straight math, no real IO, threading, object creation, etc.

But you see, that *can't* be true. Because Java defines floating point math to be the same on every platform (IEEE754), which means you can't use any floating-point hardware that has extensions to floating point math. So either they're not using a conforming Java implementation, or their C++ code sucks. And the state of the art of Java in 2001 was a *lot* worse than it is today.

>but can you C++ app..............
>run on many platforms straight away without modification ?

Yes. Try wxWidgets.

Also, have you tested your Java app on all your platforms? Different vendor's JVM's, etc. I doubt it.

I'm not a fan of Java on the desktop. Speaking as an end-user, I have used various desktop Java apps at different companies. These were all custom apps written in-house (I'm using one at my current workplace too). The one thing that distinguishes all these apps is their slow, sluggish performance. So no, I'm still not convinced that Java on the desktop is fast. No amount of arguing about about poor coding is going to change my opinion (or that of other users) - it's the end result (or "user experience") that matters, and Java simply fails in this respect.

As for cross-platform capability - who benefits? You as a developer? Or the end-user who has to put up with a sub-standard UI that conforms to the most basic common elements across different platforms so as to not break that all-important "cross-platform compatibility"? Give me a fast, natively compiled app, fully tweaked for the platform it runs on and able to take full advantage of all the features of that platform (regardless of whether any feature exists on another platform).

Finally, as to the perception that Java used to be slow, but is now much faster, well, I'm not convinced about that either. PC's have certainly got faster, so it naturally follows that any software will also run a little faster including Java. Perhaps a better measure is whether the most current version of Java runs faster than previous versions on older machines.

It always seems to be developers claiming that Java is fast on the desktop. You rarely hear the same from end-users. In general, I try and steer clear of installing any Java apps on my PC at home, and that means I've disabled Java in my web browser too!

No real numbers to refute that Java is slow. The author admits that Java takes up more memory, takes more time to run and looks uglier. How anyone can come up with the conclusion that Java isn't bad is beyond belief. Where's progress when a newer programming language does worse than existing ones.

The reason why Java survives at all is because clueless project managers locked into it as the current buzzword. I don't know how many conversation with managers I've been involved in that didn't make any sense. "It is the company's initiative to think outside the box and to synergize by ciscoing the java, and XMLing the voip". You could have the best legacy app in existance and some dumbass will want to replace it with something inferior because the old app is no longer shiny and new. I never understood why cross-platform was so important for businesses. Most businesses run the exact same desktop hardware for all their workers. Same platform, same OS, same apps. Easier to administer if every PC is identical, easier to create in house apps. Cross-platform made sense for home users that do have a variety of hardware/OS/apps but home users have been choosing not to run Java.

I'm so frickin tired about how fast a java program starts. Guess what,launching any program via citrix(e.g. Word) is three time longer (at least) than starting a quite big java app. And guess what!Managers find this response time very good! So, I don't want to hear anymore java app takes ages to start.This is very relative.

Very well written article. I have been using one program on Os X through all its versions. The current version on Tiger seems to quite slick. While it 'appears' to be a little on the slow side, it is perfectly usable. The application is called Sequence Analysis for those interested in molecular biology (you can find it on Version Tracker).

Flame War,
Flame War!
Party time,
Excellent!

Thanks for the great article, as well as your previous article, which was an interesting read!

Concerning performance: a while ago I wrote some a simple language analysis program in Java on NetBSD doing many balanced binary tree operations. JDK 1.1.8 was the last "blessed" JDK for NetBSD, and that is what I used for the initial developent. Lateron I switched to JDK 1.4.x for Linux on NetBSD. The run time (mostly consisting of tree operations) was ten times shorter with JDK 1.4.x than with 1.1.8. I wrote a program that did the same operations in Pascal and compiled it with FreePascal, except for the startup time the performance barely differed. After that I stopped worrying about Java vs <insert other compiled language> performance.

Some people still think Java is as slow as in 2000, but it is not. BTW, I always loved Moneydance as a good example of a good Java application:

http://www.moneydance.com/

I've used Netbeans on my PC (Celeron 1300, and I've had no perfomance problems with it) and I must say that it had the worst application performance I've ever seen. The garbage collector isn't able to handle all the *garbage* on time, so Netbeans + the Java VM ended using as much as 200 megs of RAM! In the end, when the situation became critical, the application simply froze for about ten seconds while the GC was freeing up memory. This thing repeated every 5 minutes and drove me crazy.
Oh, and when I tried to run my app at my school with Pentium II-300 with 32 megs of RAM machines a simple 80-kilobyte app loaded for about FIVE MINUTES and with the Java VM used as much as 20 megs of RAM.
Native Java (e.g. GJC like the one used for compiling Eclipse in Fedora) is the answer!

Or why is it that sunone is so unbearable slow? If java apps are sooo fast when written well, then why don't even Suns java apps perform good? You would expect that they do have the knowhow. I have never seen a single gui-Java program that wasn't slow, even trivial ones. But to be fair, none gui programs indeed seem to be fast enough.

How dare you to mention Java?

My Visual Basic is much more efficient, fast and powerfull...

I agree with the fact that the speed discussion doesn't do jutice to all the benefits of the Java language. The portability is a big plus, and to have every discussion focus on speed alone (which is relative to the task, as benchmarks also show Java as quicker) is a waste of energy and might deter people for the wrong reasons. This is not helped by the amazinf zealotery that is roaring in the programmer communities all over the internet.

Please keep discussions on topics and be reasonable. Try to find arguments that could weigh against YOUR OWN arguments, it will give you a better understanding. And don't try to force your beliefs on other by stating nonsense or using only one argument. That not good for anyone. Remember it's not politics or religion (no really, it's not religion), and you can't always be right.

"It always seems to be developers claiming that Java is fast on the desktop. You rarely hear the same from end-users. In general, I try and steer clear of installing any Java apps on my PC at home, and that means I've disabled Java in my web browser too!"

This means that your opinion about current Java performance is less than useless, since you've made it impossible to run Java apps on your machine, and you're obviously not using any current Java apps. Try to form an opinion based on an actual point of reference, rather than the heresay on language war threads like this one.

Also, the comment you made about rarely hearing about good Java performance from end-users is less than useless as well, as end users usually have no clue whatsoever what the application they're using was written in.

Go ahead and try it - ask a non-technical user if they know what programming language the application they're using was written in. I'm 99.9999999999% certain that they'll have no idea. Most of them won't even know what C++ and Java are (other than Java being coffee). It's only programmers who know and care.

And it's only C and C++ programmers, well, the stupid, ignorant language war loving C/C++ biggots, who keep saying that all Java apps suck and that Java is slow and a memory hog.

The smart C/C++ programmers, who know that you should just use the best tool for the job, know that Java is great for some things, and C++ great for others, and that some Java desktop apps are indeed quite good, and that J2EE is very powerful and successful. Bjarne Stroustrup himself, who's book I've read and think the world of, has never, ever bashed Java.

And smart Java programmers know that C++ is great for some things, particularily for game development, large commercial software, and lot's of systems level stuff.

Finally, as has already been said by another poster here, benchmark tests are less than useless. They always are victims of the benchmarker's bias and various skills/knowledge (or lack thereof) of the languages they are benchmarking.

Here are a few obervataions:
- Azureus normally occupies 32mb of ram on my computer, while firefox normally occupies 40mb (few pages opened)
- NetBeans has a lot of potential to be optimized
- Most people are not running java 5, which has the latest performance enhancements
- From my experience, ABC (a python BT client) has always been less responsive compared to Azureus and Bitcomet (a C++ BT client) always has the annoying list flickering bug.
- About java applets: most of them are not compiled under modern versions of Sun Java. Also note that java is running as a plugin in the browser and most browsers tend to handle plugin repaintings a lot less efficiently compared to the lightweight widgets it normally uses for web forms. Similar sluggishness can be seen on the Quicktime plugin as well.
- There are very few commodity desktop softwares written on java. Most in house softwares tend to perform poorly due to limited budgets, which means the developers hired may not have enough experience to use the multithreading facilities of j2se. They probably have no experience with Spin, Foxtrot or even SwingWorker.
- Try RSSOwl, Azureus, Freemind etc. on a daily basis for a while.

http://oddlabs.com/download.php - go on, I dare ya (yes, it is a Java game)

Java IS slower than a native application, and will bascially always be. However, Java provides a lot more for the both the developer and the end user which needs to be taken into account too.

One should note that the JIT compilers we have right now are not even scratching the surface of the possibilities with JIT. Here are a few obvious improvements that could be made:

- Permanent native code caching: right now, the JVM must recompile everything everytime you restart your java app. However, the java team is investigating the possibility of caching the compiled code to the harddrive. This means a large part of the application will not need to be recompiled the next time you start up the application

- Generics: The java5's implementation of generics is rally a hack to preserve compatibility with older VMs. They could make much better use of the type information.

-Autoboxing: Yet another hack to preserve compatibility. It would be really nice if they can adapt the algorithms used in the smalltalk JITs to determined when boxing/unboxing really needs to occur.

This means that your opinion about current Java performance is less than useless, since you've made it impossible to run Java apps on your machine, and you're obviously not using any current Java apps. Try to form an opinion based on an actual point of reference, rather than the heresay on language war threads like this one.

Um, did you actually read what I said? In the very first paragraph of my original post I stated I use java apps at work. What does that make your comment? Less than useless as well?

"Um, did you actually read what I said? In the very first paragraph of my original post I stated I use java apps at work. What does that make your comment? Less than useless as well?"

touche'

Anyway, I read the whole thing. But your experience with the Java app could be due to Java itself, or it could be due to poor coding/design by the programmers of the app, it could be due to the enormity of the app, or it could be due to many other factors. Just because one app, or a number of apps, written Java did not give you a satisfied experience does not mean that Java is weak.

By way of example, let me give a small list of applications written in C and/or C++ that I think suck:

OpenOffice - slow to load, slow to run, memory hog - about 95% C++
MS Office - bloated, buggy mess - 100% C++
MS Windows - swiss cheese security, unstable, buggy, overpriced - mix of C and C++
Oracle DB - although very powerful and scalable, it's a huge resource hog and hard to use - C and C++

Now, would it be fair for me to conclude that C++ sucks just because I think these apps written in C++ suck? Of course not.

How well, how fast, programs written in different computer languages perform is definitively an important topic. Considering which languages help in improving, and which languages impede performance in a specifc situation is important too. Yet articles like these are worth next to nothing. Presenting a "Java is slow" Myth is a straw man argument. No serious Programmer will maintain a myth of this sort. Of course you can achieve fast programs with Java, at least for some sort of programs, and if you take some care. The same is true for every computer language I am aware of. After all, every programming language is just one representative of the same computational model, the same abstract machine. You could express a Java program as an C++ program, and vice versa (*).

It would really suprise me, if with the current high-quality Java VMs and compilers, almost all programs would perform bad. After all, Sun and other companies spend millions on improving them (Compare this to the mostly voluntarily developed implementations for numerous other languages).

So if you want to compare the "speed" of programming languages, Benchmarks are notoriously bad. But you can analyize which impact on speed the features of a language have. To achieve the desired result, which cost do the used features incur? How well can an implementation of the language optimize a given part of code? A meaningful comparision of languages, with respect to speed and efficiency, must discuss, why for a given programming problem, an implementation of the language which is discussed, is able or is unable to produce efficient code. This Article, and most of the Articles I read, whose claim is that Java is not "slow", fail horribly to do this. Often the same arguments get repeated. So here: It is argued that the JVM (or the compiler) knows which processor it is running on, and can optimize accordingly. This is of course meaningless. It is irrelevant to the execution speed at which point in time the decision is taken to optimize for a specific processor. This article is little better though than the last one I read about the issue. Here the Author qualifies his statement, and mentions that this point is only true for commercial software. Nevermind that this is the wrong terminology, since the question is not whether commercial or not, but whether the source is available or not, but this qualification is also rather irrelevant to the discussion, because is basically only says, that if you deliver ill-optimized code, the code will not perform well. Well, one could call this tautological. Another of the arguments which do not help understanding is the point about knowledge which code gets included in the program. The article says a Java compiler will know which classes are loaded, and can base decisions about inlining on that. This is of course true (also the Author probably did not mean "classes", but "implementation of classes"), but it can be true for C++ as well, for example, or for Ada or Pascal or whatnot. With these languages you also can make a decision about how much code the compiler gets to see when producing the binary program. In these notoriously bad Articles, the Authors do not only present the wrong arguments why a Java program should be faster, or can be faster as one written in another language, they also do presen phony reasons why there could be a performance hindrance to the Java version. This time its for example "JVM startup time". The Author discusses if or if not the startup time should be included in Benchmark figures or not. As if this was an issue. I rarely do use Java, but I know that JVM startup is blisteringly fast, given the size of the JVM. Kudos to the Sun Programmers, they did great work (Especially given the fact, that at least the Hotspot VM is written in C++, and one can say that C++ has issues with program startup time on many architectures!). So I can not understand why alleged Java programmers apparently do not know that this is a non-issue.

I as a (mainly) C++ programmer can point out some issues where C++ language features impede performance. Other more knowledgeable people in the C++ world can even point out more. This is good, because this way one can work on the issues, and produce a better version of the language in the future. But Java people almost invariably get it wrong (at least if you read the slashdottet, osnewsed, random Java-Fan blog, etc... publications): They can not point out the real reasons why Java programs are faster in a specific benchmark, and they fail to recognize the true factors which are problematic with C++.

-------

(*): This may not be true of *really* all programs, but I suspect at least for most real world programs one could do.

I do not think the performance is such a problem, it is the awful look of each and every swing gui. The themes suck, and the fonts too (there is no subpixel hinting).

on may laptop (500mhz, 192mb ram) you can watch netbeans redrawing the window line by line.
I know that my lapop is slow, but even doing 3d cad in software-opengl is faster than this...

All 3 of your bullet points are what .NET/Mono does now.

Actually, look at Java 7 to get the big VM changes. Supposedly, Java 7's VM will be a lot more friendly for dynamic languages.

"java -server" makes wonders to performance, providing you have a good amount of memory.

I know. Swing looks horrible on LCDs. I got into with one of the Java2d guys over at Javalobby, where he claimed that Swing fonts weren't bad and that it has not impeded Java growth on the desktop.

No wonder Sun and Java has had problems on the desktop when their Java2d guys have their head in the sand.

Look for a Mustang snapshot with subpixel rendering in it to be released this week. Probably tomorrow or friday.

Hi Martinus, Do you think our Swing-based app looks awful?

http://xerto.com/images/screen-shot.png

If so we'd definitely appreciate any feedback on how to make it look better.

I agree with you about the font rendering. Looks like that will be fixed in Mustang which is nice. In fact, if as previously mentioned that's fixed in an upcoming preview build, I'm very keen to try it out.

I agree with you that there are a lot of poor looking Swing apps out there, but then again there are a hell of a lot of poor looking non-Swing apps too IMHO.

"Hi Martinus, Do you think our Swing-based app looks awful?

http://xerto.com/images/screen-shot.png "

Wow, looks fantastic. Really, that is one nice looking interface. And it should shatter to pieces the notion that Swing GUIs look bad.

Thanks JeffS, glad you like it.

It's not to say that it doesn't take a reasonable amount of effort to get a good looking Swing app, but I think that's true of a lot of GUI frameworks, and at least Swing is readily customisable.

Someone earlier mentioned that C/C++ was a general purpose language.

That may well be, but C/C++ slowly but surely getting relegated into the specialty role, whereas Java is becoming the general purpose, first to reach for tool.

As has been mentioned here, Java is "fast enough" for a wide range of applications, and continues to get better and better, through a combination of JVM improvements, library improvements and new code.

You can pretty much do anything but write device drivers in Java today. From monster applications running on huge clusters on down to handset apps on your cell phone, the base platform and the JVM itself has proven to be resiliant and capable.

You can do all of that in C/C++, of course, but if the performance metrics work out, you can do it easier and faster in Java through a combination of simply being an easier language to use combined with leveraging the VAST amount of Java based infrastructure available today.

Java's umbrella is huge, and getting wider, while C/C++ is getting crowded out into more niche areas. Once Java survived Applets and made its big bang on the server side (where WORA is working pretty good at the JVM level, and creeping up into the J2EE server space as well with portable WARs and EARs) and is beginning to make a larger impact on the desktop, meanwhile having its foundation consistently and incrementally improved (from better JITs, better libraries, things like the MVM, etc.), the pain and expense of developing in C/C++, fighting library and binary issues, etc. is looking less and less attractive.

C/C++ still has a very strong foothold in the commercial consumer marketplace, but behind the scenes, on the server and on corporate desktops, which is arguably a larger market in terms of $$$ into software, Java is going strong and growing.

In many circles, C and C++ have to justify their use over Java rather than the other way around.

Those circles are getting bigger.

"Thanks JeffS, glad you like it.

It's not to say that it doesn't take a reasonable amount of effort to get a good looking Swing app, but I think that's true of a lot of GUI frameworks, and at least Swing is readily customisable."

No problem. Is your software available for free trial download? If so, what are the hardware requirements?

That app looks nice. All you need is for Mustang font improvements. I think the green looks good. Nice "cool" colors.

In my opinion the article is trying to defend java because it is flawed. I don't understand what it takes for java to be snappy. On the applet front esp in web browsers I dread applets, after all from a layman point of view applet does nothing more than have some fancy animation. However the important point is if java bloat takes sometime to load before showing the artifacts I'd rather block it. The point of java being memory freindly, aw c'mon fire up azureus and look in the task manager. If the whole point behind java was platform independence it is a failure.

he point of java being memory freindly, aw c'mon fire up azureus and look in the task manager. If the whole point behind java was platform independence it is a failure.

While you are at it, fire up firefox and open a few pages. See how much memory firefox hogs. Also, make sure you also open up Microsoft Word and open a document with 5+ pages containing a few charts and equations and see how everything goes.

The threading problem is a very common problem. Unfortunately, j2se doesn't include a readily available solution to solve this problem, unlike VB, which provides doEvents.

"No problem. Is your software available for free trial download? If so, what are the hardware requirements?"

It's not available just yet but it will be as soon as we enter our beta testing phase. I can't give an exact date for that just yet though sorry.

Hardware-wise, it should run fine on any PC from the last few years but you'll obviously get better performance if you have a newer PC with decent graphics acceleration and a reasonable CPU (for instance if your processor has hyperthreading it'll take advantage of that, which is quite handy if you're regularly cataloging large amounts of images).