Generics shall risen again!

Here is a possible solution for cases in which some libraries that you depend upon and are not under your control (Spring, Apache Commons etc..) don't use generics (usually this is due to 1.42 backward compatibility), in such cases you'd usually write lines that might resemble something like this:

JdbcTemplate jdbcTemplate=new JdbcTemplate();
List⟨String⟩ result=jdbcTemplate.queryForList(/*query*/,/*params*/);

This code will result in unchecked assignment warning during compilation however the most annoying thing about it is that the IDE will not auto complete the generics types for us(=> more typing for us!).
My solution is based upon JRetrofit a framework that enables us to add interfaces to classes during runtime, first will create an interface that should contain all the commonly used JdbcTemplate methods:

public interface JdbcDynamicWrapper {
 List queryForList(String sql,Object[] args)throws DataAccessException;
}

And a factory method that will be used to get jdbcTemplate instances:

class JdbcTemplateFactory {
 public ⟨T⟩ JdbcDynamicWrapper⟨T⟩ getTemplateWraper(Class⟨T⟩ clazz){
  JdbcTemplate jdbcTemplate = new JdbcTemplate();
  return(JdbcDynamicWrapper⟨T⟩)
   Retrofit.partial(jdbcTemplate,JdbcDynamicWrapper.class);
 }
}

All that is left is to use the factory method:

JdbcTemplateFactory jdbcTemplateFactory=new JdbcTemplateFactory();
JdbcDynamicWrapper⟨String⟩templateWraper=jdbcTemplateFactory.getTemplateWraper(String.class);
List⟩String⟨ names=templateWraper.queryForList(/*query*/,/*params*/);

Now i know that this solution has its down sides (the need to add each method to the interface is one of them), but for methods which are very commonly used i think that its worth its price, don't you?

Dicsrete math & Java

In my Bachelor's degree i had the pleasure to study discrete math, discrete math handles group theory which address well hmm... groups :).
A group is a math entity that has a proper definition and a collection of operations which are operable on them such as: intersection, union, disjunction, subtraction.

At this point you must be thinking "well this all doesn't matter to us Java folks ..", well in fact we can think of Java collections and sets as groups (not exactly since we wont insist on a binary operation), thinking of them this way can result in some clean code implementation.
For example imagine that we need to find which changes were made to an arbitrary list of uniquely identifiable objects (list which are new, removed or old), the simplistic approach will look like:

public void printChanges(List older, List newer) {
for(Object value:older){
 if(newer.contains(value)){
  log.info(value.toString()+" is old");
 } else {
  log.info(value.toString()+" was removed");
 }
}

for(Object value:newer){
  if(!older.contains(value)){
  log.info(value.toString()+" was added");
 }
}
}

Its not the most elegant code since it contains loops and conditionals, in simple cases this might not be so bad but in more complex cases keeping trace on this kind of code is not easy, as for run time its about o(n).

Now lets see how the groups approach might work, our input consists of two object groups and we are seeking for three other groups that contain elements from these two, the most easy one to detect is the intersection of the two which match the old objects.
Finding the removed and the new is the same symmetric problem which is to find the objects that exists in one group but doesn't exist on the other, in groups lingo the operation that finds such objects is called subtraction.
Now lets take a look at the group oriented implementation:

//making use of org.apache.commons.collections
public void printChanges(Collection older, Collection newer) {
 final Collection removed = CollectionUtils.subtract(older, newer);
 final Collection added = CollectionUtils.subtract(newer, older);
 final Collection old = CollectionUtils.intersection(older, newer);
 log.info("removed: "+removed);
 log.info("added: "+added);
 log.info("old: "+old);
}

Its easy to see that this implementation is much more easy to follow since there are no loops or conditionals (code complexity is lower), as for runtime its also o(n).