Java: Follow-ups

In regard to my last post, Christian Ullenboom recommended that I put the JBoss naming properties in a separate jndi.properties file that is in the runtime classpath. This is a great recommendation because it decouples the naming properties from the code allowing different naming services to be used. I think doing it this way is the “right” way to do it because the Java code is cleaner and the application becomes more flexible. There was one small problem I ran into after putting the jndi.properties file into my Eclipse project. Running the application produced a NoInitialContextException and it seemed like the jndi.properties file was not found in the project classpath. I “fixed” this by exporting a jar file containing the properties file and manually added that jar file to the project classpath. I'm not sure I like doing it that way and I'll play with it a little more to see if I can make due without any artificial external jars.

Tom Hawtin had some advice about (not) overriding the Object#finalize() method. Here's what the code should look like using Java 1.5:

@Override
protected void finalize() throws Throwable {
    super();
    System.out.println("This is the com.anthonychaves.scratch.Guitar#finalize() method.");
}

I wasn't really sure what the @Override annotation meant, other than it was an annotation new to J2SE 1.5. A search on the
Java 1.5 docs told me what the @Override annotation means. A complie-time error would be nice when refactoring a superclass removes a method that is expected to be overridden in a subclass. The only problem I see is that you have to be aware of @Override to use it. Thank you for pointing it out to me Tom.

David Shay pointed out an oversight I made coding up the Guitar classes a few weeks ago. I was trying to illustrate that changing the value of a final variable was not possible using the = operator and used String#replaceAll(…) instead. David correctly said that the nameBrand.replaceAll(”Fender”, “Celebrity”); line of code would not work as I expected and had I bothered to read that variable again I would have caught it. Since Java Strings are immutable a call to replaceAll(…) doesn't operate on the String it's called on, but rather returns a new String. No matter how you try it, you can't change a final String.

Thanks all that wrote comments. They're always welcome.