Java Developers Need To Understand Networking

As I mentioned, when I interview candidates, I ask a series of networking questions.

Tonight I transitioned a JBoss service off of a VMware instance and onto real hardware. To make things easier, we swapped the IP addresses of the VMware instance and real hardware (no messy DNS TTLs to worry about).

When co-ordinating this move, I asked to have a network guy around, "just in case someone needs to flush an ARP cache". Nobody was quite sure if we would actually need to do this.

The transition was extremely smooth, and half way through, our NetOp guy chimed in letting us now that he indeed needed to flush the ARP cache of the routers. Had we not flushed the cache, things could've been messy. It would have cleared up eventually, and had we not been prepared we would have just been puzzled for a little bit.

I feel that even when developing within a no-sharp-edges universe like a J2EE container, it's important to be vaguely aware of how an application is communicating with the world around it and a lot of Java developers these days sorely lack in this domain of knowledge.

M-x format-according-to-company

Many Java developers have a "follow suit" mentality. It's honestly a good thing; it gives the code that we all write a uniform look and feel. It makes a developer naturally write in lowerCamelCase while avoiding Hungarian notation. If a developer extends Exception, they're naturally going to have a strong urge to end their class name with Exception.

It's a pleasant change from the C days when everyone invented this standard. Gone is the era of not picking a library because of their naming scheme (well, mostly gone).

One idiosyncrasy we have where I work is a coding convention that method names should be ordered alphabetically in classes, with the exception of pairing getters/setters together. This convention reminds me of my C days.

Historically, IDEs were nothing more than project management tools with syntactic colour coding, so naturally, finding functions involved a lot of paging around, or just plain old searching if you knew what you were looking for (was it "set_window_border", or "window_set_border"?). Back then, tidying up your code so method names were alpha-sequential only made sense.

Fast forward fifteen years.

These days, my IDE knows more about the interdependencies of my project than I do. It suggests what parameters I want to pass to my methods, and it gets them right. I can search for classes by wildcard, or by acronym expansion; entering "NPE" returns NullPointerException (and a surprising array of other classes whose names shorten to NPE).

Once in the type of my choice, my IDE is there with all the methods sorted alphabetically in a nice, handy side view.

Personally, I prefer the "sorted by conceptual closeness" mechanism. Methods that work together, live together. I know this requires some diligence, and some maintenance, but not much of each.

All that said, I don't think I would enforce any sort of method ordering scheme upon developers. We don't read or write code like we did years ago. Even during code reviews, I tend to follow the logical flow from public methods instead of reading a class linearly from beginning to end.

At least we're not arguing about tabs vs. spaces.....right?