Clearly I made a slight error in wording that one:) The dna evolves as a group, so organisms evolve as a group.
I kind of see what you mean. I may have been imprecise as well! I know that single indivuals can't evolve, but evolutionary selection happens at the level of the individual - ideas of group or species selection (if that is what you are implying) is pretty much out of date.
It is very easy. If you find a fossil with 'modern' features (such as that of an ape) in rocks that are dated as, say, 100 million years ago, then evolution is instantly falsified.
By the way, if you would like to read detailed refutations of Buchanan's points, let me know and I will provide them. I do think it is unfair for you to have been modded 'Troll', as you are simply expressing a commonly held belief.
This illustrates the evolution of whales from land mammals.
By the way, has anyone "invested" in evolution asked themselves if they could possibly be wrong?
All the time.
This is why more than one dating method is often used to check the age of fossils (radioactive decay + position in rocks). There are frequent controversies about how different animal groups are related (such as dinosaurs and birds).
That's bullshit. The existence of species is an underlying tenant of evolution, since evolution describes how species adapt and change over time. If the word species is not well defined and meaningful, the theory of evolution can not be either.
No. Evolution is about how organisms adapt and change over time.
Shouldn't they be allowed to teach it, so long as they teach all of the current theories?
No, because it is not a scientific theory. It is not testable or disprovable. Because our knowledge of nature and life and evolution is likely to remain incomplete (there will probably always be things we don't understand), the 'Intelligent Design' idea can always be brought in as an arbitrary 'explanation' for anything.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
Okay, name ONE major Java application that you are proud of (as a Java fan).
Oxygen - the XML/XSLT processor with GUI.
I know two: Eclipse & Netbeans. Both sucks at speed/memory footprint compared to Emacs (I agree they have other very nice features and can be useful for a lot of things)
I simply disagree that they suck relative to emacs. I find NetBeans very responsive.
Both easily run out of memory when compile a big project.
I have never found this, even on projects with several hundred thousands lines of code.
And I do not agree that sizeof(Object) should not bother developers: actually it matters a lot in many projects. If you don't need locking, don't need virtual tables, don't need garbage collection -- you don't want to pay for all this stuff.
You don't pay for it. Most of this is automatically optimised out by the Hotspot engine even in J2ME implementations.
Name one Java implementation where I can have a vector with a billion of elements.
Java 5.0 64-bit.
With C (and to some extent with C++) I can predict cache footprint of a function, can ask questions about page misses, memory locality, can rewrite code to use SSE2 intinsics, etc. With Java such questions have no meaning as you have a very little control over it!
True. But this is where C or C++ excels - it is what they were designed for. It is not functionality needed by general purpose code.
Yes, the language itself is nice, it's just impossible to implement it efficiently.
Contrary to the evidence....
And about Google searches -- not surprisingly they write software in C/C++ and don't run on HPUX (I think).
Google make extensive use of Java.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
How can you sit there with a straight face and tell me that Interpreted code startup isn't slow?
Because it isn't, and even a few seconds of thought would reveal. The fact that interpreted languages like PHP and PERL give good response times show that it isn't.
You take interpreted code that runs at roughly 1/10th the speed of native code, THEN (because that's not fast enough) you fire off a CPU intensive compile in the background sucking up even more CPU cycles, and this IMPROVES performance HOW?
Because the compile isn't CPU intensive. It is a low-priority background thread (see below).
So, if the backround JIT is taking 50% of the CPU time, and the interpreted code is running at 1/10th native speed, that means that the code is running at 5% of what a native program would be running (assuming there aren't even any other programs running).
Why not actually check some facts? Who says that the background JIT is taking 50% of the CPU time? Of course it isn't! It is a low-priority thread, and it is even possible to fine-tune the proportion of CPU time given to an application that this JIT takes.
No, of course, now I understand why startup times are blistering fast.
This post shows you don't understand much about this technology.
Re:Why Java still isn't faster than C++
on
Java Is So 90s
·
· Score: 1
This is an interesting comment, but in my opinion all you are doing is describing a series of reasons why you think that Java should not be able to match C++ speed.
But this is irrelevant. It does! Here is an example:
Just to correct one misunderstanding - Hotspot is not a typical optimiser, C++ style. It does not significantly impact performance, as it is not a full profiler - it detects 'hotspots' - performance critical areas and concentrates on them - it does not profile the entire application in detail (which would certainly impact performance).
The reason why this sort of thing is not used much elsewhere is that it is extremely hard. It is based on technology developed from the Self language, and has involved years of research. Also, until now, there has never been much of a need. Pre-compilation has been good enough for languages like C++. However, with Java, pre-compilation is often problematic.
The widespread use of Java in whatever industry you are is not likely to happen no matter what the performance, as areas of the IT industry are very conservative - for example, much game development is still in assembler, and COBOL is far from dead.
Guess what? I also write high-performance code - numerical simulations of molecular interactions. Java is the first language that looks like it may at least start to replace Fortran in this area.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
Bollocks. This run-time profiling is a total myth. Java still badly loses benchmarks where, if your claims were true, it should win handily.
Fortunately, most people have a more realistic vision of Java. Namely that every Java app they've ever tried blows... drinks memory like water (and never gives it back) and slows their machine to a crawl while being spectacularly ugly. (and yes, this is with Java 1.5 *and* with the Mustang dev versions).
Fortunately most people have a more realistic vision of Java that you, which is why it is so successful. It is your opinion against the majority.
By the way - Java *does* give memory back. You need to research more.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
Oh for goodness sake!
Stop saying 'bullshit' and actually check some facts. It isn't hard you know!
Check the VM parameters for differences between Java 1.4 and 1.5. There are substantial Java vs. C++ benchmarks out there a no amount of saying 'bullshit' will invalidate them, no matter how much you may want this to.
As for Swing performance, you are showing your ignorance yet again. Linux is not a 3rd class citizen, as OpenGL acceleration is available.
Regarding Swing on MacOS and Windows Vista, you can say 'utter bullshit' if you like, but guess what? Mustang is beta! Sun and Microsoft are still working on things, which not surprising as Windows Vista is not finished yet! If you don't believe that Swing on MacOS/X is not totally compatible, perhaps you might want to actually check with Apple? They happen to disagree with you.
And why should Sun give up on Swing when it has recently become the most popular GUI for client-side development?
Stop ranting and try and actually research some facts.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
Oh, come on! What you say may be true on an average desktop with the usual 2% cpu load, but if you have all your CPUs 100% busy where do you get any time for "background"?
Java uses real OS threads. The scheduler will ensure that these low priority threads are activated. In fact, there is a JVM switch to ensure that such threads get the right proportion of CPU time.
Next, ever tried any Java IDE?
All the time.
NetBeans,Eclipse -- try that against Xemacs! It's only 100 times more responsive and doesn't crash with "NULL pointer exception" while collecting compilation output.
What are you talking about? I have never seen that happen.
The problem with Java is that you pay A LOT for stuff you don't use.
Like what?
How may bytes is Object on 64 bit platform?
Depends entirely on the Java implementation. This is no concern for the developer.
And it's not going away with a better compiler, because language itself guarantees certain things (that are expensive).
No, they are not expensive. Things like range checking and security are dynamically analysed at run time and are often optimised out.
on Java, if I understand correctly, you should set beforehand how much you will allow it to use (and the one I tried didn't allow for more than 2GB on 32 bit linux).
This is an implementation dependent thing, and not specified in the language. For example, HP's Java supports up to 3.5GB on 32-bit HP/UX.
Can I set the limit to 1TB on 64bit?
Depends entirely on the implementation. This is not specified in the language.
on Java I'll need to do tricks to clean the memory or it'll eat everything.
You may say this, but no-one else seems to need to do this. Major Java app servers run for very long periods without having to do such tricks.
Also, please disclose which airlines use Java for realtime purposes!
Boeing. They have real-time systems that they demonstrated at JavaOne this year.
The real question is why you are asking these things. This information is all available in the public domain, and no further away than a Google search.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
One other thing. If you've got a CPU-intensive task, why not write that in C/C++ and import it to Java? You can do that, you know. The interop is pretty clean. You get the best of both worlds.
This simply isn't necessary. There is little evidence that C/C++ is faster at such things.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
Actually, that is understandable. I have found even relatively bare Windows XP and Linux with Gnome/KDE to be less-than-usable on a machine with, say, 128MB. I would expect significant delays even with C++/KDE apps on a machine with that spec.
The key thing, in my view, is swap space. A machine with 384MB and, say, 512MB of swap with that spec should give a reasonable performance. The delay in the GUI should be there at the start, but disappear as the JIT starts to work.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 2, Informative
Even though i'm more of a pythonista, don't forget Ruby here, it got a LOT of momentum fropm Ruby on Rails and the language itself deserves fame. It's well built, flexible, stable, and clearly the best competitor of Python.
Even though I am mainly a Java developer, I agree that the Ruby language deserves a lot of success. However, I really don't think that there is a lot of momentum around Ruby on Rails. There is a lot of press, and a lot of discussion, but there is little evidence that this has actually resulted in significantly increased use.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 0
Well, good for you. I imagine you have a better machine.
So what is the spec of your machine? What Java apps are you running? Let's actually compare real apps and hardware.
Re:Java use slipping? You have to be joking
on
Java Is So 90s
·
· Score: 1
That's more of a measure of Java's acceptance in the open-source world.
True, but it is surely also a sample of wider interest.
It doesn't surprise me that Java's mindhshare among OSS developers is showing an uptick, because gcj is finally becoming viable.
This could be the case, but I doubt it. Java has been growing in use on Sourceforce for some time, and gcj is still (in my view) far from being an adequate Java implementation. The most popular SourceForge Java project is Azureus, and the developers recommend Java 1.5, which is far from what gjc can provide.
Until recently, there just wasn't any free-as-in-speech implementation of Java. And even ignoring ideology, the non-free licensing made it a major PITA to install Java on FreeBSD, for example.
Good point.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
1997: Java 1.1 VMs are vastly better than previous releases, with more optimisations and better garbage collection. They can routinely equal C++ in terms of performance....... 2009: Java 7.0 VMs are vastly better than previous releases, with more optimisations and better garbage collection. They can routinely equal C++ in terms of performance...
I suggest you actually look at the history of Java performance before posting a rant like this. It does not help your argument, and how it was rated 'informative' is beyond me.
There was no doubt that early versions of Java were slow, and came nowhere near C++ performance. Before version 1.2 of the JVM Java would only reach 10%-30% of C++ speed. This is typical of low-quality JIT compilers, and many other cross-platform languages (such as Smalltalk) would reach similar speeds.
Then IBM got in on the act, and started to produce really high-quality JITs for the JVMs. Even so, programs would only reach around 50-70% of C++ speeds typically. Sun's VMs were usually worse.
The big speedup came with Hotspot in Java 1.4. This was not a traditional JIT, but a background compiler and optimiser. This could produce far better machine code than JIT as it could take the time to perform extensive optimisations. This is when Java really started to hit C++ speed. In theory this sort of optimisation (where the machine code is continally re-profiled and adapted as a program runs) could produce faster code than a single pre-execution compilation as with C and C++.
In reality, some Java implementations did reach C++ speeds even in 1997! However, these were very specialised VMs or Java compilers that would only provide such performance on specific platforms. The key to Java's current speed is general approaches that can give true cross-platform high performance.
Oh you mean like Enterprise Services that unlike Java does not require buying an app server (and doesn't suck like EJBs do) ?
You don't have to buy an app server. There are very high quality free ones, such as JBoss and Geronimo. As for the saying that EJBs 'suck' - I have no idea what this means, as thousands of commercial companies use them very effectively to provide high-performance and robust services. E-Bay is a good example. They may be a pain to program (although this changes with EJB 3.0), but there is no denying that they are effective where required.
I must've been sick the day they covered that in buzzword class. WTF is an "enterprise object"? Is it like a paradigm synergizer?
It is an object that can provide a transactionally safe, clustered service - something that won't fall over leaving a mess and can be run in parallel on different servers, giving increased performance and security, without extra effort from the programmer. Examples are J2EE Session Beans and Entity Beans.
Re:I guess it depends on where you came from
on
Java Is So 90s
·
· Score: 1
Really, who uses the hardware-agnosticism of Java anyways?
It is more like 'who doesn't'.
One of the most common ways to do Java commercial development is to use IDEs under Windows and then the client can choose the deployment platform - Linux/Unix/Windows.
Re:The real 90s versus outdated 00s software
on
Java Is So 90s
·
· Score: 1
I can't help feeling that a lot of the Java bashing is because the first couple of versions (e.g. pre 1.2) were pretty poor. I, personally, don't think the language started getting good until 1.3. 5.0 is fantastic though, it's really made me believe that they can keep growing Java.
I do find the typical/. attitude to Java puzzling, as I would have thought that those enthusiastic about IT would be regularly re-visting different technologies to see if they had changed. An outdated view of Java based on 1.2 or earlier shows a seriously outdated knowledge of IT.
And, I agree, Java took a long time to become acceptable. Early versions were so slow and buggy I was amazed that anyone was using them.
Slashdot Mirror
Clearly I made a slight error in wording that one :) The dna evolves as a group, so organisms evolve as a group.
I kind of see what you mean. I may have been imprecise as well! I know that single indivuals can't evolve, but evolutionary selection happens at the level of the individual - ideas of group or species selection (if that is what you are implying) is pretty much out of date.
Well... maybe, but while clearly the DNA is evolving, the organism evolves as a result of that.
Exactly. Change starts at the level of the DNA/Organism, not the species.
Almost every mutation in science degenerates a particular species, not improve it.
The key thing here is the word 'almost'. That is what makes evolution feasible.
How would you falsify evolution?
It is very easy. If you find a fossil with 'modern' features (such as that of an ape) in rocks that are dated as, say, 100 million years ago, then evolution is instantly falsified.
No, it really isn't. One organism cannot evolve. It is about groups of organisms, loosely termed "species"
Actually, it isn't even about that. The only thing that really can evolve is DNA.
By the way, if you would like to read detailed refutations of Buchanan's points, let me know and I will provide them. I do think it is unfair for you to have been modded 'Troll', as you are simply expressing a commonly held belief.
I'd like to see at least two intermediate fossils, please.
Here are many:
http://www.origins.tv/darwin/landtosea.htm#whales
This illustrates the evolution of whales from land mammals.
By the way, has anyone "invested" in evolution asked themselves if they could possibly be wrong?
All the time.
This is why more than one dating method is often used to check the age of fossils (radioactive decay + position in rocks). There are frequent controversies about how different animal groups are related (such as dinosaurs and birds).
Questioning is at the core of science.
That's bullshit. The existence of species is an underlying tenant of evolution, since evolution describes how species adapt and change over time. If the word species is not well defined and meaningful, the theory of evolution can not be either.
No. Evolution is about how organisms adapt and change over time.
Shouldn't they be allowed to teach it, so long as they teach all of the current theories?
No, because it is not a scientific theory. It is not testable or disprovable. Because our knowledge of nature and life and evolution is likely to remain incomplete (there will probably always be things we don't understand), the 'Intelligent Design' idea can always be brought in as an arbitrary 'explanation' for anything.
Okay, name ONE major Java application that you are proud of (as a Java fan).
Oxygen - the XML/XSLT processor with GUI.
I know two: Eclipse & Netbeans. Both sucks at speed/memory footprint compared to Emacs (I agree they have other very nice features and can be useful for a lot of things)
I simply disagree that they suck relative to emacs. I find NetBeans very responsive.
Both easily run out of memory when compile a big project.
I have never found this, even on projects with several hundred thousands lines of code.
And I do not agree that sizeof(Object) should not bother developers: actually it matters a lot in many projects. If you don't need locking, don't need virtual tables, don't need garbage collection -- you don't want to pay for all this stuff.
You don't pay for it. Most of this is automatically optimised out by the Hotspot engine even in J2ME implementations.
Name one Java implementation where I can have a vector with a billion of elements.
Java 5.0 64-bit.
With C (and to some extent with C++) I can predict cache footprint of a function, can ask questions about page misses, memory locality, can rewrite code to use SSE2 intinsics, etc. With Java such questions have no meaning as you have a very little control over it!
True. But this is where C or C++ excels - it is what they were designed for. It is not functionality needed by general purpose code.
Yes, the language itself is nice, it's just impossible to implement it efficiently.
Contrary to the evidence....
And about Google searches -- not surprisingly they write software in C/C++ and don't run on HPUX (I think).
Google make extensive use of Java.
How can you sit there with a straight face and tell me that Interpreted code startup isn't slow?
Because it isn't, and even a few seconds of thought would reveal. The fact that interpreted languages like PHP and PERL give good response times show that it isn't.
You take interpreted code that runs at roughly 1/10th the speed of native code, THEN (because that's not fast enough) you fire off a CPU intensive compile in the background sucking up even more CPU cycles, and this IMPROVES performance HOW?
Because the compile isn't CPU intensive. It is a low-priority background thread (see below).
So, if the backround JIT is taking 50% of the CPU time, and the interpreted code is running at 1/10th native speed, that means that the code is running at 5% of what a native program would be running (assuming there aren't even any other programs running).
Why not actually check some facts? Who says that the background JIT is taking 50% of the CPU time? Of course it isn't! It is a low-priority thread, and it is even possible to fine-tune the proportion of CPU time given to an application that this JIT takes.
No, of course, now I understand why startup times are blistering fast.
This post shows you don't understand much about this technology.
This is an interesting comment, but in my opinion all you are doing is describing a series of reasons why you think that Java should not be able to match C++ speed.
But this is irrelevant. It does! Here is an example:
http://www.kano.net/javabench/
Just to correct one misunderstanding - Hotspot is not a typical optimiser, C++ style. It does not significantly impact performance, as it is not a full profiler - it detects 'hotspots' - performance critical areas and concentrates on them - it does not profile the entire application in detail (which would certainly impact performance).
The reason why this sort of thing is not used much elsewhere is that it is extremely hard. It is based on technology developed from the Self language, and has involved years of research. Also, until now, there has never been much of a need. Pre-compilation has been good enough for languages like C++. However, with Java, pre-compilation is often problematic.
The widespread use of Java in whatever industry you are is not likely to happen no matter what the performance, as areas of the IT industry are very conservative - for example, much game development is still in assembler, and COBOL is far from dead.
Guess what? I also write high-performance code - numerical simulations of molecular interactions. Java is the first language that looks like it may at least start to replace Fortran in this area.
Bollocks. This run-time profiling is a total myth. Java still badly loses benchmarks where, if your claims were true, it should win handily.
That is a broad claim, and is utter nonsense.
Java simply doesn't badly lose benchmarks:
http://www.kano.net/javabench/
I bet you were wanking while you wrote that.
Way to go to get modded up.
Fortunately, most people have a more realistic vision of Java. Namely that every Java app they've ever tried blows... drinks memory like water (and never gives it back) and slows their machine to a crawl while being spectacularly ugly. (and yes, this is with Java 1.5 *and* with the Mustang dev versions).
Fortunately most people have a more realistic vision of Java that you, which is why it is so successful. It is your opinion against the majority.
By the way - Java *does* give memory back. You need to research more.
Oh for goodness sake!
Stop saying 'bullshit' and actually check some facts. It isn't hard you know!
Check the VM parameters for differences between Java 1.4 and 1.5. There are substantial Java vs. C++ benchmarks out there a no amount of saying 'bullshit' will invalidate them, no matter how much you may want this to.
As for Swing performance, you are showing your ignorance yet again. Linux is not a 3rd class citizen, as OpenGL acceleration is available.
Regarding Swing on MacOS and Windows Vista, you can say 'utter bullshit' if you like, but guess what? Mustang is beta! Sun and Microsoft are still working on things, which not surprising as Windows Vista is not finished yet! If you don't believe that Swing on MacOS/X is not totally compatible, perhaps you might want to actually check with Apple? They happen to disagree with you.
And why should Sun give up on Swing when it has recently become the most popular GUI for client-side development?
Stop ranting and try and actually research some facts.
Oh, come on! What you say may be true on an average desktop with the usual 2% cpu load, but if you have all your CPUs 100% busy where do you get any time for "background"?
Java uses real OS threads. The scheduler will ensure that these low priority threads are activated. In fact, there is a JVM switch to ensure that such threads get the right proportion of CPU time.
Next, ever tried any Java IDE?
All the time.
NetBeans,Eclipse -- try that against Xemacs! It's only 100 times more responsive and doesn't crash with "NULL pointer exception" while collecting compilation output.
What are you talking about? I have never seen that happen.
The problem with Java is that you pay A LOT for stuff you don't use.
Like what?
How may bytes is Object on 64 bit platform?
Depends entirely on the Java implementation. This is no concern for the developer.
And it's not going away with a better compiler, because language itself guarantees certain things (that are expensive).
No, they are not expensive. Things like range checking and security are dynamically analysed at run time and are often optimised out.
on Java, if I understand correctly, you should set beforehand how much you will allow it to use (and the one I tried didn't allow for more than 2GB on 32 bit linux).
This is an implementation dependent thing, and not specified in the language. For example, HP's Java supports up to 3.5GB on 32-bit HP/UX.
Can I set the limit to 1TB on 64bit?
Depends entirely on the implementation. This is not specified in the language.
on Java I'll need to do tricks to clean the memory or it'll eat everything.
You may say this, but no-one else seems to need to do this. Major Java app servers run for very long periods without having to do such tricks.
Also, please disclose which airlines use Java for realtime purposes!
Boeing. They have real-time systems that they demonstrated at JavaOne this year.
The real question is why you are asking these things. This information is all available in the public domain, and no further away than a Google search.
One other thing. If you've got a CPU-intensive task, why not write that in C/C++ and import it to Java? You can do that, you know. The interop is pretty clean. You get the best of both worlds.
This simply isn't necessary. There is little evidence that C/C++ is faster at such things.
Actually, that is understandable. I have found even relatively bare Windows XP and Linux with Gnome/KDE to be less-than-usable on a machine with, say, 128MB. I would expect significant delays even with C++/KDE apps on a machine with that spec.
The key thing, in my view, is swap space. A machine with 384MB and, say, 512MB of swap with that spec should give a reasonable performance. The delay in the GUI should be there at the start, but disappear as the JIT starts to work.
Even though i'm more of a pythonista, don't forget Ruby here, it got a LOT of momentum fropm Ruby on Rails and the language itself deserves fame. It's well built, flexible, stable, and clearly the best competitor of Python.
Even though I am mainly a Java developer, I agree that the Ruby language deserves a lot of success. However, I really don't think that there is a lot of momentum around Ruby on Rails. There is a lot of press, and a lot of discussion, but there is little evidence that this has actually resulted in significantly increased use.
Well, good for you. I imagine you have a better machine.
So what is the spec of your machine? What Java apps are you running? Let's actually compare real apps and hardware.
That's more of a measure of Java's acceptance in the open-source world.
True, but it is surely also a sample of wider interest.
It doesn't surprise me that Java's mindhshare among OSS developers is showing an uptick, because gcj is finally becoming viable.
This could be the case, but I doubt it. Java has been growing in use on Sourceforce for some time, and gcj is still (in my view) far from being an adequate Java implementation. The most popular SourceForge Java project is Azureus, and the developers recommend Java 1.5, which is far from what gjc can provide.
Until recently, there just wasn't any free-as-in-speech implementation of Java. And even ignoring ideology, the non-free licensing made it a major PITA to install Java on FreeBSD, for example.
Good point.
1997: Java 1.1 VMs are vastly better than previous releases, with more optimisations and better garbage collection. They can routinely equal C++ in terms of performance... ....
2009: Java 7.0 VMs are vastly better than previous releases, with more optimisations and better garbage collection. They can routinely equal C++ in terms of performance...
I suggest you actually look at the history of Java performance before posting a rant like this. It does not help your argument, and how it was rated 'informative' is beyond me.
There was no doubt that early versions of Java were slow, and came nowhere near C++ performance. Before version 1.2 of the JVM Java would only reach 10%-30% of C++ speed. This is typical of low-quality JIT compilers, and many other cross-platform languages (such as Smalltalk) would reach similar speeds.
Then IBM got in on the act, and started to produce really high-quality JITs for the JVMs. Even so, programs would only reach around 50-70% of C++ speeds typically. Sun's VMs were usually worse.
The big speedup came with Hotspot in Java 1.4. This was not a traditional JIT, but a background compiler and optimiser. This could produce far better machine code than JIT as it could take the time to perform extensive optimisations. This is when Java really started to hit C++ speed. In theory this sort of optimisation (where the machine code is continally re-profiled and adapted as a program runs) could produce faster code than a single pre-execution compilation as with C and C++.
In reality, some Java implementations did reach C++ speeds even in 1997! However, these were very specialised VMs or Java compilers that would only provide such performance on specific platforms. The key to Java's current speed is general approaches that can give true cross-platform high performance.
The moral: don't rant - research.
Oh you mean like Enterprise Services that unlike Java does not require buying an app server (and doesn't suck like EJBs do) ?
You don't have to buy an app server. There are very high quality free ones, such as JBoss and Geronimo. As for the saying that EJBs 'suck' - I have no idea what this means, as thousands of commercial companies use them very effectively to provide high-performance and robust services. E-Bay is a good example. They may be a pain to program (although this changes with EJB 3.0), but there is no denying that they are effective where required.
I must've been sick the day they covered that in buzzword class. WTF is an "enterprise object"? Is it like a paradigm synergizer?
It is an object that can provide a transactionally safe, clustered service - something that won't fall over leaving a mess and can be run in parallel on different servers, giving increased performance and security, without extra effort from the programmer. Examples are J2EE Session Beans and Entity Beans.
Really, who uses the hardware-agnosticism of Java anyways?
It is more like 'who doesn't'.
One of the most common ways to do Java commercial development is to use IDEs under Windows and then the client can choose the deployment platform - Linux/Unix/Windows.
I can't help feeling that a lot of the Java bashing is because the first couple of versions (e.g. pre 1.2) were pretty poor. I, personally, don't think the language started getting good until 1.3. 5.0 is fantastic though, it's really made me believe that they can keep growing Java.
/. attitude to Java puzzling, as I would have thought that those enthusiastic about IT would be regularly re-visting different technologies to see if they had changed. An outdated view of Java based on 1.2 or earlier shows a seriously outdated knowledge of IT.
I do find the typical
And, I agree, Java took a long time to become acceptable. Early versions were so slow and buggy I was amazed that anyone was using them.
Things have changed.