For a long time in SO and in other places Java has the reputation of being slow. From jokes to many comments in questions and answers, people still believe Java is slow based solely on experience with it in the 90s.

This is my issue: we have disproved (most) of the reasons that people believe Java is slow. Outside of small things, Java is pretty fast.

So why is it that people still refuse to believe Java is fast now? Is it part of their mindset that anything thats not C/C++ is slow? Is it because people don't check over time? Is it because people are just biased?

closed as not constructive by user8 Oct 5 '11 at 15:49

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

locked by Thomas Owens Mar 29 '14 at 11:26

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. See the help center for guidance on writing a good question.

Read more about locked posts here.

  • 10
    Umm, C# is fast too ;) – Evan Plaice Sep 11 '10 at 12:27
  • 12
    umm, that link doesnt disprove java being slow. – user2528 Sep 21 '10 at 2:47
  • 13
    My feeling is that Java is unresponsive rather than slow. – zneak Oct 2 '10 at 18:42
  • 23
    Bloated and horrible UI Libraries..? – dmp Oct 24 '10 at 14:00
  • 4
    Because JVM is not a part of the kernel. Oh, maybe some linux guys will add it in future. – Xiè Jìléi Mar 1 '11 at 11:20

18 Answers 18


It's the applications. As you note, we have proved, time and time again, that in contrived scenarios Java code can meet or even beat the performance of so-called "performant" languages like C, C++, Lisp, VB6, or JavaScript. And when presented with such evidence, most sane, open-minded opponents will hang their heads in shame and promise never again to spread such slander.

...but then, they fire up Eclipse, or NetBeans, or Guiffy, or enable the Java support in their browser, or try to run an app on their favorite feature phone. And they wait for it to become responsive...

...and wait...

...and wait...

...and wait...

...and wait...


...what did I promise never to do again? Sorry, must have dozed off...

  • 44
    Even the simplest Java GUI takes at least 1.5 seconds to start. That's not a tiny bit. – Peter Boughton Sep 2 '10 at 17:44
  • 32
    I never thought Javascript was considered a "performant" language. – zneak Oct 2 '10 at 18:38
  • 11
    +1 for mentioning IDEs. There's a huge difference between the responsiveness of Eclipse and an IDE like Visual Studio. – mellowsoon Oct 22 '10 at 17:50
  • 56
    I have issues with this. Firefox is written mainly in C++ and its slow. Does that mean C++ is slow? No, it means Firefox is slow. Saying that a language is slow because the largest program written in it is slow is stupid. – TheLQ Oct 23 '10 at 19:15
  • 13
    Jonas, using the simplest example I can find doesn't make me a bad programmer. If you've got a magic method that runs a Java GUI in less than a blink, go ahead and demonstrate it. – Peter Boughton Oct 25 '10 at 9:01

This question operates on false premises: where it counts, Java is still slow. Where it counts are computation-heavy algorithms on large data sets. Granted, these can be optimized, sometimes to be on par with C/C++ code, but only at the cost of modularity and genericity. Efficient C++ code can be designed to be generic and usable as a general-purpose library. Java code can’t. Just look at the heavily optimized Array.sort method, which uses different implementations for all fundamental types, and whose object variant is still much slower than C++’ generic sort because these objects have to dispatch equality comparisons dynamically.

Granted, just in time optimizations as performed by the HotSpot engine can actually predict the target of these virtual calls and attempt inlining. But this is still slower than the directly inlined call that is dispatched inside C++’ sort method.

A former colleague of mine has done comparative benchmarks of a problem on huge data sets (q-gram counting using dynamic shapes) with a templated C++ implementation and an object-oriented Java implementation. The Java code was orders of magnitude slower than the C++ code.

Of course this is comparing apples with oranges. But the point is that the Java implementation was the best possible implementation (in terms of performance, given the degree of modularity required for a library), and so was the C++ implementation.

Unfortunately, the benchmark data is not freely available but others have found similar numbers when comparing the overhead of runtime abstraction. For instance, Scott Meyers writes in Effective STL about the overhead of C’s generic qsort function:

C++’s sort virtually always embarrasses C’s qsort when it comes to speed. […] At runtime, sort makes inline calls to its comparison function … while qsort calls its comparison function through a pointer. […] In my tests on a vector of a million doubles, [sort] ran up to 670% faster …

  • 6
    To be fair, std::sort is one of the cases where it's difficult to do anything similar in other languages. But the vast majority of projects I've seen aren't writing std::sort -like code. They are writing (bad) Java code in C++, and complaining that they have problems. – Billy ONeal Oct 22 '10 at 16:23
  • 2
    Do you have any reports to backup your story that huge datasets are slow? I've heard people talking about doing operations 1-2 million entry Lists and it still being fast. And isn't messing with massive datasets in memory (usually stuff like that is in a DB) a bit of a niche field? – TheLQ Oct 23 '10 at 19:11
  • 8
    @TheLQ: the source is the SeqAn book by Gogol-Döring & Reinert. And about your counter-example: what operations? And what do they consider “fast”? Also, 1E6 entries isn’t all that large. ;-) And as to whether this is a niche field – certainly. But this is where you need fast computations. The point is whether Java is fast, not whether it’s “fast enough” for inexpensive operations. On a small enough data set, everything is fast enough. – Konrad Rudolph Oct 24 '10 at 10:51
  • 2
    there is no such thing as best possible implementation – jeremy-george Oct 5 '11 at 12:16
  • 3
    @fonzo There can be reasonable approximations. Scratch that, for a simple enough algorithm and a well-defined metric there can be a best possible implementation. This is the case here. The algorithm is simple, and there is a well-defined case for which was optimised: running time on a given input. – Konrad Rudolph Oct 5 '11 at 12:22

Because it is slow... in some applications. Desktop applications have to be responsive from the beginning and the startup overhead counts as slow.

On the other hand if you run a server it does not matter if there is some heating (JIT analysis and compilation) - you do it once in blue moon so most of the time it cannot be considered entirely slow.

  • Startup costs are a problem, but you can tweak it with some command line switches – TheLQ Sep 2 '10 at 11:02
  • 22
    How many users actually know about command line switches? – Walter Sep 2 '10 at 11:41
  • 17
    TheLQ, if you can provide a command line switch to remove the 1.5s startup delay for Swing/AWT, please go ahead and answer this: stackoverflow.com/questions/508723/… – Peter Boughton Sep 2 '10 at 17:47
  • 6
    And how do I tweak those command line switches to avoid by entire browser locking up for 5 seconds if I click on a link that contains a Java thing? That is the kind of thing that makes people call Java slow, and it doesn't matter that once loaded it actually runs rather quickly. – Roman Starkov Jan 22 '11 at 12:03

I'd say it's because when people first encountered it, it was slow. Based on that, they formed an impression of it. That impression is unlikely to change if they don't use it, and they don't use it because of that impression - it's a vicious cycle.

I must admit, I had the impression that Java was slow, and yes, that was from my previous exposure to it. I've now moved on to different languages and have had extremely limited exposure to Java since then. Consequently, my opinion hasn't changed much.

  • 3
    +1 -- I totally agree. I hated Java in its early days. The .NET Framework really helped the managed code cause: I liked C# and eventually I appreciated Java, too. – Wizard79 Sep 7 '10 at 10:28
  • 7
    It still takes over a second to run hello world. It's slow in terms of startup time. – intuited Sep 21 '10 at 5:19
  • @intuited Try building a server over C++/C# or whatever language you could find HECK try building it with C and THEN compare against JAVA. The thing with C is that it's fast if you're a "Ma, i wrote 10 lines C code that is faster then Java but you can't read it" type of guy. The moment when your C code grows, your speed slows ;) – AceofSpades Jan 3 '12 at 18:43

Because it takes a generation to change peoples perceptions about a product

It has nothing to do with how fast Java becomes. In people's minds Java is a const identifier associated with the word 'slow'. There's little, nothing you or Oracle can do about it.

Just be happy that Oracle hasn't destroyed the Java programming culture (yet) by doing anything rash or stupid. Like charging excessive licensing costs to use it. Or suing people based on software patents previously owned by Sun. ::sigh::

I hate to be the naysayer here but, unless Oracle and Google settle the Java struggle on nice terms, or Google is forced to purchase Java and makes it a 'proper' open source platform, Java is well on it's way to being the kid on the playground that has lice. IE, no one will want to touch it with a 20ft pole.

Note: Just to be clear, when I say generation I'm talking in people terms not computer terms. IE, until the people who hold that perception die of old age or replaced by a younger generation the perception will hold true. Think in terms of 5 decades not 5 years.

  • 2
    I think Google is using so much Java that them buying it is not an entirely unfeasible theory. I'd probably be happy with it. – Bart van Heukelom Sep 14 '10 at 22:15
  • 1
    @donroby: And who cares about these languages? In two decades Java will going to be a niche language. – aasc Oct 22 '10 at 22:44
  • 1
    @aasc - Java might be obsolete in two decades, but LISP isn't now and won't be then. – Don Roby Oct 23 '10 at 2:53
  • 2
    @aasc "Programmings languages usually don't live more than a generation" Good lord man, 1 million Delphi Developers that's Pascal, 5 Million Visual Basic Developers err... not to mention Perl, Lisp, Fortran, Cobol, C++ do you have any justification for that comment??? – Reallyethical Oct 24 '10 at 14:01
  • 2
    @Reallyethical Not in the mainstream. How many businesses depend on Lisp, Fortran, Cobol. With lisp, it's mostly trapped in academia and used as a model for features of other languages, few use it for actual production projects. Fortran has become a niche language for high performance mathematical modeling and Cobol only remains because the banking industry is to damn scared to change their old/dependable code to a new platform. C++ is the glaring exception because it is still very widely used and adopted today. – Evan Plaice Nov 11 '10 at 0:24

One reason is that people trust what others say instead of what they see.

According what I was told when I first started programming, Java is "slower" than C++, and reason why Java could be used is because it's "convenient and easier". It's very commonly believed that Java brings Safety and convenience, at the cost of performance. Even when later C# is invented people believe it's faster than Java because it's "native".

But the truth people see without sensing it, is that, eclipse, the IDE that's built with Java, is absolutely the FASTEST IDE in class. I've used nearly all main stream IDEs, those from MS and GNU, Borland..., eclipse is the absolute king, of IDEs, largely because of it's fast.

Another reason is its long start up time.

Java is not suitable for developing a tiny app that stay in system tray, consumes a little memory, popup a dialog reminding you to take a break; or a notepad that you use to open a text file, read it and close it. It should be used on something BIG, like a web server that's always there, make optimized use of you computing resource, respond to millions of requests every hour. Or an IDE like eclipse that manage thousands of workspace files. You don't know you Java app is fast until it has run for at least several hours, I believe.

  • 1
    Isee slowness all the time. – aasc Sep 18 '10 at 9:52
  • 28
    Eclipse fast? LMAO – finnw Sep 18 '10 at 15:48
  • 2
    @finnw - it is if you tune it. Out of the box and with all the plug ins, obviously it won't be fast. Obviously it can never be compared to vim or jedit or Notepad++, but these "fast" or "slow" arguments and statements are meaningless without a context. – luis.espinal Oct 13 '10 at 11:21
  • 2
    @luis you can however compare it to Delphi 7, which I don't believe is all that much simpler than Eclipse. And Delphi 7 is almost as fast as notepad. It's insane. – Roman Starkov Jan 22 '11 at 12:07
  • 4
    @finnw, for an IDE with zillions of plugin it's pretty fast :) – user1249 Feb 7 '11 at 19:24

@bigown "Why do people still say Java is slow?"

Because they are dumb. Because they have no work experience, but think they are the living incarnation of Dikjstra or the second coming of Linus Torvald, oh I dunno. The reasons for saying such a retarded thing are so many, but usually stupidity, mindless subjective fanboyism, and emotional attention-whoring seem to be behind them.

Let's disect this so that you can see the truth of what I've just said above:

First, what is slow, in what context, for what, under what conditions, with what engineering/scientific/business purpose (for saying tehe it sucks is not one of them.) Any person who says "X is slow" for any technology X, or simply "X is Y" where Y is some type of negative statement, without answering any of the questions above should be dismissed as a fool. Statements like that don't have a place in engineering. In politics and juvenile chat rooms maybe, but not on engineering.

Second, most of these misguided fools cry about Java being slow because ZOMG, their eclipse takes forever to fire up (gee, load the thing with all the plug ins, and guess what happens.) Most of these fools don't even know how to tune the jvm for eclipse to operate fast (or for any Java application for that matter). That is, they have no clue about performance tuning, which is a reality not just for Java, but for any non-trivial system, be it hardware or software. So right there, they disarm themselves for any technical validity in making such mindless statements.

Third, let's consider what the bulk of Java development is for: back end OLTP first and foremost; monitoring systems coming second. Either type of system is intended to run in clusters, and to run uninterrupted for weeks if not months. Does it really matter then that your little eclipse or toy app takes a minute or two to load when the purpose of REAL Java apps is to run for extended periods of time? Context, people, context.

Lastly, the backbone of OLTP on Google and Ebay run on Java. I would take that as a proof by contradiction that Java is not slow (at least for conditions that matter, not for little toy experiments, benchmarks and unverifiable annecdotal evidence done specifically for the purpose of saying "tehe X is slow, it sucks."

There is engineering, and there is fanboyism. Guess which category statements like those belong to?

  • 19
    If I have to tune my JVM to get Java to run acceptably fast, while I don't have to tune anything (except -O2) to get C++ to run acceptably fast, then Java is slow. – David Thornley Oct 22 '10 at 17:50
  • @David - Obvious statement. Anyone knows that Java is slower than C++. That does not logically follow that it is slow, however. Neither mentioning of gcc flags give the comment validity. It only states that it is slower than something else. A jaguar is slower than a cheetah. Does that make the former slow? Try some engineering objectivity and ask yourself this: can one logically declare, arbitrarily, that something is slow simply because it is slower than something else without mentioning a context of operations that defines what is fast enough and for what? Can you, logically? – luis.espinal Oct 22 '10 at 19:46
  • 5
    @luis.espinal: I was responding to your reason #2: that people say Java is slow because, in your opinion, they have failed to tune Java. Please also note my use of "acceptably fast". It would seem to me that something that is not "acceptably fast" is slow, and it would seem to me that something people routinely claim is slow is likely not acceptably fast. – David Thornley Oct 25 '10 at 13:50
  • 4
    @luis espinal You sound like Kant :) People here have made an implicit assumption that slow means slower in comparison to other practical, production-ready languages like C++. (Remember physics??) when you measure potential energy, you always measure it relative to some ground. Now going by your grammar, "X is dumb" is baseless. and "X is dumber than Knuth" does not make X an absolute dumb, as pretty much anyone can be X here. I agree calling a lang slow is not elite, but the people here who say that are not "dumb", but just happen to have made an agreed upon implicit assumption. – yati sagade Oct 5 '11 at 13:37
  • 1
    @luis hahaa.. nice observation. (My belief that you're a reincarnation of Kant has become even more solid ;) ) And such discussions end up in flame wars and unproductive keystrokes... According to me, one should always stick to what seems like the best tool to tackle the job at hand. Agree, Kant2 ? :P – yati sagade Oct 5 '11 at 14:07

Because it is, can we close this topic once and forever?

https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf [scroll down to tables, Java is 3.7-12.6 times slower than C++, research by Google employees]

P.S.: If it's not, name me at least one snappy Java app for a start, haven't seen one before.

  • 6
    Please summarize the contents of the PDF in your answer. – Adam Lear Oct 5 '11 at 15:06
  • 1
    This paper is very far from scientific research standards. It doesn't even compare exactly the same algorithms and optimizations in all the languages. "E. Java Tunings Jeremy Manson brought the performance of Java on par with the original C++ version. This version is kept in the java_pro directory. Note that Jeremy deliberately refused to optimize the code further, many of the C++ optimizations would apply to the Java version as well." jeremymanson.blogspot.com/2011/06/scala-java-shootout.html – Piotr Kolaczkowski Nov 4 '13 at 15:09

TMHO, this is because of the time needed to start the VM in the browser. If an application starts slowly, people will only remember that. Because, long starting time is really annoying. Really. One of my co-worker told me that he doesn't use Firefox because it is too slow. (?!?). But, Yes, Ok, on windows, Firefox takes a huge amount of time to show up. According to him, this app is slow, he made his mind about the general speed of it.

  • That's why Mozilla has been spending an awful lot of effort to get Firefox to start fast... – Spudd86 Sep 9 '10 at 18:12
  • 2
    It might turn out like Windows. Yes, after you log in you see the desktop really quickly, but then you still have to wait a while for it to get responsive. – Bart van Heukelom Sep 14 '10 at 22:16

Slow compared to what? I'm thinking of changing from ordinary Ruby to JRuby (Java based ruby) because I've heard it's faster.

  • 1
    JRuby is faster than Ruby, even in 1.9. However, the gap is closing. – Dan Rosenstark Oct 22 '10 at 16:07
  • 2
    +1 for pointing out a big problem. Though I'd say the OP is probably comparing to C# or C++. – Billy ONeal Oct 22 '10 at 16:13
  • @Yar, you are pointing out that CRuby is catching up with JRUby? – user1249 Feb 7 '11 at 19:25

Opinions are opinions, and facts are facts.

Here's a fact from the Google Code Jam, which arguably challenges programmers to solve tough computing problems in a short period of time, meaning that performance of the language they use play an important role:

During the past editions (2009, 2010, 2011), around 75% of the programmers who arrived at the final rounds were using C++, as opposed to around 15% using Java.

Source -> http://www.go-hero.net/jam/

  • 3
    That only really proves that Java can make it to the top of a speed-focused competition but most people choose C++. – Adam Lear Oct 5 '11 at 13:27
  • 3
    "solve tough computing problems in a short period of time" -- what, the time it takes to write the code, or the time it takes to run the code? Regardless, your fact is that -- a fact -- what does that have to do with the question? Are you drawing a conclusion from your fact? – occulus Jan 8 '12 at 19:36
  • which may just be because 75% of people writing programs that make the final rounds think Java is slow without ever having tested it and therefore use C++ instead because they believe it is fast without ever having tested it. – jwenting Apr 10 '13 at 6:15

Circa 1997 I used a HP Vectra VE (200 MHz) and Windows 95. Most applications ran very fast on this, but then I tried a few applications written in Java (IDEs, if I recall correctly). They were very slow, at least the GUI parts of them. They took long time to start, and the GUI elements (e.g. menus) were not very responsive -- there were delays in the visual feedback. Also, since Java GUI applications had (has) a rather distinctive look, I learned to associate this look (and Java) with poor performance.

  • 2
    I remember 1997! Great year, though a lot of the wines -- and observations -- from 1997 are no longer usable. – Dan Rosenstark Oct 22 '10 at 16:08
  • 1
    I remember 1997 well too. Windows crashed all the time and required rebooting when installing a driver. Piece of junk. – user1249 Jul 15 '11 at 18:37
  • And you didn't change your opinion of 1997? Did you notice that 2011 is totally different than 1997? – Jesper Jul 15 '11 at 21:21
  • 5
    My analysis from this data would be that 1997 sucked. – JasonTrue Sep 26 '11 at 5:20

It depends what you means as being slow.

First of all, java as made many progress recently and is very fast in most cases. But :

  • Java is slow at startup, because you have to load the JVM before doing anything.
  • Some security feature can kill performances in some cases. Bound check with random access is an exemple.
  • Make something really fast in java require to work against the JVM (to take advantage of cache line for exemple).
  • The lack of metaprogramming imply a penality at run time with each abstraction, thus performance come to the cost of design in many cases.
  • Java can hardly ensure real time constraint - by design - and this could be considered as « being slow » by some people.

By the way, java is, in some cases, faster than vanilla C/C++. But thoses languages gives you the tools to tweak them.

Java is a programming language aimed at productivity. Now it is fast enough for most applications, but isn't enough for some others.

In general, Java's slowness is an overused argument because it's irrevelant in most cases.


Simple, canonical Java code tends to be on par with or faster than simple, canonical C/C++/D code. Simple, canonical code tends to perform a lot of memory allocations unnecessarily, not be particularly tuned to any CPU architecture, not have tons of low level optimizations done to it, etc. Java's HotSpot GC is nothing short of amazing, and the VM optimizations tend to be better than what a static compiler could do.

On the other hand, if you really need performance and are willing to hand-tune stuff to get it, C/C++/D provides many more opportunities for this. You can't use inline assembler in Java. You can't use dirty type punning tricks to treat floating point numbers as arrays of bits. You can't use custom memory management schemes that may be faster than the GC for your specific use case. You can't allocate nearly as much on the stack in Java as in C/C++/D. In Java the only way to get anything roughly equivalent to higher order functions is with interfaces and runtime binding. In D and (I think, correct me if I'm wrong) C++, you can pass functions to templates, allowing for binding to happen at compile time without loss of flexibility.

  • 5
    Can you source those comments? I.e. where are any benchmarks showing canonical code in each language showing Java being faster? – Billy ONeal Oct 22 '10 at 16:11

Another point for "slowness" of Java is the 64bit runtime.

I've heard some people complain that Java is very slow for them on 64bit computers. As it turns out, 64bit Java runtime uses server JVM which compiles whole program before starting.

HERE is explanation why 64bit VM starts slower.

For example on Windows:

C:\> java -version  
java version "1.6.0_21"  
Java(TM) SE Runtime Environment (build 1.6.0_21-b06)  
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode)  
  • 3
    The server VM is slower to start-up but it does not natively compile the whole program before starting. It couldn't, classes are loaded lazily and potentially via reflection, so there is no way to know in advance what bytecode would need to be natively compiled. – Dan Dyer Sep 11 '10 at 13:11
  • @Dan Dyer After some research, looks like I misunderstood what I read. I meant that Server VM does more optimization while client is optimized for quick start and smaller memory use. – AndrejaKo Sep 11 '10 at 14:42
  • server VM is optimised for long running processes, therefore preloads more which leads to longer startup times and tends to use more RAM. Client VM is optimised for lower footprint and startup times, but may have lower runtime performance. – jwenting Apr 10 '13 at 6:18

The performance of Java is very subjective however, the perception of why Java is slow is largely for reasons that others have noted: most peoples perception of something is colored by their earlier experience with it and Java hasn't always been a well optimized language under the hood. Likewise, vanilla Eclipse isn't exactly a fast IDE to work with and pales in terms of responsiveness when compared to an IDE like Visual Studio.

That said though, outside of the UI issues that Java has at start-up, it is fast enough for most applications. If you search you can find articles that compare it with other languages and most of the results presented put it into the range where it will only be an issue when you are dealing with major data sets.

In the bioinformatics field it is used quite a bit because it is well supported and there is already an installation base for, one of the advantages that Java has is that you can do some fairly rapid development with it that you can't do with C. If you look at the languages used for bioinformatics (I personally use R, Python, and Java regularly) you will note that none of them is exactly the fastest and it isn't unusual for the data sets in bioinformatics to run into the 100's of gigabytes of information. At the end of the day, human time is still more valuable and while the speed differences are noticeable, the size of the data sets tend to be large enough that they run overnight anyway.

If it were easier to write a snappy UI in Java it is quite like that the speed perception would fall off the radar as most people do not push languages enough that speed is really an issue on a daily basis.


To throw in a worthless coin, I find that Java webapps generally have long startup and response times, where it seems to me that Python or Ruby would have done better.

I do use Eclipse for most of my programming, and I must say that Java is just as fast as anything else, if not faster running locally and "standalone".

  • 1
    On the web, start up time isn't as important. It's resource consumption and scalability that matter most. – Berin Loritsch Nov 24 '10 at 18:35

I would say Java is infinitely slow, not just sluggish, because it fails to solve simple problems which are easy in real high level languages.

Let me give a simple example. There is a simple optimisation which applies when mapping a list twice, called deforestation: here is the rule for it written in my language Felix:

reduce deforest[T,U,V] (f:T->U, g:U->V, x:list[T]): 
  map g (map f x) => map (compose(g,f)) x

which says: instead of mapping list x with f, then mapping it again with g, requiring two list traversals and making a garbage temporary list, just map the list with the composition of the functions.

This is a high level optimisation vastly more significant than low level performance of the Java JVM. The specification I gave above isn't just pretty syntax, this is an instruction written by the user telling the Felix compiler how to perform an optimisation.

Please show me how to do this kind of thing in Java. No? Then Java is slow. Very slow. [Haskell can do this one automatically I believe].

And before you say "but Java is an OO language, this kind of optimisation doesn't apply" .. well that's exactly my point. Java sucks, and being OO is one of the main reasons.

JIT optimisation can never come even close to competing with the kinds of optimisations a decent compiler can do.

  • 3
    I have absolutely no idea what your code does there. And if you say that an entire language is slow just because it can't do one small optimization then there are other problems here – TheLQ Jan 22 '11 at 16:34
  • 7
    -1 digging up an old question and bashing a language with very lame arguments. Tell me if you want a detailed writeup about what's wrong with your reasoning. For starters, naming OO as the main reason it sucks is not very objective and the de facto performance of a JVM+JIT is very good, even if there are optimizations left out. – user7043 Jan 22 '11 at 17:11
  • 8
    Haskell is infinitely slower than Java for our main platform, because it is not ported to said platform, so Haskell sucks... – user1249 Feb 7 '11 at 19:32
  • 1
    @Thorbjørn Ravn Andersen I really wish I could give you a +1 for that observation. – Patrick Hughes Jul 16 '11 at 3:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.