The inventors of Java were C/C++ programmers, and they made conscious decisions to leave out most of the C/C++ features that get programmers into trouble. Not you of course, you are a great programmer and you never make mistakes and your code is wonderful. It's your dumb, lazy, careless coworkers I'm talking about here.

Java has no global variables or functions

Of course you've heard that global variables are evil, but maybe you never really bought into it. You made a variable global "for now" and never got back to making it local. Or you have a variable (probably named something like "DEBUG") that's referenced just about everywhere, so it needed to be global.

Every Java variable is part of some class, so you'll have to change your ways, and you'll feel a lot better about yourself. Looking for the abs() function? It must be in the Math class. Where is "stdin" defined? It's a public static field in the "System" class. Trying to find "atoi()"? Umm...ok, there it is: Integer.parseInt().

Java has no pointer and address operators

That's right, no more "*person" and no more "&person". How about we just use "person" everywhere? Really! Things are much simpler that way.

Java has no "struct" or "union"

A class is a bunch of variables and methods ("method" is just the object-oriented term for "function"). So why do we need a "struct"? It's just a class that happens to have no methods. And a union to save data of one type or another at a single location? That's what subclasses are for. If you don't know what a subclass is yet, don't worry: it's a basic OO concept, and you'll learn it as you learn Java.

Java has no pre-processor and no macros

What do you use your pre-processor for? Let's see...

• You define your "structs" there, but structs are gone now.
• You define TRUE and FALSE, but Java has the boolean type built-in.
• You define some simple function-like macros that are really hard to read and should probably just be functions, but you wanted to save a few milliseconds at runtime when your application ran on a 80286 processor. You're past that now.
• You have lots of "#ifdefs" to handle various compilers, various Operating Systems, and various hardware. Java takes care of all those inconsistencies for you. "Write Once, Run Anywhere", as they say.

Java does not have "unsigned" types

Was it really worth the two seconds of effort for you to type "unsigned" when you knew your int should never be negative? Was it really worth the savings of two bytes of runtime memory out of the 20 million bytes that your program uses? It's possible, but I doubt it.

Java has no bitfields

Again, do we really need to have the ability to specify a particular number of bits that you need to save a few bits in memory? If you need a one-bit value, use the "boolean" primitive type in Java. If you have a two-bit field, shouldn't you really be using an "enum" anyway and clearly specify what those values are? Please, go back to concentrating on your application and don't worry excessively about wasted bits.

Java has no operator overloading

Ah, yes, operator overloading. The previous developer was so cute to have written:

x = person1 + person2;

The problem is, you don't know what it means to "add two people together". Are you adding their ages? Are they getting married or something perhaps more intimate? In fact, now that you think about it, does "+" really mean much of anything except to add two numbers? OK, ok, let's assume it means to concatenate two Strings together, but that's it. No operator overloading. Just say:

 "person1.marry(person2)"

...using an appropriate method name.

Java has no comma operator

Do we really need this operator in a language? Nah.

Java has no goto statement

You knew this was coming! The "Gotos Considered Harmful" discussion has been going for 35 years now. We're all grownups here. We all know you can write nice code without gotos, and in the very rare case where the code might be a little nicer where we need to break out of a particular nested loop, we can do it. Goto is dead. Long live goto.

Java has no function pointers

The syntax for function pointers is just plain ugly. You can do the same thing in Java, in a cleaner way, using Reflection. For example:

 Method method = Person.class.getMethod("getAddress", null);
// invoke the "getAddress()" method on object "joe"
Object address = method.invoke(joe, null);

Java has no enums

Now how am I going to put a positive spin on Java's lack of a "enum" type? Well, I can't. I wish Java had an enum. But of course, you can make do by defining your own class, and get all the compile-time type-checking that you'd like:

class MarriageStatus {
public static final MarriageStatus SINGLE = new MarriageStatus();
public static final MarriageStatus MARRIED = new MarriageStatus();
public static final MarriageStatus DIVORCED = new MarriageStatus();
}

Java has no "varargs"

There's no need for this "varargs" stuff. If you have a set of fields that you tend to pass around together, put them together into a class and pass an instance of the class around. If you have a function that works on a list of objects (and the list can be any length) then just pass a List object.

Java does not allow multiple inheritence

It's surprising but true: multiple inheritence is way overrated. Sure, you can think of examples where it seems like you'd want multiple inheritence, but in the real world, it's very rare that you want to inherit behaviour from more than one superclass. More often, multiple inheritence is used where a Java interface would be better suited. Say I'm the database guy, and I write a bunch of functions that you call to access the database. How do we formally agree on what functions I provide? I know what you're thinking: I write a superclass that lists all the functions, and then I subclass it and you create an instance and call the methods. That's how it's usually done in C++, but that's not a good way to do it. You shouldn't care what my class is a subclass of, all you should care about is that I have implemented a certain set of methods. That's what an interface is: a list of methods that can be called. In Java, we write an interface (which is just a list of method signatures). I implement the interface, and you call the methods. Trust me, you'll be pleasantly surprised that you don't really need multiple inheritence in the few places where you think you do.

Home