From builder.com: “Manipulate expressions with the new features of java.lang.String”

“The Java String class has remained largely unchanged since JDK 1.0,
receiving only a minor addition of new methods with JDK 1.2. However, there
have been some major additions in JDK 1.4.

Regular expressions have arrived with much fanfare in JDK 1.4, but the
melding of the java.lang.String class to the java.util.regexp package has
been less talked about. Four new regexp-based methods have arrived, with
their various overloads, to help enhance the String class.

The String.matches(String) method returns true if the current String
matches a given regular expression. For example:

“Music”.matches(“M.*”) returns true while
“Noise”.matches(“M.*”) returns false.

The String.replaceFirst(String, String) method replaces the first
instance of a regular expression with a replacement value and returns the
new
version of the String. For example:

“Small angry, angry kittens”.replaceFirst(“angry”, “fluffy”)

will give us:

“Small fluffy, angry kittens”.

We also have the replaceAll method, which is exactly the same except
that it will replace all the values. So we get:

“Small fluffy, fluffy kittens”.

The first argument to a replace method is a regular expression, while
the second argument is the replacement value. This replacement value may
contain references to captured values.

Lastly, we have the String.split(String) method, which turns a String
into an array of Strings, based on a common delimiter. The following code
shows how to split a line of comma-separated values:

String csv = “one,two, three,four, five”;
String[] fields = csv.split(“,\s*”);

The argument may be a regular expression, which allows the code in this
instance to ignore the white space characters.

The addition of regular expressions to Java is a long-awaited affair,
but the new helper methods in java.lang.String are an added bonus that
should reduce the regular expression learning curve.”

Object finalization and cleanup: How to design classes for proper object cleanup

“…By now you may be getting the feeling that you don’t have much use for finalizers. While it is likely that most of the classes you design won’t include a finalizer, there are some reasons to use finalizers.

One reasonable, though rare, application for a finalizer is to free memory allocated by native methods. If an object invokes a native method that allocates memory (perhaps a C function that calls malloc()), that object’s finalizer could invoke a native method that frees that memory (calls free()). In this situation, you would be using the finalizer to free up memory allocated on behalf of an object — memory that will not be automatically reclaimed by the garbage collector.

Another, more common, use of finalizers is to provide a fallback mechanism for releasing non-memory finite resources such as file handles or sockets. As mentioned previously, you shouldn’t rely on finalizers for releasing finite non-memory resources. Instead, you should provide a method that will release the resource. But you may also wish to include a finalizer that checks to make sure the resource has already been released, and if it hasn’t, that goes ahead and releases it. Such a finalizer guards against (and hopefully will not encourage) sloppy use of your class. If a client programmer forgets to invoke the method you provided to release the resource, the finalizer will release the resource if the object is ever garbage collected.”

Java finalize() method: if overridding finalize() it is good programming practice to use a try-catch-finally statement and to always call super.finalize(). This is a saftey measure to ensure you do not inadvertently miss closing a resource used by the objects calling class

Abstract classes vs. interfaces: When does it make sense to choose an abstract class over an interface? [source: javaworld]

“Abstract classes let you define some behaviors; they force your subclasses to provide others. For example, if you have an application framework, an abstract class may provide default services such as event and message handling. Those services allow your application to plug in to your application framework. However, there is some application-specific functionality that only your application can perform. Such functionality might include startup and shutdown tasks, which are often application-dependent. So instead of trying to define that behavior itself, the abstract base class can declare abstract shutdown and startup methods. The base class knows that it needs those methods, but an abstract class lets your class admit that it doesn’t know how to perform those actions; it only knows that it must initiate the actions. When it is time to start up, the abstract class can call the startup method. When the base class calls this method, Java calls the method defined by the child class.”