No need to add more information; if you contact me privately (jdennett at acm.org will do) I'll happily review this for you and update it to conform to the C++ Standard where it doesn't already, and maybe offer a few other tips.
If you'd like a chance to make work for me, feel free to read the comp.std.c++ FAQ at http://www.jamesd.demon.co.uk/csc/faq.html and let me know what deficiencies you find there.
The rest of the card doesn't look much better. The reserved words are listed and the card notes that they can't be used as identifiers, but it doesn't mention that there are other reserved identifiers.
The description of while(x) says that x must be an expression, but for a long long time C++ has allowed a variable declaration at this point, and such use is idiomatic.
The example of operator overloading is far from ideal: the argument is idiomatically passed by const reference, not by value, and for operator- it's normal to copy and then subtract the rhs, rather than the more C-inspired code shown.
This card might be helpful in its free version, but if you pay money you probably want something that's teaching correct/good C++.
Maybe with an update the card would be a good thing. Visually it's not unappealing and some thought has clearly gone into it: it's just that it has not been written by a C++ expert.
Now, c'mon, how did that get past pedants code review? So, catch by const reference, make numShares const if it's not going to change, and use std::numeric_limits::max() instead of INT_MAX, to please the anti-preprocessor crowd. Thanks.
Imitation is flattery, but imitation without acknowledgement is plagiarism. Microsoft appear (at the very least) to strongly discourage their employees from discussing how much.NET owes to the Java platform and how much C# owes to the Java language, even though anyone who knows Java can see that 80-90% of C# came directly from Java.
It's good that C# is competition, in some domains, for Java, and seems to have pushed Java's evolution forwards (new features for Java 1.5 are similar to things in C#).
In the academic or open source world these projects would normally acknowledge that they are building off each others strengths, but the commercial world tends to be less honest.
So, sure, don't condemn.NET for being a derivative product. But do by all means condemn those who try to cover that fact up.
http://www.accu.org/, by programmers for programmers. There's even a mailing list open to non-members, though membership is cheap and includes journals covering C, C++ and related languages as well as tools, techniques, and more.
atoi has undefined behavior for some error conditions. strtol is a safe version. You should only consider using atoi if you are entirely sure that the input is valid. And even then you should choose to use strtol to make the code rubust in the face of changes.
(For C++ heads, just read an int from a stream of whatever kind with >>, just as you do for any other type, and then check the stream status afterwards to make sure the operation succeeded, as in if (mystream >> myint) it_succeeded(); )
"As to your final question, while there certainly is a right to fair use, it is not a violation of that right to make products that cannot be copied."
This appears to be an assumption stated as a fact. One of the issues I would like to see debated honestly and openly is whether fair use law does/should protect your right to make reasonable use of a copyrighted work. It would be most disappointing if it's only application turned out to be in meaning that if you *could* make this use then you would not be breaking laws by doing so.
My feeling is that fair use doctrine has always intended to protect the right to make fair use, not just to grant immunity from prosecution to those who make such fair use. IAAP, though, not a lawyer.
If it is true that current law is clear and that there is no protection in the US for a citizen's right to make fair use of a copyrighted work, then the law needs to be changed. Copyright is about balancing the interests of copyright owners and the public, and the combination of technology and law is threatening to destroy that balance by giving "IP" owners complete control over how and when their works are used.
Let's not even get into estimates of how much many companies spend to avoid IP liabilities, and how much that exceeds their gain from IP assets...
Yes, relying on/. would be stupid, so naturally I don't do that. Relying on MS alone is also unwise. Bugtraq, automated updated (with supervision), slashdot, and warnings from clueful friends are better than any one source alone.
Whereas I read the slashdot story, and then attempted to use Microsoft's software update facility from IE6 to download the patch -- only to be told that my system was up to date. It wasn't, so I downloaded the patch and applied it manually.
For critical security updates, don't rely on the automatic update tools yet.
You'll be glad to know that the committee is aware of these issues and gives them more weight than you might believe. C++ doesn't evolve quickly; changes made in the last 6 years are nothing more than fixing defects, and the next standard is probably close to 6 years away.
The committee is generally not interested in adding features for the sake of adding features. New proposals are expected to fix a documented problem, and to show that they are valuable enough to justify the lack of stability they cause.
There is also clear recognition among the committee that C++98 was too inventive, and that anything significant that goes into C++0x should do so only after real-world experience with it has been obtained and reviewed. Hence the intention to publish a "technical report" on new library features -- it is likely that this TR will form the basis of much that will end up in C++0x, but its initial publication will not be in the form of an official standard.
D looks interesting, it's true, but last time I read through it's list of "improvements" they were largely actually a list of "things where D doesn't have the same goal as C++". Interestingly some of the reasons _for_ doing things a particular way are the same reasons for _not_ doing it that way in C++.
C++ doesn't have to do everything. Serious C++ users know and use other languages when it's appropriate (which is often), or combine C++ with other languages (Perl, Python, Tcl, C,...).
And the difference between pointers and references in C++ are a lot more than syntactic.
Note that languages which don't come with a preprocessor usually get preprocessors bolted on, either in their evolution or as third-party extras. The C++ preprocessor is ugly, it's true, by inheriting from the C preprocessor, but there is a need for some kind of preprocessor. C++ just covers more uses than a language like Java.
There will be much less change this time around; C++ has a standard now, and the standards committee, unsurprisingly, is largely composed of people who care about the value of a stable standard.
Many of the changes that are made will be in the library, not affecting compilers. Library changes tend to be "cheaper" in the library implementations are more portable and less user code is broken.
Changes to the core language are much harder to get past the committee. Apart from anything else there are fewer committee members working in this area.
Compared the stability of C++ to the rate of evolution of (say) Java, and you'll maybe see that we do care about the real world.
Read Bjarne Stroustrup's website to find out why most of your fears are unfounded, and to see a list of examples of real uses of C++.
A fundemental principle of C++ has been the "zero overhead" rule; there's no reason for good C++ code compiled with a good C++ compiler to be slower than C (and modern techniques allow C++ to be faster for some things, such as numerics).
Bjarne's homepage is still at http://www.research.att.com/~bs/. You'll find a list of examples of C++, as well as some debunking of performance myths about C++.
The C++ committee are also producing a "technical report" on performance, which gives more detailed refutations of many myths about C++ performance problems.
I have used C++ for embedded work. There is not a problem with C++ "implicitly creating objects on the fly". C++ allows tight control of memory allocation. C++ does not assume anything about interrupt handling.
Many compilers are written in C++ or generate C++ as their output. There is a move to use C++ in gcj, GNU's Java compiler.
There are problems with C++, but I don't think you've hit on them.
The original C++ is informally known as C++98, because it is defined by the International Standard ISO/IEC 14882:1998 (also adopted by ANSI).
A minor update to that standard will be published very shortly, depending on how the ISO machine works. That won't be what we're calling C++0x, it'll just be fixes for errors in C++98.
C++0x is the name given to the next major version of the C++ Standard, and it's some years away yet: expect 'x' to be large! Between now than and then there will be a "technical report", proposing extensions to the C++ library. It is likely to be widely supported, but a "technical report" (often abbreviated to TR) doesn't have the weight of a full ISO standard.
I really ought to update the comp.std.c++ FAQ to cover this...
Yes, it's C++0x for 2000-and-something, because we hope to get the next major revision of the C++ Standard out before 2010. A minor revision is going through the process of being published around now, but that just fixes defects in C++98, as the original ANSI/ISO/IEC 14882:1998 standard is informally know.
You're right in a sense: the bulk of the patent system consists of simple, incremental patents. I disagree that they are non-obvious.
If they are "non-obvious" and make a significant improvement, I'm not against patenting them. However -- I stand by my claim that most of the incremental patents are, in fact, sufficiently obvious that they ought not to be protected by patent law.
A phenomenal number of things software developers would think of, independently, thousands of times over, are protected by patents. Which is odd, given how obvious they must be that we reinvent them continuously.
So... if you invent a completely new way to open a soda can, go ahead and patent it. If you merely think of printing advertising on the top of the can, it's obvious, unimportant, and not worthy of protection.
The backbone of the patent system is, sadly, broken. In the world of software, at least, the patent system is more of a force against progress than for it.
The very fact that this is just a minor variant on so many existing systems shows that it is not "inventive" or "non-obvious", but rather "incremental" and "unimportant".
The US patent system should be changed to require an application to justify its claim to being inventive and non-obvious. That would eliminate the vast majority of software-related patents.
Such a shame it seems that the US will succeed in getting EU patent laws changed for the worse too. There's still time to act before the delayed vote in September, so for those who care that we have a system that encourages innovation rather than stifling it, find out what you can do to stop the EU patent system becoming as bad as that in the US.
Re:Let me be the first to say...
on
Jaguar is Over
·
· Score: 1
Saying that $129 is a reasonable (or sane) upgrade price from 10.2.6 to 10.3.0 does not make it so.
You failed to address the points I raised, and then you claim that it would be difficult and expensive to administer to offer reduced pricing for smaller upgrades -- but they did just that for the step up to 10.1 from 10.0.
So: explain to me why the upgrade from Mac OS 10.2.6 to 10.3.0 should cost as much as the upgrade from a completely different OS (Mac OS 9) to Mac OS 10.3. Explain why Apple would suddenly find it so troublesome to administer such a simple differentiated upgrade price.
With Mac OS X, I gave Apple a chance; finally they released an early version of what could be a fine OS. As of yet, it's the least solid Unix-based platform I work with, but it does at least run Microsoft Word natively, and runs on nice hardware.
Apple have effectively moved to a subscription model without mentioning it.
Now, I wonder how the lawsuits against them for selling Jaguar as including the.Mac service and then withdrawing it are going along...
Re:Let me be the first to say...
on
Jaguar is Over
·
· Score: 1
There's a world of difference between upgrading an old Mac from Mac OS 9 to 10.3 and spending a large chunk of cash _again_ if you recently handed over your hard-earned to upgrade from 9 to 10.2.
That's why there ought to be a sane upgrade price for users of Mac OS X 10.x. They've already paid already paid for most of what's in 10.3.
Fair comment. I did not mean to say that JDO or similar persistence mechanisms are inherently slow -- just that they will be slow if you don't use them well.
As with all synchronization, the key is to do as much as possible concurrently. That can mean batching updates, keeping writes restricted to small chunks of code, and so on.
I don't ask that people believe me blindly. Just don't believe any performance reports blindly.
Of course, if the article was true then using immutables and building objects wouldn't cause performance problems...
Did I mention that Java serialization is also pretty slow in many cases? Luckily there are hooks so that you can perform custom externalization, which can speed up RMI.
Don't trust me. Get some tools (OptimizeIt isn't bad, but also rely on measuring real throughput) and see where the bottlenecks in your code are.
My apologies to readers for bothering to respond to the parent post. Moderate away (or do I mean moderate this away to -1, Redudant?).
Most StringBuffer objects are not used from multiple threads. If you need synchronization, use it. In general you don't.
In particular, if you use a+b on String objects, the compiler will translate to use of a StringBuffer, even though that StringBuffer is manifestly not accessible from any other thread. I don't know if the JVM will optimize away the synchronization -- if it does, the analysis to allow it to do so is an overhead anyway.
The problems with StringBuffer are varied:
1. It is overcomplicated because it uses reference counting to avoid a single object allocation.
2. It guarantees thread safety even though that is not required for most of its uses.
3. The thread safety protects the integrity of the StringBuffer, but is not enough for most code that could use a StringBuffer from multiple threads: th e granularity of the locking is too fine. This is the same flaw that lead to the introduction of the unsynchronized collection classes (such as ArrayList to replace most uses of Vector).
4. It is overkill for the uses the Java compiler makes of it in performing string concatenation, and a performance penalty is paid.
One other interesting thing to note is that my UnsychronizedStringBuffer did not have a default constructor. This forced developers to specify an estimate for the size of the buffer, and so avoided most reallocations -- another performance win, just by restricting an interface.
In a real project, using JDK 1.3 on various platforms, we had performance issues. So, we measured speed in various ways, and found three main problems.
1: Synchronization.
This is slow. Really slow. And it just gets worse when you're running on dual or quad processor machines. StringBuffer is a major offender; in a lame attempt to save one object allocation, it uses a simple reference counting device which requires synchronization for operations as trivial as appending a character. Writing a simple UnsynchronizedStringBuffer gave a measurable performance boost.
2: Object creation
This is the real problem. GC is slow. GC on SMP machines is still really slow in JDK 1.3 -- maybe JDK 1.4 is better, my experience is a little out of date. By rewriting large chunks of code to create fewer objects (often by using arrays of primitives) we made it much faster -- close to twice as fast, if memory serves.
3: Immutable objects
Yes, these add to GC, and so are bad for performance. But not such a great evil, so long as you don't overuse them.
Funny that the article "debunks" these myths without figures, when our thorough measurements showed that the problems are real, and in our case would have killed our chances of meeting performance targets had we not found them and dealt with them.
Some bigger issues for server-side design: be careful how you use remote calls (such as RMI) and how you use persistence (such as JDO). But the small things, which the article seems to misrepresent, matter too.
Slashdot Mirror
No need to add more information; if you contact me privately (jdennett at acm.org will do) I'll happily review this for you and update it to conform to the C++ Standard where it doesn't already, and maybe offer a few other tips.
If you'd like a chance to make work for me, feel free to read the comp.std.c++ FAQ at http://www.jamesd.demon.co.uk/csc/faq.html and let me know what deficiencies you find there.
and didn't make it though for some reason... I'm "sure" I said plain text. Let's try them with HTML formatting this time.
void main? No points.
? Not part of Standard C++, which has instead.
The rest of the card doesn't look much better. The reserved words are listed and the card notes that they can't be used as identifiers, but it doesn't mention that there are other reserved identifiers.
The description of while(x) says that x must be an expression, but for a long long time C++ has allowed a variable declaration at this point, and such use is idiomatic.
The example of operator overloading is far from ideal: the argument is idiomatically passed by const reference, not by value, and for operator- it's normal to copy and then subtract the rhs, rather than the more C-inspired code shown.
This card might be helpful in its free version, but if you pay money you probably want something that's teaching correct/good C++.
Maybe with an update the card would be a good thing. Visually it's not unappealing and some thought has clearly gone into it: it's just that it has not been written by a C++ expert.
Now, c'mon, how did that get past pedants code review? So, catch by const reference, make numShares const if it's not going to change, and use std::numeric_limits::max() instead of INT_MAX, to please the anti-preprocessor crowd. Thanks.
Imitation is flattery, but imitation without acknowledgement is plagiarism. Microsoft appear (at the very least) to strongly discourage their employees from discussing how much .NET owes to the Java platform and how much C# owes to the Java language, even though anyone who knows Java can see that 80-90% of C# came directly from Java.
.NET for being a derivative product. But do by all means condemn those who try to cover that fact up.
It's good that C# is competition, in some domains, for Java, and seems to have pushed Java's evolution forwards (new features for Java 1.5 are similar to things in C#).
In the academic or open source world these projects would normally acknowledge that they are building off each others strengths, but the commercial world tends to be less honest.
So, sure, don't condemn
http://www.accu.org/, by programmers for programmers. There's even a mailing list
open to non-members, though membership is
cheap and includes journals covering C,
C++ and related languages as well as tools,
techniques, and more.
atoi has undefined behavior for some error conditions. strtol is a safe version. You should only consider using atoi if you are entirely sure that the input is valid. And even then you should choose to use strtol to make the code rubust in the face of changes.
(For C++ heads, just read an int from a stream of whatever kind with >>, just as you do for any other type, and then check the stream status afterwards to make sure the operation succeeded, as in if (mystream >> myint) it_succeeded(); )
"As to your final question, while there certainly is a right to fair use, it is not a violation of that right to make products that cannot be copied."
This appears to be an assumption stated as a fact. One of the issues I would like to see debated honestly and openly is whether fair use law does/should protect your right to make reasonable use of a copyrighted work. It would be most disappointing if it's only application turned out to be in meaning that if you *could* make this use then you would not be breaking laws by doing so.
My feeling is that fair use doctrine has always intended to protect the right to make fair use, not just to grant immunity from prosecution to those who make such fair use. IAAP, though, not a lawyer.
If it is true that current law is clear and that there is no protection in the US for a citizen's right to make fair use of a copyrighted work, then the law needs to be changed. Copyright is about balancing the interests of copyright owners and the public, and the combination of technology and law is threatening to destroy that balance by giving "IP" owners complete control over how and when their works are used.
Let's not even get into estimates of how much many companies spend to avoid IP liabilities, and how much that exceeds their gain from IP assets...
Yes, relying on /. would be stupid, so naturally I don't do that. Relying on MS alone is also unwise. Bugtraq, automated updated (with supervision), slashdot, and warnings from clueful friends are better than any one source alone.
Whereas I read the slashdot story, and then attempted to use Microsoft's software update facility from IE6 to download the patch -- only to be told that my system was up to date. It wasn't, so I downloaded the patch and applied it manually.
For critical security updates, don't rely on the automatic update tools yet.
You'll be glad to know that the committee is aware of these issues and gives them more weight than you might believe. C++ doesn't evolve quickly; changes made in the last 6 years are nothing more than fixing defects, and the next standard is probably close to 6 years away.
The committee is generally not interested in adding features for the sake of adding features. New proposals are expected to fix a documented problem, and to show that they are valuable enough to justify the lack of stability they cause.
There is also clear recognition among the committee that C++98 was too inventive, and that anything significant that goes into C++0x should do so only after real-world experience with it has been obtained and reviewed. Hence the intention to publish a "technical report" on new library features -- it is likely that this TR will form the basis of much that will end up in C++0x, but its initial publication will not be in the form of an official standard.
D looks interesting, it's true, but last time I read through it's list of "improvements" they were largely actually a list of "things where D doesn't have the same goal as C++". Interestingly some of the reasons _for_ doing things a particular way are the same reasons for _not_ doing it that way in C++.
...).
C++ doesn't have to do everything. Serious C++ users know and use other languages when it's appropriate (which is often), or combine C++ with other languages (Perl, Python, Tcl, C,
And the difference between pointers and references in C++ are a lot more than syntactic.
Note that languages which don't come with a preprocessor usually get preprocessors bolted on, either in their evolution or as third-party extras. The C++ preprocessor is ugly, it's true, by inheriting from the C preprocessor, but there is a need for some kind of preprocessor. C++ just covers more uses than a language like Java.
There will be much less change this time around; C++ has a standard now, and the standards committee, unsurprisingly, is largely composed of people who care about the value of a stable standard.
Many of the changes that are made will be in the library, not affecting compilers. Library changes tend to be "cheaper" in the library implementations are more portable and less user code is broken.
Changes to the core language are much harder to get past the committee. Apart from anything else there are fewer committee members working in this area.
Compared the stability of C++ to the rate of evolution of (say) Java, and you'll maybe see that we do care about the real world.
Read Bjarne Stroustrup's website to find out why most of your fears are unfounded, and to see a list of examples of real uses of C++.
A fundemental principle of C++ has been the "zero overhead" rule; there's no reason for good C++ code compiled with a good C++ compiler to be slower than C (and modern techniques allow C++ to be faster for some things, such as numerics).
Bjarne's homepage is still at http://www.research.att.com/~bs/.
You'll find a list of examples of C++, as well as some debunking of performance myths about C++.
The C++ committee are also producing a "technical report" on performance, which gives more detailed refutations of many myths about C++ performance problems.
I have used C++ for embedded work. There is not a problem with C++ "implicitly creating objects on the fly". C++ allows tight control of memory allocation. C++ does not assume anything about interrupt handling.
Many compilers are written in C++ or generate C++ as their output. There is a move to use C++ in gcj, GNU's Java compiler.
There are problems with C++, but I don't think you've hit on them.
Indeed, the final text of the first C++ standard wasn't ready until 1997, and became an International Standard the following year.
The original C++ is informally known as C++98, because it is defined by the International Standard ISO/IEC 14882:1998 (also adopted by ANSI).
A minor update to that standard will be published very shortly, depending on how the ISO machine works. That won't be what we're calling C++0x, it'll just be fixes for errors in C++98.
C++0x is the name given to the next major version of the C++ Standard, and it's some years away yet: expect 'x' to be large! Between now than and then there will be a "technical report", proposing extensions to the C++ library. It is likely to be widely supported, but a "technical report" (often abbreviated to TR) doesn't have the weight of a full ISO standard.
I really ought to update the comp.std.c++ FAQ to cover this...
Yes, it's C++0x for 2000-and-something, because we hope to get the next major revision of the C++ Standard out before 2010. A minor revision is going through the process of being published around now, but that just fixes defects in C++98, as the original ANSI/ISO/IEC 14882:1998 standard is informally know.
You're right in a sense: the bulk of the patent system consists of simple, incremental patents. I disagree that they are non-obvious.
If they are "non-obvious" and make a significant improvement, I'm not against patenting them. However -- I stand by my claim that most of the incremental patents are, in fact, sufficiently obvious that they ought not to be protected by patent law.
A phenomenal number of things software developers would think of, independently, thousands of times over, are protected by patents. Which is odd, given how obvious they must be that we reinvent them continuously.
So... if you invent a completely new way to open a soda can, go ahead and patent it. If you merely think of printing advertising on the top of the can, it's obvious, unimportant, and not worthy of protection.
The backbone of the patent system is, sadly, broken. In the world of software, at least, the patent system is more of a force against progress than for it.
The very fact that this is just a minor variant on so many existing systems shows that it is not "inventive" or "non-obvious", but rather "incremental" and "unimportant".
The US patent system should be changed to require an application to justify its claim to being inventive and non-obvious. That would eliminate the vast majority of software-related patents.
Such a shame it seems that the US will succeed in getting EU patent laws changed for the worse too. There's still time to act before the delayed vote in September, so for those who care that we have a system that encourages innovation rather than stifling it, find out what you can do to stop the EU patent system becoming as bad as that in the US.
Saying that $129 is a reasonable (or sane) upgrade price from 10.2.6 to 10.3.0 does not make it so.
.Mac service and then withdrawing it are going along...
You failed to address the points I raised, and then you claim that it would be difficult and expensive to administer to offer reduced pricing for smaller upgrades -- but they did just that for the step up to 10.1 from 10.0.
So: explain to me why the upgrade from Mac OS 10.2.6 to 10.3.0 should cost as much as the upgrade from a completely different OS (Mac OS 9) to Mac OS 10.3. Explain why Apple would suddenly find it so troublesome to administer such a simple differentiated upgrade price.
With Mac OS X, I gave Apple a chance; finally they released an early version of what could be a fine OS. As of yet, it's the least solid Unix-based platform I work with, but it does at least run Microsoft Word natively, and runs on nice hardware.
Apple have effectively moved to a subscription model without mentioning it.
Now, I wonder how the lawsuits against them for selling Jaguar as including the
There's a world of difference between upgrading an old Mac from Mac OS 9 to 10.3 and spending a large chunk of cash _again_ if you recently handed over your hard-earned to upgrade from 9 to 10.2.
That's why there ought to be a sane upgrade price for users of Mac OS X 10.x. They've already paid already paid for most of what's in 10.3.
Fair comment. I did not mean to say that JDO or similar persistence mechanisms are inherently slow -- just that they will be slow if you don't use them well.
As with all synchronization, the key is to do as much as possible concurrently. That can mean batching updates, keeping writes restricted to small chunks of code, and so on.
LOL.
I don't ask that people believe me blindly. Just don't believe any performance reports blindly.
Of course, if the article was true then using immutables and building objects wouldn't cause performance problems...
Did I mention that Java serialization is also pretty slow in many cases? Luckily there are hooks so that you can perform custom externalization, which can speed up RMI.
Don't trust me. Get some tools (OptimizeIt isn't bad, but also rely on measuring real throughput) and see where the bottlenecks in your code are.
My apologies to readers for bothering to respond to the parent post. Moderate away (or do I mean moderate this away to -1, Redudant?).
Most StringBuffer objects are not used from multiple threads. If you need synchronization, use it. In general you don't.
In particular, if you use a+b on String objects, the compiler will translate to use of a StringBuffer, even though that StringBuffer is manifestly not accessible from any other thread. I don't know if the JVM will optimize away the synchronization -- if it does, the analysis to allow it to do so is an overhead anyway.
The problems with StringBuffer are varied:
1. It is overcomplicated because it uses reference counting to avoid a single object allocation.
2. It guarantees thread safety even though that is not required for most of its uses.
3. The thread safety protects the integrity of the StringBuffer, but is not enough for most code that could use a StringBuffer from multiple threads: th e granularity of the locking is too fine. This is the same flaw that lead to the introduction of the unsynchronized collection classes (such as ArrayList to replace most uses of Vector).
4. It is overkill for the uses the Java compiler makes of it in performing string concatenation, and a performance penalty is paid.
One other interesting thing to note is that my UnsychronizedStringBuffer did not have a default constructor. This forced developers to specify an estimate for the size of the buffer, and so avoided most reallocations -- another performance win, just by restricting an interface.
In a real project, using JDK 1.3 on various platforms, we had performance issues. So, we measured speed in various ways, and found three main problems.
1: Synchronization.
This is slow. Really slow. And it just gets worse when you're running on dual or quad processor machines. StringBuffer is a major offender; in a lame attempt to save one object allocation, it uses a simple reference counting device which requires synchronization for operations as trivial as appending a character. Writing a simple UnsynchronizedStringBuffer gave a measurable performance boost.
2: Object creation
This is the real problem. GC is slow. GC on SMP machines is still really slow in JDK 1.3 -- maybe JDK 1.4 is better, my experience is a little out of date. By rewriting large chunks of code to create fewer objects (often by using arrays of primitives) we made it much faster -- close to twice as fast, if memory serves.
3: Immutable objects
Yes, these add to GC, and so are bad for performance. But not such a great evil, so long as you don't overuse them.
Funny that the article "debunks" these myths without figures, when our thorough measurements showed that the problems are real, and in our case would have killed our chances of meeting performance targets had we not found them and dealt with them.
Some bigger issues for server-side design: be careful how you use remote calls (such as RMI) and how you use persistence (such as JDO). But the small things, which the article seems to misrepresent, matter too.