java
Feb 6th
Back from hiatus
May 17th
I’ve been on a bit of a hiatus recently, but I should be back to posting soon. I switched projects and have been spending a lot of time cleaning up some big messes. I turned a nasty Eclipse right click/export build into something usable. We ended up with a sweet Maven/Nexus/Hudson build process. I’ve used Maven on a lot of projects and have a love-hate relationship with it. Dependency management is such a freeing experience, but I’m trying to cut down on the amount of time I spend with XML. I know Maven 3 has the ability to create poms with Groovy, but I haven’t gotten into that much. Instead, I’ve been using Gradle. It has all the advantages of dependency management without the legacy cruft. It took me a couple of days to understand what Gradle was doing and it’s still immature, but I think it has a bright future. Either way, Nexus has been the core product that has brought all of this together. Whether we are using Maven, Gradle, or Ant/Ivy, Nexus just keeps getting better and better. It’s one of those products that I find just “works”. I highly recommend it as the heart of a jvm build process. I’ve got a lot more to talk about in this space, so hopefully I can’t blog on that soon.
Addicted to final
Jun 25th
What can I say? I’m addicted to the final keyword. My code is littered with it. A typical class can end up looking like the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | public class SimpleClass { private static final Logger logger = Logger.getLogger("SimpleClass"); private final String foo; private final List<String> bars = new ArrayList<String>(); public SimpleClass(final String foo) { this.foo = foo; } public void addBar(final String bar) { bars.add(bar); } public void printFooBars() { final PrintStream out = System.out; try { out.println(getFoo()); } catch (final Exception e) { logger.info(e.toString()); } for (final String s : bars) { out.println(s); } } protected String getFoo() throws Exception { if (foo == null) { throw new Exception(); } return foo; } } |
Constants, variables, and parameters have final attached to them. I wasn’t always this addicted, but I’ve since learned through painful experience. With the final keyword spread liberally around my code, the compiler does the hard work and tells me when I’m doing something wrong. I can’t accidentally change a value or reassign a variable I didn’t mean to. I know that a lot of people will complain about how verbose this can be and they’re correct. That’s part of the language, though. I’d love to have all variables set as final by default. Until then, I’ll sprinkle it around every chance I get.
Input params are not for output
Feb 25th
Sometimes you run across some code that makes you cringe a little bit. That happened to me today when I ran across this blog post. It’s about how the final modifier is used for method parameters. A sample of what the post is trying to convey looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | public void printWords() { final List<String> words = new ArrayList<String>(); words.add("foo"); words.add("bar"); appendNewWords(words); System.out.println(words); } private void appendNewWords(List<String> words) { words.add("boo"); words.add("far"); } prints: [foo, bar, boo, far] |
The problem with that code is it treats a method input as an output parameter. Generally, that’s bad form and should be avoided. Even with a descriptive method name, you end up with code that doesn’t read well. A better example, with the input parameter removed, would look something like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | public void printWords() { final List<String> words = new ArrayList<String>(); words.add("foo"); words.add("bar"); words.addAll(getNewWords()); System.out.println(words); } private List<String> getNewWords() { final List<String> newWords = new ArrayList<String>(); newWords.add("boo"); newWords.add("far"); return newWords; } prints: [foo, bar, boo, far] |
Perhaps you’re still dead set on passing your List object into a method and getting results back. Maybe you want to remove elements, for example. You still want to use input params for input and return an output object. In this instance, it’s nicer to pass an immutable List (Google collections) or an unmodifiable in and return results based on that versus modifying the input param, which leads to confusing code.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | public void printWords() { final List<String> words = new ArrayList<String>(); words.add("foo"); words.add("bar"); List<String> modifiedWords = removeFoo(Collections.unmodifiableList(words)); System.out.println(words); System.out.println(modifiedWords); } private List<String> removeFoo(final List<String> words) { final List<String> modifiedWords = new ArrayList<String>(words); modifiedWords.remove("foo"); return modifiedWords; } prints: [foo, bar] [bar] |
Java EE 6 Automatic Timer
Jan 14th
I’ve been playing around with scheduled jobs a bit. I’ve mostly used Quartz in the past, but I thought I’d try out Automatic Timers from Java EE 6. They are pretty simple and can be defined either in an annotation or the ejb-jar.xml file. For instance, I might want to run two different jobs; one every 5 seconds and one every 10 with something like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | import java.util.Date; import javax.ejb.Schedule; import javax.ejb.Singleton; @Singleton public class SimpleJobs { @Schedule(second="*/5", minute="*", hour="*", persistent=true, info="job #1") public void jobOne() { System.out.println("Job one fired on " + new Date()); } @Schedule(second="*/10", minute="*", hour="*") public void jobTwo() { System.out.println("Job two fired on " + new Date()); } } |
The second, minute, and hour values all default to 0, so you need to provide wild cards for them in this case. The “*/5″ and “*/10″ basically means for every interval of X seconds, fire the job. Of course, there are values for day, week, month and year. There is support for ranges and starting time, so you can get as complicated or simple as you need. The persistent element is true by default and tells the server if the timer should remain after a restart or not. The info tag gives a simple name for programmatic display purposes.
I think these automatic timers seem like a nice addition and could come in handy in certain spots. I’m curious about their reliability, mutability, and accessibility though as I haven’t gotten a chance to play with them much. How will jobs react in a cluster or during a server crash? Is there an easy api interface to edit a running schedule? How can I know when jobs are being fired and when they aren’t? I’m going to write some more code and play with them a bit. I need to consolidate the status of all my scheduled jobs into one place, so we’ll see how these fit in. I’m sure a bit of magic pixie dust is all I’ll need.