Linked by Andy Roberts on Wed 1st Jun 2005 16:22 UTC
Java Following on from my previous article, the Java platform has an even greater image problem that is more than skin deep. Coming under yet another two-pronged attack, you'll typically hear complaints falling into the two camps:
Order by: Score:
its slow, and a memory hog ;)
by Anonymous on Wed 1st Jun 2005 16:38 UTC

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...

Prove it.
by Jim on Wed 1st Jun 2005 16:40 UTC

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?

but can you C++ app..............
by Snake on Wed 1st Jun 2005 16:44 UTC

run on many platforms straight away without modification ?

RE: but can you C++ app....
by Anonymous on Wed 1st Jun 2005 16:48 UTC

> 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.

v Java
by Anonymous on Wed 1st Jun 2005 16:49 UTC

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.

Layout
by snowflake on Wed 1st Jun 2005 16:52 UTC


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.

RE: Java
by Anonymous on Wed 1st Jun 2005 16:55 UTC

> 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.

RE: RE: Direct comment link its slow, and a memory hog ;)
by Anonymous on Wed 1st Jun 2005 16:57 UTC

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.

"Sun licenses search software for desktop push" (watson)
by Jim on Wed 1st Jun 2005 16:59 UTC

"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...

It's slow!
by . on Wed 1st Jun 2005 16:59 UTC

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?

Why Java is considered slow. It's not though.
by Anonymous on Wed 1st Jun 2005 17:00 UTC

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.

Java applications that I use everyday...
by Kwarizmi on Wed 1st Jun 2005 17:00 UTC

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.


Misunderstanding...
by alpha99 on Wed 1st Jun 2005 17:01 UTC

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...

Slooooow
by Peskanov on Wed 1st Jun 2005 17:01 UTC

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.

Other camps
by thrift on Wed 1st Jun 2005 17:02 UTC

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.

Java vs C++ benchmark.
by Anonymous on Wed 1st Jun 2005 17:02 UTC
RE: Layout
by James on Wed 1st Jun 2005 17:02 UTC

>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 one...
by Aran on Wed 1st Jun 2005 17:05 UTC

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...

RE: Java vs C++ benchmark.
by Anonymous on Wed 1st Jun 2005 17:09 UTC

> 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.

RE: but can you C++ app..............
by Anonymous on Wed 1st Jun 2005 17:11 UTC

"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.

Re: How can that be true ?
by Bascule on Wed 1st Jun 2005 17:27 UTC

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

speed
by someone on Wed 1st Jun 2005 17:30 UTC

>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.

Intellij IDEA.....
by Victor on Wed 1st Jun 2005 17:32 UTC

...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.

It's not just GC and/or JVM
by Practitioner-Of-The-Art on Wed 1st Jun 2005 17:39 UTC

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.

java runs everywhere
by blk on Wed 1st Jun 2005 17:40 UTC

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.

Reuse objects for better performance
by Andy Roberts on Wed 1st Jun 2005 17:40 UTC

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/

Java is great..
by Chris on Wed 1st Jun 2005 17:42 UTC

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...

v LOL
by Dr.BooBooGone on Wed 1st Jun 2005 17:42 UTC
@Java runs everywhere
by Andy Roberts on Wed 1st Jun 2005 17:44 UTC

.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.

How slow is too slow - personal preference?
by Darius on Wed 1st Jun 2005 17:46 UTC

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
by Lumbergh on Wed 1st Jun 2005 17:47 UTC

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.

JVM load time
by Andy Roberts on Wed 1st Jun 2005 18:12 UTC

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.

Good Java app: Moneydance
by Anonymouser on Wed 1st Jun 2005 18:13 UTC


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.

@Darius
by Andy Roberts on Wed 1st Jun 2005 18:17 UTC

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.

re: Good Java app: Moneydance
by Andrewg on Wed 1st Jun 2005 18:21 UTC

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.

RE: Java vs C++ benchmark.
by Anonymous on Wed 1st Jun 2005 18:24 UTC

>> 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.

People should open their minds
by JeffS on Wed 1st Jun 2005 18:25 UTC

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.

Compile/Run cycle
by MatzeBraun on Wed 1st Jun 2005 18:29 UTC

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.

Fast
by gghgh on Wed 1st Jun 2005 18:30 UTC

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.

performance? how about stability?
by brian on Wed 1st Jun 2005 18:31 UTC

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 VM does not need to be large.
by Anonymous on Wed 1st Jun 2005 18:34 UTC

> 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.

RE: performance? how about stability?
by Anonymous on Wed 1st Jun 2005 18:37 UTC

>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.


Lies, damn lives, and benchmarks
by Andy Roberts on Wed 1st Jun 2005 18:42 UTC

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.

Good article.
by Joris on Wed 1st Jun 2005 18:43 UTC

One of the best recent articles about java performance

finally

Performance pi**ing contest
by somebody on Wed 1st Jun 2005 18:45 UTC

** 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).

RE: Lies, damn lies, and benchmarks
by Anonymous on Wed 1st Jun 2005 18:51 UTC

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.

correction on RE: Lies, damn lies, and benchmarks
by Anonymous on Wed 1st Jun 2005 18:56 UTC

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.

Imagery
by Andrewg on Wed 1st Jun 2005 19:10 UTC

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!

Re: Bascule
by zarr on Wed 1st Jun 2005 19:18 UTC

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. ;)

to dispell Java hype/misinformation
by emarkp on Wed 1st Jun 2005 19:37 UTC

>> 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.

Java on the desktop
by AMH on Wed 1st Jun 2005 19:45 UTC

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!

Biased
by konkat on Wed 1st Jun 2005 19:45 UTC

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.

Enough is enough
by Bud on Wed 1st Jun 2005 19:48 UTC

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 nicely written article
by Hobbs on Wed 1st Jun 2005 19:53 UTC

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).

Welcome to Flame's World
by mat on Wed 1st Jun 2005 20:05 UTC

Flame War,
Flame War!
Party time,
Excellent!

Nice article
by Daniel de Kok on Wed 1st Jun 2005 20:09 UTC

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/

Netbeans performance
by Zlogic on Wed 1st Jun 2005 20:16 UTC

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.

Re: Welcome to Flame's World
by alpha99 on Wed 1st Jun 2005 20:22 UTC

How dare you to mention Java?

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

Agree
by Mike on Wed 1st Jun 2005 20:35 UTC

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.

@AMH
by JeffS on Wed 1st Jun 2005 20:36 UTC

"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.

A few observations
by someone on Wed 1st Jun 2005 20:45 UTC

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.

Java performance
by Brian Matzon on Wed 1st Jun 2005 20:46 UTC

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.

JIT vs. statically compiled
by someone on Wed 1st Jun 2005 21:00 UTC

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.

@JeffS (IP: ---.ded.pacbell.net)
by Anonymous on Wed 1st Jun 2005 21:19 UTC

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?

@amh / annonymous
by JeffS on Wed 1st Jun 2005 21:28 UTC

"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.

Not a good Article
by El Pseudonymo on Wed 1st Jun 2005 21:31 UTC

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.

Swing looks bad
by martinus on Wed 1st Jun 2005 21:45 UTC

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).

yes, java is slow
by smashIt on Wed 1st Jun 2005 22:10 UTC

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...

RE: JIT vs. statically compiled
by Lumbergh on Wed 1st Jun 2005 22:22 UTC

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.

Re: The Java performance debate
by Mr. Foo on Wed 1st Jun 2005 22:24 UTC

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

@martinus
by Lumbergh on Wed 1st Jun 2005 22:25 UTC

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.

RE:Swing looks bad
by Simon on Wed 1st Jun 2005 22:29 UTC

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.

@Simon
by JeffS on Wed 1st Jun 2005 22:55 UTC

"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.

RE: @Simon
by Simon on Wed 1st Jun 2005 23:11 UTC

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.

Java is General Purpose
by Will on Wed 1st Jun 2005 23:15 UTC

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.

@Simon
by JeffS on Wed 1st Jun 2005 23:24 UTC

"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?

@simon
by Lumbergh on Wed 1st Jun 2005 23:30 UTC

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

Slow
by Anand Pandey on Wed 1st Jun 2005 23:40 UTC

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.

RE:Slow
by someone on Wed 1st Jun 2005 23:49 UTC

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.

Also, make sure you read the article
by someone on Wed 1st Jun 2005 23:54 UTC

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.

@JeffS
by Simon on Thu 2nd Jun 2005 00:14 UTC

"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).

@Lumbergh
by Simon on Thu 2nd Jun 2005 00:23 UTC

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

Thanks. Yeah I'm really looking forward to the font improvements, along with the proper support for backbuffering which is already in the current builds.

The colors for the selection, the filter panel blocks etc. are based on the system colors with hue,saturation, brightness adjustments so they vary depending on your color scheme. You get a nice coolish blue with the default Luna theme on XP for example. The other neutral colors are fixed though. Our general aim was to not let the interface draw attention from the main focus which is the images themselves - hence the subdued color scheme.

Just a reminder
by Lumbergh on Thu 2nd Jun 2005 01:00 UTC

Tomorrow or Friday should be the release of the Mustang B39 build that has the subpixel rendering and some other stuff (like respecting desktop AA settings).

http://java.sun.com/developer/technicalArticles/J2SE/Desktop/mustan...
Scroll down to the Java2d section.

If Sun cares about the desktop, they'll backport this to Java5 in a service release.

Perceived Java speed
by Gern on Thu 2nd Jun 2005 02:07 UTC

I used to avoid any program that was developed in Java, until I tried FreeMind. I cannot think of any part of the interface of FreeMind that feels sluggish in any way. In fact, if it was not me who installed it, I would likely not even realize that it was a Java program.

Since installing FreeMind I have tried several other Java programs and have found many (but not all) to have similar speediness in the interface.

It seems to me that this Java is slow preception is a myth.

so
by joe on Thu 2nd Jun 2005 02:42 UTC

how much more memory just to make a java app look nice?

it always seems that java eats memory willy-nilly, sometimes I am doing nothing at all and a java app will still go up and down with memory usage as well as processor usage... then if I actually use the app it continues to fluctuate.... I dont get it....

I just think everyone is always interestd in using a new language because it is new and going to be the big thing and it takes a few years to realize it isnt much better if at all then what we were previously using, diffferent yes but not all that better....

Java programs
by someone on Thu 2nd Jun 2005 03:35 UTC

We just need more java programmers who are dedicated to making professional-quality softwares. The user experience often have nothing to do with benchmarks: They have more to do with the dev's skills, knowledge and dedication.

Very nice
by snowflake on Thu 2nd Jun 2005 04:59 UTC


>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.

Looks very nice indeed. What development setup do you use, specifically do you use an IDE for your Java work?

Fast enough!
by Anonymous on Thu 2nd Jun 2005 05:10 UTC

Java by far is the best programming language out there. It is platform independent and has a rich of libraries. I do agree that Java is slower than C++ in some instance, but with the development of new JIT, it will eventually close the gap between C++. With that being said, the ease of developments and portability will out gain its speed issue.

In my line of work, I used java for real time signal processing and distributed application. Since I don't sometime don't my client Operating System, writing it in Java make sense.

it's not java or c. it's you...
by Aki on Thu 2nd Jun 2005 05:40 UTC

first, well-written java apps will always run slower than well-written native compiler apps. not much technicalities or benchmarks must be discussed to realize this. java apps goes through the jvm before the machine can execute it. natively compiled apps are directly executed. but then, well-written java apps can run fast enough for end-users.

second, java is proud of its write-once, run anywhere ability. but then again it does not matter much for at least two reasons.

1. a company normally uses entirely the same OS for better performance and easier maintenance, so that the ability of their java-written apps to run on different OS/machine is of really no use to them.

2. native compilers can offer write-once, compile anywhere, without changing the codes (consider free pascal at www.freepascal.org).

so the bottomline here is, don't tell me that java is slow. don't tell me that my compiler does not offer "write-once, run anywhere" ability. but tell me, how well can you write codes?

RE: Just a reminder
by Dmitri Trembovetski on Thu 2nd Jun 2005 05:52 UTC

OK, I'll say it again: subpixel text antialiasing is NOT critical for java on desktop.

FYI: ClearType is not turned on by default on WindowsXP, even on notebooks. Guess why. (hint: not everybody likes it, another hint: it slows your system down because it's not accelerated on windows xp). Also, do a search on msdn for problems with cleartype and MS office - people complain that text looks fuzzy and unreadable (especially with smaller font sizes).

So Java2D's subpixel text antialiasing is unlikely to be backported to 5.0 (unless Lumbergh who complains so much will buy a support contract and file an escalation =)

Note that I'm not saying that there are no font rasterization problems with Java2D, we know about them and some of those fixes may get backported from 6.0 to 5.0 updates, my point is that LCD text rendering is nice to have but not critical. Regular AA would do just fine for most people _even_ on LCDs. And that's another reason to spend time improving text rasterization..

Having said all that, yes, the subpixel rendering will appear in mustang b39 (along with tons of other juicy stuff), and it will be enabled by default, so if your desktop "text smoothing" is set to ClearType then text in most swing apps will be rendered with LCD AA, on Windows and Gnome.

In case you don't know where to get the latest 6.0 build:

https://mustang.dev.java.net/#download

Thanks,
Dmitri
Java2D Team

It's a culture thing.
by Calroth on Thu 2nd Jun 2005 06:18 UTC

The problem is not Java being inherently slower or more memory-hungry than C/C++ or whatever.

The problem is that a whole generation of programmers has been raised to believe that it's OK to write slow, bloated software. It's a culture thing. Anyone raised on C/C++ in the early 90's would have a large awareness of performance issues, optimisation, etc. etc. Anyone raised on Java/.NET would not; they'd be thinking objects, garbage collection, etc.

Java itself is not much more slower or bloated than any other runtime; it's just the mindset of the people who code its apps. (Also, the Java runtime can in certain circumstances be faster than a C/C++ runtime, since it cam perform dynamic runtime optimisations, whereas C/C++ optimisations are static at compile-time. But that's a completely different debate.)

Good point
by Werner on Thu 2nd Jun 2005 06:36 UTC

General rule, and it does not matter which language you use, if something is to slow, start to revamp your algorithms and patterns, do profiling, in most cases the language is not to blame there (after all java basically does what GTK2 and other Toolkits do, draws its own widgets at basically the same speed as C written GTK2), but in 99.99% of all Cases I have encountered in the last 15 years, the algorithms were. Often it is an unneeded O(n≤) or even worse O(n≥) at places where you could push it down to O(log n) with a little bit of knowing how to use data structures and changing the algorithm, often it is excessive object allocation (typical problem from people who come from the C++ side of things and suddenly are in the we dont have to call delete anymore heaven)

The main problem with Swing applications is, that most people are to lazy to switch on an alternative look and feel, they dump it onto the user with the awful metal look and feel, many programmers are not aware that they have to push longer operations into the background. That is mostly a problem from people who come from the windows side of things, which also blocks at longer operations, but not the control redraw, so that you get the impression that redraw happens instantly, the application just blocks, while Swing gives the impression that it crashed or is dog slow. Sun should push the workers and Foxtrott stuff excessively into the documentation, to fix that problem.

Java's problem is that it doesn't share
by Eric Garland on Thu 2nd Jun 2005 06:55 UTC

"I do agree that Java is slower than C++ in some instance, but with the development of new JIT, it will eventually close the gap between C++"

I don't buy this. I think there are fundamental reasons why Java is slower. Those reasons won't go away without deep philosophical changes Java. The biggest issue I see with Java is that it does EVERYTHING itself, and it does it it's own way. This is seen by developers as a benefit because the libraries are all portable and available on other operating systems but for the end user it's a pain. Here's why:

If there's a library in your OS somewhere for, for example, rendering fonts or tcp/ip communication, odds are you have it loaded and in memory all the time since those functions are regularly used. When you fire up a python application that does these things, odds are it was linked against the same libraries as your file manager or your web browser and those libraries are already in memory somewhere. Since most modern OS's have the concept of shared object files (dll's work that way) the loading is almost instantaneous since both applications end up just sharing the one memory image of the code. When you fire up a Java application, however, it has it's own libraries for doing all these things and it therefore needs to load them all adding tons of disk IO and memory allocation and swapping to the application startup. Now, you might think the answer to that problem is that you simply need to use more things written in Java. This isn't quite the case either though since Java applications all JIT their code instead of linking with shareable object code so the OS doesn't have visibility into the fact that the code is the same and could be shared.

The other big issue I see with Java is all the compiling. People love that huge standard class library but in the end, if you need to compile 50 different libraries into machine language just to get your application to run, it's going to take some time. It will also blow out your RAM caches and disk caches with all the compiling activity. This adds to the "resource hog" feeling of Java and again, this is a hard thing to fix. If they would turn the Java libraries into pre-compiled sharable object code they could fix this. I don't see that ever happening.

I like the idea providing developers with a standard interface to common OS functionality across platforms but Java pushes this to an impractical extreme. Their unhealthy obsession with not allowing anything OS specific is the cause of much of Java's pain. They try to treat Java as the OS instead of the OS itself. Instead of treating it as an OS, they should be treating it as a development platform for making native applications since, in the end, thatís exactly what it is.

Java desktop performance, memory usage
by Anonymous on Thu 2nd Jun 2005 07:31 UTC

Just remembered this old link comparing the memory usage of Java/C# (Mono)/Python/Perl.
http://tirania.org/blog/archive/2005/Feb-09.html

oh .. and need i mention how nice it is (in C#) to not have to care about the difference between int/Int, long/Long etc. and just write "int i = 2 + new int(2);"

@Dmitri
by Lumbergh on Thu 2nd Jun 2005 07:36 UTC

OK, I'll say it again: subpixel text antialiasing is NOT critical for java on desktop.

You are right, and thankfully we have SWT for those that want nice looking fonts. But I'm sure Gnome and KDE users would be perfectly happy without subpixel rendering/hinting on their LCDs.

FYI: ClearType is not turned on by default on WindowsXP, even on notebooks. Guess why. (hint: not everybody likes it, another hint: it slows your system down because it's not accelerated on windows xp). Also, do a search on msdn for problems with cleartype and MS office - people complain that text looks fuzzy and unreadable (especially with smaller font sizes).

So now you're trying to argue that ClearType is not good. It's fuzzy...there are problems. At least you have the option of using it or not. With that attitude its no wonder that its taken so long to address this issue. At least people have alternatives (SWT)

So Java2D's subpixel text antialiasing is unlikely to be backported to 5.0 (unless Lumbergh who complains so much will buy a support contract and file an escalation =)

Swing isn't the only game in town.

... my point is that LCD text rendering is nice to have but not critical. Regular AA would do just fine for most people _even_ on LCDs

In your opinion it would "do just fine". And you're right again, it's not critical for Java because we have SWT.

What about Swing on OSX? It looks great.

I'll download the B39 build today or tomorrow and check it out.








Load of crap!
by deepspace on Thu 2nd Jun 2005 08:03 UTC

oh .. and need i mention how nice it is (in C#) to not have to care about the difference between int/Int, long/Long etc. and just write "int i = 2 + new int(2);"

Oh, java can have that as well, there are preprecessors for that ;)

About all the comments: Just a load of crap! Both pro and conn still stick to the same good old excuses to have an opinion about java, mumbling about a few details. Come om, look at the whole picture before making up your mind about how great java is, or how much it sucks. I guess, in the end, it somewhere in between. I could just as well start praising or bashing any other programming language...

Re: Load of crap!
by Jimmy on Thu 2nd Jun 2005 08:25 UTC


oh .. and need i mention how nice it is (in C#) to not have to care about the difference between int/Int, long/Long etc. and just write "int i = 2 + new int(2);"

Oh, java can have that as well, there are preprecessors for that ;)

Didn't know that. Gave up on Java a few years ago, started playing with it again recently, but got kinda dragged into C# instead, and was very positively surprised with how well the language works compared to Java.

In my heart i want to write all software in C (old school C programmer), but the productivity gain in higher level languages like Java,C# and Python is just too big to be ignored, and i'm more than willing to accept a small performance penalty in exchange for that, but the larger memory usage, slower load times and general "lag" of most java applicatinos (azureus, eclipse, jedit to name a few) is just too high a price to pay.

Someone mentioned that python apps actually loads faster / runs better than java apps, and I must agree that this is the case... on Linux anyway.

Re: Load of crap!
by Jimmy on Thu 2nd Jun 2005 08:30 UTC

Oh .. and before someone starts the "Buy better hardware" thread :
the slow applications are used on an AMD64 3200+ with 2gb ram, Sata raid 0.
and the same goes for my T43 Laptop with 1.5gb ram.

python/C#/C apps will load almost instant (1-2 sec), java apps still requires 10-20 sec load times.

@Dmitri
by Jasper on Thu 2nd Jun 2005 08:44 UTC

Personaly I am not a fan of Clear Type and have it off by default. But Java's font rendering is poor in its non-antialiased form and its antialiased form. Just compare how text in Java/Swing looks compared to Windows, Photoshop, Flash or most apps for that matter. I recently used PHP over java for rendering dynamic images for the web because its font rendering was way ahead. I hope the new Mustang will improve all font handeling not just sub-pixel.

Re: Very nice
by Jasper on Thu 2nd Jun 2005 08:56 UTC

At Xerto we all use IntelliJ, it has so many ways of helping you like refactoring and intentions etc. I think I am probably 20-30% more efficent with IntelliJ then any other IDE I have used. I think Eclipse has copied a lot of the features but I just find the interface hard to live with. We use the IntelliJ gui builder for layout in dialogs and wizards but all the main panel is layed out by hand. This is mainly due to limitations in the IntelliJ gui builder, like you can't add custom containers, or components that you want to construct you self. It would be nice if you could add place holders which can be replaced with your own component in code. We have started to use the IntelliJ layout manager from code which works well. The reason we like there layout is because it gives you lots of control over the spacing between things, if you ask any designer they will tell you that the white space is just as important as the content in making something look nice.

"My anecdote is better than yours"
by Andy Roberts on Thu 2nd Jun 2005 08:59 UTC

The thing that strikes me is that most of the comments are from anecdotal experience (including much of mine!) For example, I don't know what I've been doing differently over the years, but I've never had to wait long at all for the JVM to load. Up until recently, my PC was an old Athlon 600 with 256MB RAM. On that machine, some Java apps did run slow (like Eclipse), but, so did many other apps written in other languages. So, from my experience, Java hasn't been that slow, which is why I still use it.

My current machine is a laptop with a Pentium 4M 1.7GHz with 1GB RAM. This is the fastest machine I've owned. I friend has new AMD64 at 3+ GHz plus ~1.5Gb RAM (I think) and that runs super-fast. So, my machine is slower than my friends, but it still feels extremely snappy - more than adequate for my needs. It's slower than the latest specs coming out, but is it "slow"?

The issue of speed of Java apps.
by Ashok on Thu 2nd Jun 2005 09:14 UTC

Those who complain about the speed of Java applications for desktop should try the backup application AKGBackup (http://www.akgupta.com/applications/akgbackup.htm) and compare its speed with other backup applications. I am sure the experience would prove to be an eye opener.

My P2P program is better than your web browser!
by vg on Thu 2nd Jun 2005 09:15 UTC

> Here are a few obervataions:
> - Azureus normally occupies 32mb of ram on my computer, > while firefox normally occupies 40mb (few pages opened)

Ehh, did you (and many others here) just compare a simple P2P-application to a complete web browser?

Java just doesnt cut it by any measure
by NoWayHosay on Thu 2nd Jun 2005 09:18 UTC

First a word on java benchmarks. I remeber reading a performance tuning book on java while in the throws of a huge project invovling java, J2EE, Websphere, etc...
The book went on to measure a web server perfroamnce in java and then compare it to some c++ ones. And then showed how to make it compariable via various techniques. What amused me no end, was you had to use dozens of techniques (which are good practise in any language ) to get it perform equivilantly to an unoptimized version of the C++ one. If you applied the same techniques to the C++ one, it would be in the lead again. This sentiment kinds of summirises all I have every heard of java, well you can make it perform well if you code correctly. I am sorry this is true of any language!

As an example, I coded many applications in java, and when they were too slow, I would code them exactly the same in C++. I have done this dozens of times. Most of the time, what you would see is say the java one taking 10 seconds to do XYZ. Then C++ would take 8.5 seconds. No biggie you say ?
Well what if I told you the C++ one used 10-20% of the cpu for those 8 seconds and java used a woping 100% for its whole 10 seconds?

In the end we could only get between 20-40 users onto each cloned JVM for that particular project, ironicallty this was due some of the much vantid caching techique you have to use to get java to perform? while I never did the whole app in c++ (I am not that sad) I have no doubts if we where using other langauges like c++ we could have got far more scalability with the exact same design and hardware.

**"Andy, I don't like Java because it's slow" are the very same people who use Perl/Python/PHP***

Speakign as someone who has done extensive work on J2EE business applications as well as B2B java apps etc.. I can point out straight away that python, despite some benchmarks, always lands up being super fast compared with java for real world apps I have written! You can rant about JIT all you want, processor specific code etc.. I have worked with both for years and python outpeforms java with amazing regularity.
If I have to choose a dynamic language, with platform independance I choose python anyday!

***"Programs known to be memory intensive by nature, like scientific applications can in fact be limited by the JVMs conservative usage, and so many developers launch their Java apps with special JVM flags that permit Java to utilise additional memory"***
Its simple fact that JAVA consumes more memory to the same thing. It has nothign, YES NOTHING, to do with it being object orientated. Write the same session caching system with C++, JAVA, and python using the exact same CLASS design etc.. and guess what. JAVA hogs the boat. you mention that java gives you a lot of framework as a base. Right ok, python gives me MORE. I can do more in python in less time than java and the overheads are lower. Not to mention doing something in python doesnt require learning a million obscure framework classes that are unintutive. Its intiutive simple and easy to use. Then again, from a memory perspective C++ is so far ahead of both that the comparison is a joke.


The main selling point for java always lands up being programmer productivity:
***"As a Java developer, I will happily sacrifice some memory, and a bit of speed, because the Java platform affords many other benefits. I find myself being productive with Java because of its richness and ease of use. I do benefit from the multi-platform aspect too, because I use Linux to develop yet many of my typical users are on Windows."***
And to be fair I can argue this when comapring to C++. The language is cleaner, easier to use. In fact I really liked learning java. However the syntax is not enough to make a language great.

So what about platofrm independance ? well I speak from experience when I say that java is not write once run everywhere. Its write once, test and tweak everywhere.
Its platform independance is far better than that of c++ and other similiar languages. However there are languages which are far better at it than java. Yes I mention python again, but there are many others.
So what about out the box functionaltiy ? Well I covered that already. Java's framework classes are a mess, they hard to use and harder to learn. Most other "scripting" type lanaguages provide far more in a far more devloepr friendly way than java.

Ultimatly C++ or any native langauge is gona beat java at most things except programmer productivity and possibly bug counts. But if your in the market for somethign higher level than C++, JAVA (or even .NET ) is NOT your only choice! In fact they are bottom of the pile in my opionion.

Java is great concept and brilliant idea, but people always tend support something based on its founding ideas, not its actuall implementation. Java is great idea, the implementation doesnt give the idea justice though.

My thoughts.

Python is good
by Andy Roberts on Thu 2nd Jun 2005 09:33 UTC

I should point out that Python is a language I use regularly too for my research (I do a lot of text processing) It's a great language and I enjoy programming with it. Never found it faster than Java, but I haven't done any analysis on it.

It doesn't have the same breadth though. Yes, the main Python interpreter is available on many more platforms than Sun's JRE, therefore, you could argue that it's more portable. Yet, alternative JREs exist which are available on most platforms you care to think of. Whilst it would be nice to be Sun's offical JVM, you can still reach a wide range of platforms with Java and open implementations.

RE: Java just doesnt cut it by any measure
by Anonymous on Thu 2nd Jun 2005 09:47 UTC

"As an example, I coded many applications in java, and when they were too slow, I would code them exactly the same in C++. I have done this dozens of times. Most of the time, what you would see is say the java one taking 10 seconds to do XYZ. Then C++ would take 8.5 seconds. No biggie you say ?
Well what if I told you the C++ one used 10-20% of the cpu for those 8 seconds and java used a woping 100% for its whole 10 seconds?"

Well, sounds like IO was bootleneck. Known, and mostly solved issue (see NIO). However, even if that is true, processor is there to be used, isn't it?

"In the end we could only get between 20-40 users onto each cloned JVM for that particular project"

What the hell were you doing? Cloning JVM's? Why? 2 Gb RAM limit? IO problem again, maybe?

"So what about platofrm independance ? well I speak from experience when I say that java is not write once run everywhere. Its write once, test and tweak everywhere"

Could be for you, but we have a full blown ERP written in Swing, and It Just Works across MS, Mac, Linux, Solaris. Just a tiny bit of tweaking to look more native on OSX.

"I have worked with both for years and python outpeforms java with amazing regularity"

Hum, I have just about the opposite experience. Could you please do something like jake2 (lwjgl version) in Python to reasure me?
http://www.bytonic.de/html/jake2_webstart_de.html

Hardware JVM
by Saqib Rasul on Thu 2nd Jun 2005 10:02 UTC

I dont know if its been mentioned before, but perhaps someone should come up with a JVM chip so that the OS is not burduned with the JVM. We all know hardware is faster than software, so this would be cool.

I have a feeling i heard something about this recently, but i dont know from whom.

Idle
by Andy Roberts on Thu 2nd Jun 2005 10:19 UTC

It's interesting to see that the "perfect" program is one that leaves your memory empty and your CPU idle!

Once again, the benchmarks from the above "Java vs c++" link shows relative performance. Say a Java program uses CPU 5x more than C++. So what? That's what it's there for! If it's causing problems with sluggishness, ask yourself why your OS is letting a process thrash your system. I have C++ programs that give an CPU a good going over, but if it's the only thing my PC is doing, I expect it to take 100% CPU. As soon as I want to do another task, I expect my OS to manage that (and fortunately, Linux is very good at this)

Ask yourself though, how long did it take, and whether the difference in speeds is significant. A 1Ghz CPU means it's running a 1,000,000,000 cycles *per second*. So, it can do in a second. Like I said, half the speed of light is still very fast, even if it is half as slow!

RE:The issue of speed of Java apps.
by realloc on Thu 2nd Jun 2005 10:27 UTC

Those who complain about the speed of Java applications for desktop should try the backup application AKGBackup (http://www.akgupta.com/applications/akgbackup.htm) and compare its speed with other backup applications.

Yeah, like some no-name bloated Java program could beat rsync.

java on OS X
by lucas on Thu 2nd Jun 2005 10:40 UTC

i never thought java was slow on windows, it always seemed fine, even on shitty spec pcs (p2 300, 384mb ram) after seeing the POS that is called a java VM on OS X though, now i know what people whinged about. given the choice i'd never use a java app on OS X again, worthlessly slow

CPU Time
by Anonymous on Thu 2nd Jun 2005 10:41 UTC

"Once again, the benchmarks from the above "Java vs c++" link shows relative performance. Say a Java program uses CPU 5x more than C++. So what? That's what it's there for!"

Wrong. Wrong. Wrong.

Maybe if you were using MSDOS (does ultra portable, write once, run anywhere, JVM run on MSDOS I wonder?) this would be true. However, most of us run *multitasking* operating systems and as such one application hogging the CPU with 100% usage will adversely affect the rest of the system. A more efficient application with 10-20% CPU usage will allow other applications to work happily and the overall system performance will be increased.

So less of this "That's what it's there for!". That sounds like an excuse for Java to be a hog.

RE: Java just doesnt cut it by any measure
by NoWayHosay on Thu 2nd Jun 2005 10:50 UTC

***Well, sounds like IO was bootleneck. Known, and mostly solved issue (see NIO).
"""However, even if that is true, processor is there to be used, isn't it? ""

Well you obviously missed the point about scalability and performance. If it takes twice as much cpu to do something, thats means its processing at half the speed in a multi threaded environment. ( And yes I know half is a lie in real world terms in a bits less but you get the point).

The point is how much can I do with my XYZ box? How many users can I support. How much work a program takes to accoumplish something is VERY relevant. If I can support a 1000 users on XYZ hardware with a C++ application, why would I choose a java one which can only supoprt say 500 ? ( this is just a bullshit example to make a point, no flame wars please)

***What the hell were you doing? Cloning JVM's? Why? 2 Gb RAM limit? IO problem again, maybe?""""
Cloning is a standard feature of most App servers including web sphere. So to answer your question I will ask you one: Why is it a standard feature of java application servers if you sound shocked anyone would use it?

The reasons being if you give java JVMs too much memory they land up spending more time manageing it than do productive work. Performance tuning websphere (and java vms running there in) is a black art, a balancing act of amzing difficulty. And yes the memory limit is the problem. To support 2000+ concurrent users in a fully interactive data intensive web application with backend ERP integration, telephony, CC autherisations, etc.. all in a call center environment where response times are critical. Java simply cant handle it in single JVM, not even close!

***Could be for you, but we have a full blown ERP written in Swing, and It Just Works across MS, Mac, Linux, Solaris. Just a tiny bit of tweaking to look more native on OSX.**
First off, good for you, second I am not saying Java is useless (JEdit is my favorire text editor), just there are better products. If you have a choise (how often do you really ?), you choose the better product.
With regards portabliltiy, I experienced plenty of issues between NT and AIX (that is it worked differently between the two), they were obscure I'll admit but its not write once run everywhere. This was 1.3, maybe its better now. I can only speak from what I have personally experienced.


***Hum, I have just about the opposite experience. Could you please do something like jake2 (lwjgl version) in Python to reasure me?
http://www.bytonic.de/html/jake2_webstart_de.html***

Since I dont read the langauge I am not sure what it does. But if you want a specific example, a while back we had to Process a 400 MB CSV File with 30+ columns. We accessed about 20 of the columns using numeric indeces, and wrote them to a new file. In python we used the std CSV class. In java we used a 3rd party class found via google.

I dont recall the specifics, but it was at least a 30 second difference when we did it (python 1.4/Java 1.4 I think). since we needed it run regularly for a while, we opted for the faster.





intellij
by silvio on Thu 2nd Jun 2005 11:31 UTC

Well, if intelliJ is "blisteringly fast", can you tell why the interface is so plain, but still you can see the redraws from top to bottom...
just a simple check: copy something to the windows clipboard.
then click on the "project" button on the left thin "tab bar". a slide-out pane will open. AFTER it opens, with a considerable delay, the "paste" icon on the top toolbar changes from grey to normal. On this AMD Athlon 3500+ machine with 1GB of memory, this kind of delay is very unnerving. And, YES, from this kind of little things the user experience consists. And, excatly because of no attention to this, everyone sees java as slow and unresponsive. Waiting at least half a second until the icon becomes normal from grey ? Why is that so ? Because the icon bar update is taken care of after something else or what ? You don't get such behaviour in any NATIVE utility. And if intellij has a bug there that causes that delay, imagine how hard it is to write a good application, if even they cannot do it right.
All in all, it seems that java currently allows creation of bad applications easily, while being very hard to develop responsive applications on.

p.s. other examples from intellij:
on the same pane, there are two buttons, "project" and "packages". click on any of them and then on the other, on the first one again etc. Play with them. Do you see the icons above them updating ? It's supposed to be instanteous. it's not. why ? These are the things which cause user to say an application is "unresponsive".
never mind that any native menu's are not available. Like, you don't always get a chance of right-click "copy/paste" menu in text fields, do you ? That is called consistency.
Also, if we're talking about the new hardware-accelerated stuff, it only shows that really, there's no platform-independence (like any mobile developer will explain to you), you always need to tweak your app to the platform it'll run on.
Let's continue with the same IntelliJ program.
in the same pane, you can see the pane "title bar" with four buttons on the top. What do they do ? Why aren't they made in the same style as others ? Why do they only light-up when clicked ? No tooltips ?
oh..

beliefs
by silvio on Thu 2nd Jun 2005 11:37 UTC

also, please don't blame people for the java's bad performance ideas "sticking". Everyone knows first impression matters. Java blew it.
About the open-source toolkits to "fix" java stuff. Well, why didn't java include them from the start ? You said for yourself that it was java's idea to have everything implemented from the start and not depend on open-source fixes, didn't you ?
Well, it seems that idea was incorrect now.
There is a reason why most of the people think java is bloated. That's because if you really want to write a nice app, you use 3rd party skins, you use 3rd party memory management mechanisms etc. Why include them in the first place ? To allow people to write bloated apps ? Well, that was accomplished, a complete success. 100% of the apps tried were unresponsive (unresponsive is not slow, it means that you may get the same results only twice slower, but user experience is ten times worse). As you see, nobody wants to write a wrod processor or an email client in Java, and there's a reason to it. Those applications do not require any much processing power. But they require user experience, and responsiveness. Java clearly lacks at it. And what is going on with no double-buffered display capability ? What century are we in ?

@Intellij
by Andy Roberts on Thu 2nd Jun 2005 12:17 UTC

My machine is slower than yours, but Intellij runs and redraws as fast as any native app, in my experience at least. I don't what I'm doing different. Maybe it's an OS thing. I'm in Linux and all my Java apps run smoothly as any other app. It's not that I'm a particularly patient guy. I know what a slow repaint is, and I don't see it.

But that's something you need to look at. It's runs slow for you; it runs fast for me. Based on these experiences, is it slow or fast?

@Beliefs
by Andy Roberts on Thu 2nd Jun 2005 12:23 UTC

When Windows first came out, it blew. When the next came out, it blew too; And so on and so on. (Some say it still sucks) But, it's the most popular OS on the planet. Part of its success is obviously from its devious marketing strategies, but it's also because it gradually improved. First impressions didn't count here.

The Linux kernel, when it first came out, couldn't do a lot. Now, it's running on some of the fastest supercomputers there is. First impressions would have denied this, surely, because when Linux first came out, it wasn't very good.

Most things when released aren't up to much, especially commerical offerings, since they need to get products out of the door, even if it's not fully featured. They get better though.

First impressions are important, but if you want to be taken seriously, you have to judge things on their current merits, because hey, things change!

yeah, whatever
by Chris Herborth on Thu 2nd Jun 2005 12:54 UTC

That article went into religious ranting mode pretty quickly.

As a user, Java is too slow. I don't really care about the memory issues, just usability and speed.

Azureus on Windows takes too long to start up, and its UI (SWT) is sluggish. The same goes for Eclipse.

On Mac OS X, a platform with excellent Java support, Xcode launches so much faster than Eclipse, it'll make your head spin. You've got projects open before the Eclipse splash screen loads. Xcode + 1 project + 1 source file open is taking up 47MB on my system, Eclipse + 1 project + 1 source file is taking up 69MB.

Sorry, I mentioned that I don't care about the memory issue. Eclipse is sluggish while working, too. Even if you don't typically launch/exit your IDE several times a day (with something like Xcode, I can, because it's not painful), you get these exciting pauses and halts while it loads features on the fly, or just decides to wait a while, or does a garbage collection cycle.

At least you can double-click .jar files these days, or developers provide a platform-specific launcher, so users can ignore the insane java command-line launching.

Every Java project I've seen has been written/deployed in Java because it's "in"; the "free" cross-platform ability of Java has resulted in a lot more work for the developers and the testers, who've had to work against platform-specific JVM bugs and behavioural differences.

No sale.

- chrish

@CPU Time
by Andy Roberts on Thu 2nd Jun 2005 12:59 UTC

I too run a multi-tasking OS. I therefore expect it to make the most efficient use of my resources. Running everything at 20% CPU load is not actually efficient. That's known as wastage, because you're super-fast processor is under-utilised. I want my OS to use available processing capacity, yet, if I multi-task, to let me multi-task, and therefore balance the load evenly. This can be done without running tasks at 20%.

IIRC, in Germany, some Autobahns (motorways/freeways) don't have speed limits. Instead, you are restricted by relative distances between cars. So, you can go as fast as you feel safe to drive, just so long as you don't get too close to the car in front. That's the way I want my OS to run, and funnily enough, Linux does that for me.

@ Chris Herborth
by Andy Roberts on Thu 2nd Jun 2005 13:04 UTC

Could I recommend a quicker IDE? JBuilder is quick, and I've personally found Intellij to be as responsive as any IDE - Java or not.

I've found Eclipse to be sluggish at times. The current milestone is much better. But, the Eclipse framework is meant for large-scale flexibility. I'm not surprised that it takes a performance hit. Still, it's my main IDE and find perfectly decent speed wise.

The JIT compiler can...
by Kango on Thu 2nd Jun 2005 14:43 UTC

.. optimize for different cpus, yes?

I'm not a C++ guru, but when you compile your generic app, what CPU level to you target for? I guess you have to target for the lowest common arch. Am i right?

With Java, you can run the same code on one two machines and you get a performance increase as one JVM can benefit from the extra features in the CPU.

Can anyone else comment? I saw an article somewhere, but cannot find it.

Anyway, i just downloaded Eclipse SDK 3.1 RC1, and shit it's fast. The performance increase on Linux is so great that it now performs like a native GTK2 app. That is no mean feat. This IDE is now king (in my opinion). Probably why Borlands new IDE will be based on Eclipse.

----
daz

write once, debug everywhere
by geri on Thu 2nd Jun 2005 14:47 UTC

The platform independence of java is a SHOULD-BE, not an IS.
If I write a java-app, and I get it working with Internet Explorer on Windows, I would like to be absolutely sure that this application will also work with Mozilla on HPUX.
Fact is, it does not, and it does seldom. If its the fault of Explorer or Mozilla or Java I do not want to know, it is the task of java to make sure that differences of browsers make no difference. The only allowance I would make, would be for java to display a window stating that the current browser is not java-compatible if it is not running.

huh..
by aaa on Thu 2nd Jun 2005 15:05 UTC

i went to a page ( http://shootout.alioth.debian.org/benchmark.php ) they are making so-called benchmarks. i picked an algorithm that it seems it has very bad results in java.
Algorithm was "the fasta algorithm" i think related with Gene patterns. Anyway, i copied the test to my machine, indeed it took 170ms to execute it, while the C++ version took 2.45ms.

then i made a quick check on the software. there was one line which is used for printing out the result to the console output (it was creating the output letter by letter thousand time.). i eliminated that line. You want to know the result??

170 micro seconds!! it was A THOUSAND TIMES faster. every java programmer knows that using console output is a very slow process and it is avoided at all costs, that is why people uses logging mechanisms.

i even tried using a StringBuffer for that line, result was 16ms. which is ten times better then the original numbers. if you just do not write it, but write it to a StringBuffer (because writing console output in IDE is a mgnitude slower then the OS console) it was only 3.5ms.

Result-1: that benchmark page is created just for FUD by a dumb ass.
Result-2: Do not believe in micro benchmarks.

Misconceptions
by someone on Thu 2nd Jun 2005 15:24 UTC

Now, you might think the answer to that problem is that you simply need to use more things written in Java. This isn't quite the case either though since Java applications all JIT their code instead of linking with shareable object code so the OS doesn't have visibility into the fact that the code is the same and could be shared.

I guess you are not really aware that Hotspot in J2SE 5 is capable of sharing class files between difference instances of JVM. And yes, starting another java app is a lot faster.

The JIT compiling problem can be solved by chaching compiled code into the harddisk and use that instead of recompiling the software with JIT compilers. This means your java app will be a lot faster the next time you start it up.

RE: but can you C++ app....
by Jessta on Thu 2nd Jun 2005 15:34 UTC

> run on many platforms straight away without modification ?

What many platforms?
java runs on one platform. The java vm.

@Chris Herboth
by Viro on Thu 2nd Jun 2005 15:48 UTC

Eclipse does a lot more than XCode. It has all sorts going on in the background. Parsing, compiling, etc. This is going to take a hit, no matter what language you use. Let's face it, Xcode is a very simplistic IDE by today's standards. There is no code folding, no background compilation, automatic error checking and correction suggestion, the list could go on.

Of course, Eclipse will start slower and may perform more sluggishly. Slow startup is Java's fault but the slightly sluggish execution is due to all the features Eclipse has.

Java is fast enough for most tasks. I imagine that after 130 posts, everything that needs to be said has already been said.

RE:huh..
by Anonymous on Thu 2nd Jun 2005 16:03 UTC

Then why don't you contribute your code to the benchmark and stop the FUD?

to Anonymous
by aaa on Thu 2nd Jun 2005 16:07 UTC

"Then why don't you contribute your code to the benchmark and stop the FUD?"

i do not believe in micro benchmarking. but this kind of stupidty should be stopped. i send a detailed message anyway.

Problem here is, that algorithm is actually only measuring "console-output" speed in a stupid way, not the actual algorithm at all.

most algorithms and numbers there are pure bull s*it. When you have a DNA stram of a trillion values and make a patten matching there, now that is an algorithm.

@huh
by Andy Roberts on Thu 2nd Jun 2005 16:10 UTC

I'm not sure those benchmarks are deliberately spread misinformation. There aren't many who are experienced in all the languages included to know how to make it fair. If you contact them, I'm sure they'll consider your amendments.

Andy
by aaa on Thu 2nd Jun 2005 16:21 UTC

My problem is, i am against this kind of pages. People are putting micro benchmark results, or line counts as a measure of productivity of a language? those are the most important things unless there is a real bottleneck.
While coding java there can be performance issues depending on your awarness of the language, but in my experience, i have never and ever has a performance problem that could not be fixed in Java. it is low level enough to create a custom solution if the high level solution does not work.
In scripting languages those bottlenecks are far more frequent and usually you cannot find a workaround.
Anyway, if i have time i will check some of the algorithms there just becuase they are spreading wrong information, but note that i do not value those comparisons at all.

correction
by aaa on Thu 2nd Jun 2005 16:23 UTC

"those are the most important things unless there is a real bottleneck. "

should be
"...are not the most important...."

I think java is fast enough
by nestor_kodila on Thu 2nd Jun 2005 18:08 UTC

C/C++ can realy be faster, thats right. But don't forget, ASM is faster than C++ or even C. I think that discussions about performance will ever come up if a newer technology will be born. This is not a new type of debate. Some peapole like rawness and as fast as possible applications another like even simplification. And we should not forget that java brings some simplifications to allow us to develope faster.

To remember some one, that Java has also examples of possible speed is the Quake derivate called Jake. I know it can be faster, but it is an example of possible speed and like this way to show the possibilities. This example shows me, that java is fast enough for me. Another example is a mass compilant product with a big success is Azureus. It shows that a java application can run fast enough to be used by masses.

So my point of view is: i don't want go back to ASM. ;)

Java programmers, please convert to C++ !
by dominic read on Thu 2nd Jun 2005 18:35 UTC


Java is not that much easier to code in than C++.
So please bite the bullet, read a book, and change your ways.

Writing code using an efficient native code compiler will be the most rewarding experience for you.
Just think you will be using 'native methods' all of the time!
And you can use a garbage collector with C++ as well.

@Dominic
by Andy Roberts on Thu 2nd Jun 2005 18:43 UTC

Why convert? I use Java, C++ and Python on a regular basis. "Converting" implies exclusivity. I use the right tool for the right job (from my perspective, at least) and I'm sure I'm not the only one.

RE:Java programmers, please convert to C++ !
by someone on Thu 2nd Jun 2005 19:33 UTC

Java is not that much easier to code in than C++.

I am sure you enjoy throwing exceptions in C++. C++ is also that much more portable compared to Java: You only need a few hundred lines of IFDEF's! All implementations of C++ are perfect and you can make full use of the STL! And MFC is the most object-oriented API ever!

Writing code using an efficient native code compiler will be the most rewarding experience for you.
Just think you will be using 'native methods' all of the time!
And you can use a garbage collector with C++ as well.


I bet you are not aware of GCJ and ExcelsiorJet.

@someone
by Matt on Fri 3rd Jun 2005 01:34 UTC

I am sure you enjoy throwing exceptions in C++.

I'm detecting sarcasm, but I don't get it. How is exception handling that different between C++ and Java? I've been out of Java for a couple months, but I haven't heard of a new exception handling mechanism from the try/catch blocks that handle thrown exceptions.

C++ is also that much more portable compared to Java: You only need a few hundred lines of IFDEF's!

That's just flat out bull. There is a C++ standard that all decent compilers understand. If you write according to the standard, there is no reason for #ifdef's, other than some low-level OS code. And even with that, the only difference between Java and C++ is that Java's "#ifdef's" are in the JVM and the appropriate place for the C++ #ifdef's are in cross-platform libraries that you don't muck with.

All implementations of C++ are perfect and you can make full use of the STL!

Unfortunately, not all implementations of C++ are perfect, neither are all implementations of the JVM. But with GCC you have a good compiler that supports many platforms ( http://gcc.gnu.org/install/specific.html ), more than the number that have a Sun JVM (MS Windows, Linux, Solaris x86, Solaris Sparc, Mac OS X).

And MFC is the most object-oriented API ever!

Ugh... MFC is a GUI API for MS Windows. It is not cross-platform, and it is not built-in to the C++ language; I fail to see how this is a strike against C++. Use a cross-platform toolkit like Qt, wxWidgets, or GTK. I've fallen in love with Qt, it is significantly easier to work with than Swing/AWT and much better for doing any sort of rapid prototyping.

not needed
by tim h @ tjhawkins.com on Fri 3rd Jun 2005 03:34 UTC

we don't really need java or .net anymore. There are easier alternatives

RE: not needed
by Angel on Fri 3rd Jun 2005 04:02 UTC

[i]"we don't really need java or .net anymore. There are easier alternatives"[i]

Care to give an example? Please don't say Python, it's nice but they are not in the same league. Those are apples and oranges.

Overall Cost
by Jupiter Moss on Fri 3rd Jun 2005 12:34 UTC

Java/.NET etc. aren't just about speed. They're about overall cost.

If you're developing in house enterprice systems and you can produce code 5x faster (for arguments sake) and easier in Java/.Net/VB than C/C++ but it runs 3x slower you've two options:

1. Higher 5 C/C++ programmers at £35k each to match productivity
2. Higher 1 Java/.Net/VB programmer at £35k and spend a couple of £k on faster servers/more memory etc.

As a business, trying to make money, what option are you gonna choose?

RE: not needed
by WhyDoyouSayThat on Fri 3rd Jun 2005 13:05 UTC

"we don't really need java or .net anymore. There are easier alternatives"
Care to give an example? Please don't say Python, it's nice but they are not in the same league. Those are apples and oranges.

Whats makes you say that ? Nothing I can do in java cant be done in Python ( or many other languages for that matter. Haskell, Lisp, Ruby, ....... ?) J2EE ? Check out zope ? Clustering ? Maths? .... what ?



@Jupiter RE: Overall Cost
by Matt on Fri 3rd Jun 2005 13:49 UTC

I haven't worked in C#, and I don't think VB is in the same class as Java or C#.

That said, I've found that there is no noticeable difference in productivity when developing in Java/Swing or C++/Qt.

This is, of course, all subjective. It's based on perspective and depends on the developer's experience in the languages.

Last comment
by alpha99 on Fri 3rd Jun 2005 17:55 UTC

Thanks for your cooperation.
This thread has been closed because of unnecessary flamewar.
Please don't send any further comment.

@alpha99 RE: Last comment
by Matt on Fri 3rd Jun 2005 18:47 UTC

There has been a balance between flaming and reasonable discussion in this thread. Please don't attempt to silence people.

RE: Last comment
by alpha99 on Fri 3rd Jun 2005 20:18 UTC

I didn't believe that somebody could take it seriously.
Come on, use your sense of humour...