Java, Ten Years Later

Posted in programming at 1:33 pm by danvk

It’s been almost ten years since I’ve actively used the Java programming language. In the mean time, I’ve mostly used C++. I’ve had to pick up a bit of Java again recently. Here are a few of the things that I found surprising or notable. These are all variants on “that’s changed in the last ten years” or “that’s not how C++ does it.”

The Java compiler enforces what would be conventions in C++.
For example, “public class Foo” has to be in Foo.java. In C++, this would just be a convention. You can use “private class” when you’re playing around with test code and want to use only a single file. Similarly, class foo.Bar needs to be in “foo/Bar.java”.

Java Packages are a more pervasive concept than namespaces in C++.
There’s a “default package”, but using this prevents you from loading classes by name: Class.fromName(“Foo”) won’t work, but Class.fromName(“package.Foo”) will. Classes in your current package are auto-imported, which surprised me at first. The default visibility for methods/fields in Java is “package private”, which has no analogue in C++.

Java keeps much more type information at runtime time than C++ does.
The reflection features (Class.getMethods(), Method.getParameters(), etc.) have no equivalent in C++. This leads to some seemingly-magical behaviors, e.g. naming a method “foo” in a Servlet can cause it to be served at “/foo” without you saying anything else. Not all information is kept though: you can get a list of all packages, but not a list of all classes in a package. You can request a class by its name, but you can’t get a list of all classes. You can get a list of all the method names in a class, but you can’t get a list of all the parameter names in a method.

Java enums are far richer than C/C++ enums.
enums in Java are more like classes: they can have constructors, methods, fields, even per-value method implementations. I really like this. Examples:

public enum Suit {
  CLUB("C"), DIAMOND("D"), HEART("S"), SPADE("S");
  private String shortName;
  private Suit(shortName) { this.shortName = shortName; }
  public String toString() { return shortName; }

Java is OK with a two-tier type system.
At its core, C++ is an attempt to put user-defined types on an equal footing with built-in types like int and char. This is in no way a goal of Java, which is quite content to have a two-tier system of primitive and non-primitive types. This means that you can’t do Map<int, int>, for instance. You have to do Map<Integer, Integer>. Autoboxing makes this less painful, but it’s still a wart in the language that you have to be aware of.

One concrete example of this is the “array[index]” notation. In C++, this is also used for maps. There’s no way to do this in Java, and I really miss it. Compare:

map[key] += 1;


map.put(key, 1 + map.get(key));

which has more boilerplate and is more error-prone, since you might accidentally do:

map.put(key, 1 + other_map.get(key));

The designers of Java Generics learned from the chaos of C++ templates.
Generic classes in Java are always templated on types: no more insane error messages. You can even say what interface the type has to implement. And there’s no equivalent of method specialization, a C++ feature which is often misused.

Variables/fields in Java behave more like C++ pointers than C++ values.
This is a particular gotcha for a field. For example, in C++:

class C {
  C() {
    // foo_ is already constructed and usable here.
  Foo foo_;

But in Java:

class C {
  public C() {
    // foo is null here. We have to do foo = new Foo();
  private Foo foo;

Java constructors always require a trailing (), even if they take no parameters.
This is a minor gotcha, but one I find myself running into frequently. It’s “new Foo()” instead of “new Foo” (which is acceptable in C++).

The Java foreach loop is fantastic

for (String arg : args) { ... }


for (Set<string>::const_iterator it = args.begin(); it != args.end(); ++it) { ... }

The “static {}” construct is nice
This lets you write code to initialize static variables. It has no clear analogue in C++. To use the Suit example above,

private static HashMap<String, Suit> name_to_suit;
static {
  for (Suit s : Suit.values()) { name_to_suit.put(s.toString(), s); }

The new features (Generics, enums, autoboxing) that Java has gained in the last ten years make it much more pleasant to use.


  1. Craig Fratrik said,

    November 6, 2011 at 11:43 pm

    Boost Foreach is pretty good.

  2. danvk said,

    November 7, 2011 at 8:40 am

    There’s something nearly identical to Java’s foreach in C++11: http://en.wikipedia.org/wiki/C%2B%2B11#Range-based_for-loop

    Unfortunately, we’re not allowed to use either that or boost::foreach at work yet :(

  3. Kenny Leftin said,

    November 17, 2011 at 11:46 pm

    If you’re doing a lot more with Java, it’s worth reading Effective Java by Josh Bloch. It’s the bible for good Java idioms. (There’s a free pdf copy within Google that you can read)

    Be careful with your last point. static {} is convenient for a project with only a couple classes, but it can get un-maintainable really quickly. Since the static block is executed only when the class is loaded, it can be surprising when it will or will not run. The ‘static’ keyword in Java in general can be a little hairy. See Puzzle 5 (http://www.javapuzzlers.com/java-puzzlers-sampler.pdf) for class initialization craziness. Not to mention, it’s almost impossible to mock any sort of static method in a unit test. I basically only use static for two things:

    1. Defining final constants
    2. Writing methods that need absolutely no state

    What are you working on nowadays that uses Java? You should e-mail me!