Java Reference
In-Depth Information
Slow to Change
The original Java language is now well over 15 years old, and has not undergone a
complete revision in that time. Many other languages (e.g., Microsoft's C#) have
released backwards-incompatible versions in the same period—and some develop‐
ers criticize Java for not doing likewise.
Furthermore, in recent years, the Java language has come under fire for being slow
to adopt language features that are now commonplace in other languages.
The conservative approach to language design that Sun (and now Oracle) have dis‐
played is an attempt to avoid imposing the costs and externalities of misfeatures on
a very large user base. Many Java shops have made major investments in the tech‐
nology, and the language designers have taken seriously the responsibility of not
affecting the existing user and install base.
Each new language feature needs to be very carefully thought about—not only in
isolation, but in terms of how it will interact with all the existing features of the lan‐
guage. New features can sometimes have impacts beyond their immediate scope—
and Java is widely used in very large codebases, where there are more potential
places for an unexpected interaction to manifest.
It is almost impossible to remove a feature that turns out to be incorrect after it has
shipped—Java has a couple of misfeatures (such as the finalization mechanism) and
it has never been possible to remove them safely without impacting the install base.
The language designers have taken the view that extreme caution is required when
evolving the language.
Having said that, the new language features present in Java 8 are a significant step
towards addressing the most common complaints about missing features, and
should cover many of the idioms that developers have been asking for.
Performance Problems
The Java platform is still sometimes criticized as being slow—but of all the criti‐
cisms that are leveled at the platform, this is probably the one that is least justified.
Release 1.3 of Java brought in the HotSpot Virtual Machine and its JIT compiler.
Since then, there has been almost 15 years of continual innovation and improve‐
ment in the virtual machine and its performance. The Java platform is now blaz‐
ingly fast, regularly winning performance benchmarks on popular frameworks, and
even beating native-compiled C and C++.
Criticism in this area appears to be largely caused by a folk memory that Java used
to be slow at some point in the past. Some of the larger and more sprawling archi‐
tectures that Java has been used within may also have contributed to this impres‐
sion.
The truth is that any large architecture will require benchmarking, analysis, and
performance tuning to get the best out of it—and Java is no exception.
