Wednesday, April 16, 2008

Simple injection util

Dependency injection is really a mainstrem in today's Java Programming. There are entire Framework, that are based on it, like Spring, Google Guice or Picocontainer.
Also called inversion of control, this pattern helps to reduce dependecies and is especially useful in unit testing.

By the way, we'll now introduce a simple Utility class to inject instances of object at field level.
static public void injectField(Object objectToBeInjected, String fieldName,
Object objectToInject) throws NoSuchFieldException,
IllegalArgumentException, IllegalAccessException {
Class clazz = objectToBeInjected.getClass();
Field field = clazz.getDeclaredField(fieldName);
field.setAccessible(true);
field.set(objectToBeInjected, objectToInject);
}

This approach has a big disadvantage: it doesn't catch the attributes, that belog to superclasses, because of clazz.getDeclaredField(fieldName).
I thought that Class#getField(String) could help in this case but I was wrong, because this method retrieves recursively only the fields, which are public.

This article gives me the right solution, that is:
static public Field getDeclaredField(Object object, String name)
throws NoSuchFieldException {
Field field = null;
Class clazz = object.getClass();
do {
try {
field = clazz.getDeclaredField(name);
} catch (Exception e) { }
} while (field == null & (clazz = clazz.getSuperclass()) != null);

if (field == null) {
throw new NoSuchFieldException();
}

return field;
}


So in order to get the desired result, you can now use this implementation.

Thursday, April 10, 2008

toString() methods generation

If you want to generate quick a toString() method for your domain-objects, with all the attributes and relative values a good solution is the eclipse plug-in jutils.

Anyway, if your are doing some refactoring, there some probability that you will forget to add new or renamed fields to your toString() method... but don't care!
The people of GridGain have thought a very clever solution to this common issue.
You can simply write a generic impementation as follows
     @Override  
public String toString() {
return ToStringBuilder.toString(MySimpleClass.class, this);
}

to obtain the desired result.
Besides you have also the flexibility to exclude/include attribute or set the right order by using the following annotaions:

  • @GridToStringInclude Annotation This annotation can be attached to any field in the class to make sure that it is automatically included even if it is excluded by default.

  • @ToStringExclude AnnotationThis annotation can be attached to any field in the class to make sure that it is automatically excluded even if it is included by default.

  • @ToStringOrder(int) Annotation This annotation provides custom ordering of class fields. Fields with smaller order value will come before in toString() output. By default the order is the same as the order of field declarations in the class.

This ingenious approach can also be extended to generate XML or JSON rapresentation of a domain object.

Tuesday, April 1, 2008

SCBCD for Java EE 5

I'm very proud to comunicate your that since March 25, 2008 I'm a Sun Certified Business Component Developer (SCBCD) for the Java Platform, Enterprise Edition 5.

This is my Score Report (total score: 72%):
Section Analysis Score %
EJB 3.0 Overview 66%
General EJB 3.0 Enterprice Bean Knowledge 83%
EJB 3.0 Session Bean Component Contract & Lifecycle 85%
EJB 3.0 Message-Driven Bean Component Contract 75%
Java Perisitence API Entities 71%
Java Perisitence Entity Operations 80%
Persistence Units and Persitence Contexts 83%
Java Persistence Query Language 50%
Transactions 40%
Exceptions 80%
Security Management 75%

Java 6 support wildcards in classpath

With java 6 you don't need anymore to specify all jar files in classpath.
For example, if all your jar are in lib folder, you can start your program in a very simple manner:
java -cp lib/* MyClass

Besides, if your classes are in a directory named bin:
java -cp bin;lib/* MyClass

Take care: subdirectories are not searched recursively! That means, foo/* looks for JAR files only in foofoo, not in foo/bar, foo/baz, etc...