15 things we hate about Java

We don't really hate Java. It's the best thing that's happened to us. We love its type-checked, belts-and-suspenders world for the stability and ubiquity. But
that doesn't ean we can't coplain a bit and dish out the snarky, cranky coents, does it! Isn't that why the Internet was invented!
"ere are #$ coplaints about the write-once, run-ostly-everywhere language that Java has becoe.
Long CamelCase names
%he idea of gluing together long sentences into variable naes by capitali&ing the first letters gets old quickly. %here's no doubt that it adds a bit of self-
docuentation to the code, but wouldn't it be easier to read a line that said'
i // holds the interest rate before taxes as per regulation 43
instead of'
interestRateHoldingVariableAdjusted ForTaxesAsDefinedByRegulation43
Punctuation
If there's one a(or difference between Java and the newcoers, it's the punctuation. Java progras are filled with curly brackets, seicolons, and
parentheses that other languages like )roovy or *uby do well without -- not that punctuation lovers don't have a legitiate beef with languages like +ython
that use arcane white-space rules to signify the sae separations between e,pressions and blocks that punctuation does in Java.
-till, ost prograers can't stand the punctuation. %hey see it as visual noise -- and an opportunity for the copiler to scold and scold again. %his
disconnect eans there ay be no easy solution beyond letting soe folks use )roovy and others use plain old Java. .t least their code can copile into
the sae J.*.
Open source confusion
Is Java open source or not! Which libraries are open source! /arned if I can be sure even after )oogle's long skirish with 0racle. 1or the ost part, Java
prograers don't need to worry because the J*2s and J/3s are freely available. But in the backs of our inds, there's always the scary feeling that soe
lawyer will (up out of nowhere and say, 4-top54 -oehow it feels like the legal status akes us all pawns in the battles between IB6, 0racle, and )oogle.
The Java thread pig farm
When Java cae along, the threads were lightweight copared to any of the other solutions. %hey were an easy way to (uggle ultiple tasks with the
sae eory space. 7ow, the folks using 7ode.(s are always sticking their tongue out at the Java server platfor and suggesting that the Java thread
factory is one big pig far adding 86B of fat to the server *.6 profile every tie soeone clicks on a Web link. -oehow, using the Java thread odel is
never as lightweight as it used to be. 9)ranted, those of us still prograing in Java aren't either, but that doesn't ake it easier to live with.:
Intolerably slow startup times
.nyone who's tried to create an .ndroid app using Java knows how slowly the siulator code runs on your desktop. %hat's the ost e,tree e,aple of
how getting a Java progra going is about as hard as getting a teenager to get up early on a -aturday to clean their roo. While Java apps can run fairly
soothly once they get going, they start up slower than an overladen #;-wheeler at a red light on an uphill road.
ndless chec!ing for null pointers
Is there anything to this coplaint! <et e check if it's null before typing any ore -- sees fine. 7ow let e check if y keyboard is present and hasn't
been replaced by a null ite. It's still here. 7ow I'll ove y fingers and tell you why null testing is a pain.
Java requires endless if stateents to test whether variables ended up null= otherwise entire threads crash with NullPointerExceptions. -art-ass
developers say it's y fault for not checking the input at the beginning, but that's not always possible when creating libraries. If soeone picks up this class
file in the future, you better check all the variables yet again -- you have no idea how they'll reuse it.
Ob"ect creation overhead
%ossing everything into an ob(ect sees like a clean way to progra until you reali&e how slow it can be to create a Java ob(ect. 2veryone who really tries to
reengineer code to speed it up begins by tossing aside the ob(ect-oriented odel as uch as possible. 0b(ect creation is relatively e,pensive, and it's a big
reason why soe Java code runs so slowly.
Primitive wrappers to use data structures
%he Java >ollections classes and other data structures are nice, but they require you to wrap your basic values in ob(ects to use the. %hat eans a four-
byte int turns into a big, fat ob(ect with all the weight and creation tie of an ob(ect. -oe prograers have written their own data structures with basic
priitives to avoid this issue, but it's probably too late for ainstrea Java. We're stuck with aking the distinction between a four-byte int and an Integer
ob(ect.
#trings are big$ need overhead$ and are final
-trings are yet another ob(ect, but they can't be changed. ?ou better get the right the first tie. If you want to change one byte, you have to create an
entirely new ob(ect and copy it all over. +lus, they add overhead, which is fine for tossing around big blocks of te,t but a real nuisance for sall strings. /o
you get a choice! 7ope. Just be happy that the overhead with the start and stop points coes in handy when you're snipping and concatenating.
%o global variables
It's a bit disingenuous for prograers to coplain about the lack of global variables in Java because they're also quite willing to grouse about the dangers
of global variables in other languages like +"+. -till, we're forced to (up through strange hoops to do uch of what global variables will give us. -oe
people create a Global class and fill it with static variables. 0thers build singleton ob(ects coplete with a getting routine that will always return the one
ob(ect. %his ight be tolerable if creating singleton ob(ects weren't so fraught with race conditions and issues about efficiency.
#ecurity flaws
-oe say it's not fair to blae Java for the fact that it's a big target. 0thers say that the other platfors have even ore security holes and at least the Java
engineers tried to build a decent sandbo,. -till others say security issues are e,pected, and at least 0racle publicly announces bug fi,es, often in big
batches like the @8 security fi,es it announced last year.
%hese are all fair points, but they don't ake living with Java any easier. Java's popularity eans that any hackers will target the JA6. Java's security
odel eans that any prograers will trust the JA6 when perhaps they shouldn't trust it so blindly. If only we could believe that the software was
perfect.
J&' freeloaders
6any languages now copile down to Java bytecode, so they can run on any JA6. What better way to draft behind the hard work the Java tea does to
ensure copatibility and ensure your code can run on a variety of platfors! >lo(ure, -cala, J*uby, *hino -- the list goes on and on.
%his can be an advantage for integrating, say, *uby with Java, but it inevitably turns into a hassle. -uddenly it's not enough to ake sure the Java code
copiles with the libraries you've got. 7ow you have to worry about 7 languages running peacefully in the sae JA6. When it works, it's a testaent to the
power of the Java stack, but it can be a headache generator for everyone.
(evisionism
-elf-iproveent is norally an occasion for celebration, but in the world of the Java stack, it can also bring confusion and headaches. -hould I use the
newerStringBuilder class or the older StringBuffer! 0r isStringBuilder the older one! .ren't they the sae!
.t least it's easier to reeber that the new I0 classes, 7I0, are newer than the old ones. %here are do&ens of e,aples of new and iproved techniques
that you ight want to use, if you can keep everything straight. %hey keep iproving the Java stack, but this only eans we need to relearn so any of the
idios that were burned into our brains before.
)nfathomable vastness
%he huge collection of official Java .+Is and not-as-official open source packages fro groups like .pache ake Java a fertile environent for standing on
the shoulders of giants. %he only proble is that you can't stand on the shoulders if you don't know they e,ist. It can take days to work through the various
.+Is to figure out which is really the best for what you're trying to do. %hen the guy in the other cubicle always sees to know soething better, a fact
always delivered with the slightest aount of snark at the code review eeting.
Java is everywhere
Java is everywhere, they say. It's in cellphones, Blu-ray disks, "adoop clouds, and desktops. -houldn't that be a cause to celebrate! /oesn't that ean
everyone loves it! -ure5 But it also akes it easier to hate because all that success akes it that uch harder to keep a handle on it all. It's a full-tie (ob
(ust watching the Java world evolve.
Buick, what do you need to fi, when you upgrade fro #.C to #.D! Which version of the .pache >oons is good enough! It's not possible to be a Java
e,pert anyore, and that's a tough revelation for those who could be Java e,perts back when the language appeared.