StyleFeeder Tech Blog » java

final

Philip Jacob — Tue, 11 Aug 2009 18:35:03 +0000

I saw this blog post referenced on Hacker News today and thought I’d pounce on one of Stephan’s opinions, which is that the final keyword in Java shouldn’t be used except on fields. I can’t disagree strongly enough with this. I first came across this advice in the O’Reilly Hardcore Java book about five years ago. The book dedicates a whole chapter to the final keyword, which initially surprised me – I didn’t think that the author could possibly have that much to say about it! However, the main idea is “enforced documentation,” which is an argument that really sold me on the concept. I find that whenever I see final on a method parameter, a local variable or whatnot, I have one less question about how that object reference will be used, especially when I’m reading someone else’s code. I know that it was the developer’s intent that the variable in question be assignable or not. I find this to be immensely helpful.

Stephan’s argument is that it impacts readability, but I don’t find that at all. In fact, we make final part of our cleanup process for our default formatter in our Eclipse setups at StyleFeeder. Does final help prevent bugs? Occasionally, yes, but the cases for this are rare enough that I hesitate to put this forth as the main argument in favor of it.

The Perl-ish argument against this is to “avoid putting bars on the windows”, since you never know how things may need to be used in the future. However, that simply doesn’t hold up as a solid argument 99% of the time. The two common use cases for sprinkling final into your Java code are on method parameters (which you should normally not be assigning to) and local variables. In the case of local variables, they are local and the impact of putting final on them is entirely contained within that scope. I have yet to see a reason why this would yield any unwanted side effects. Of course, making classes and methods final is a Big Decision and not what I’m talking about here.

To OOME, or not to OOME

Jason Rennie — Tue, 23 Sep 2008 18:15:55 +0000

“Hello? Contegix?” “Good morning. We’ve observed an OutOfMemoryError on stylefeeder01. We’ve restarted the web application and it seems to be running fine.” “Thanks for taking care of this for us,” I’d say. At this point, I’d start digging through log files to find out what had happened.

We’ve certainly had our share of Java Garbage Collection fun here at StyleFeeder, from heap and PermGen exhaustion, to memory leaks in libraries we’ve used; we’ve even been smacked over the head with the poor choice of NewRatio default for the x86-64 platform. But, these new OOMEs we were seeing seemed especially odd. The (Hotspot 1.5.0_09) JVM would log a PermGen OOME (”java.lang.OutOfMemoryError: PermGen space”), then proceed like normal, running a Full GC shortly thereafter. The GC log would indicate that, yes, PermGen was temporarily full, but, no, there was no real lack of space—the Full GC had no trouble clearing up over half of the available PermGen space. It was almost as if the JVM was yelling for help before it even tried to clean up its own mess.

At this point, we were using the default server GC, the throughput parallel collector. The parallel collector has two types of cleanups: scavenges and Full GCs. When the young generation fills up, a scavenge is fired off, cleaning up the young generations of the heap. When the old generation or permanent generations fill up, a Full GC is run, which cleans up all memory areas under GC control. Or, at least, that’s my understanding of what’s supposed to happen. In our case, when the permanent generation filled up, the GC would first fire off an OOME, then run a Full GC.

This smelled like a bug in the JVM. We weren’t using the latest version of Hotspot and were a little hesitant to upgrade, so we tried something different: the mark and sweep garbage collector. We had been thinking about using mark and sweep to avoid the occasional long pauses that are characteristic of the parallel collector. So, we gave it a whirl, making sure to turn on the options that would do as much permanent generation cleaning as possible:
-XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled
We waited… and waited… and waited… At this point, it’s been three weeks without an OOME, so I think we can safely declare the change a success.

Modified in the Past, Previously Known as the Future

Jason Rennie — Wed, 13 Aug 2008 21:13:59 +0000

Commons Configuration is a huge timesaver—flexible, simple configuration management with the highly useful feature of automatic file reloading. But, lately, that highly useful feature hadn’t been working for me. I’d make a change to the config file in a deployed application and see no change to the values in the application. WTF? What’s crazy is that it’d be inconsistent—some days it would work, others it wouldn’t. Yesterday the problem came to a head—I needed the reloading functionality to work, but it just wasn’t happening. So, I put together some simple test code and, viola, it worked! Huh? Back to the deployed application: no workie. Back to the test case: works like a charm. Egad!

Some JavaDoc digging led me to realize that the problem might be something screwy with the file last modification times. Sure enough, some of the deployed config file unix mtimes were in the future. Digging into the Commons code revealed that a file is only reloaded if the current mtime is ahead of the initial mtime of the file. So, Configuration wouldn’t reload the file until the present had caught up with the future. Ack! But, where were these future timestamps coming from? Ah, of course… (with gritted teeth) Maven. Turns out that the Maven packaging process was storing UTC timestamps in the war file. Yet, when we exploded the war file using unzip, those timestamps were not converted back to our local (EDT) time, so any file modified around the time of the packaging ended up 4 hours in the future.

The solution turned out to be simple: export TZ=”America/New_York”. This caused maven to store our local, rather than UTC times. Unzip’s behavior was unaffected by the setting of TZ, so the deployed files had the correct timestamps after all. A little test clarifies why Maven is doing this. Maven uses java code to perform the packaging and the java File.lastModified() method returns the UTC timestamp. What’s a bit appalling is that my local timezone is specified on my local system in the usual way: via /etc/localtime. Basic unix utilities like ls, stat and unzip don’t seem to have any problem doing the conversion. But, I don’t think Maven can be blamed since it’s probably doing the reasonable thing and using java.util.TimeZone.getDefault() to determine the time zone. A bit of searching reveals that the blame lays squarely on Sun’s head for using a poor hack to determine timezone on Linux. Amazingly, the bug describing this problem has been outstanding for over two years. Sun, is it really that hard to parse an /etc/localtime file?