Archive for the 'java' Category

Refactor-Safe passing of method names for callbacks

Published
by
Philipp Meier
on 2006-3-20
in java
. 0 Comments

Reflection is a very helpful tool for decoupling and avoiding marker interfaces. A common pattern for registering callbacks at the obersever pattern makes use of passing the callback method name as a String to a Observable:

The Observable class uses reflection to extract the method “onEvent” at runtime and will invoke it to notify Observable that an event occurred. This approach shows several advantages over the use of marker interfaces like java.util.Observer. First, no marker interface is needed, which decouples the code and depending on the effort put into the observer, the callback method must not be defined as strictly. E.g. the observer could even handle a signature like “void onEvent()” and simple do not pass any argument to the method.

Drawback of this approach is that the method name is passed to the Observable as String which makes refactoring your code harder and leads to nasty runtime errors. There is not check if the methods signature matches the signature which Observable expects. These errors won’t occur until the Observable will try to make a callback to the Observer.

Inspired by EasyMock 2.0 I found a way to extract a method name at runtime without invoking the method. Create a proxy with the Cglib bytecode manipulation library which records the method called on the proxy. Later on, the method can be used to register an Observer. I made the following, experimental code with Proxytoys and Cglib.

All small test shows how it should work:

As you can see, this one is refactor-safe because the name of the method isn’t used anymore.

The full power of this with the oberserver pattern:

I must admit that there is another solution to the problem of callback interfaces using anonymous inner classes, too:

This implementation which abstains of making Bar implement any Observer interface, suffers from the famous inner-class-breaks-security-problem (see entry at c2 wiki). The reflection based solution above uses an inner class only the extract the method name.

More stuff to read:

[updated and fixed broken comment form]

Group by logarithmic count in SQL

Published
by
Philipp Meier
on 2005-5-14
in java
. 0 Comments

The count() aggregate function in sql can be uses to get a histogram of the distribution of values in a table. Assume there is a table with customer data and you want to get a distribution of the distance to each customer:

select distance, count(distance)
from cust\_with\_dist
group by distance;

This will show the distance group be the exact values, which is not always desirable, f.e. when the dist column contains floating point data, this would yield the following result:

 distance | count
----------+-------
      0.0 |   142
      1.2 |   165
      5.5 |    24
      7.6 |    17
      8.3 |    11
      9.3 |    11
      9.4 |     6
...

Better would be to arrange the distance column in whole numbers:

select distance, count(distance)
from (select round(distance) as distance
           from cust\_with\_dist) as foo
 group by distance

This gives:

 distance | count
----------+-------
        0 |   142
        1 |   165
        6 |    24
        8 |    28
        9 |    17

Better for now, but if there is a large scale of values for the distance, e.g. 0 up to 1000km it dosn’t make sense to group the values from 100 to 200 into 1km intervals. A better grouping will be exponential or logarithmic grouping, e.g. into group up to 1, 10, 100, 1000km or 1, 5, 25, 125, 625km. This can be accomplished by transforming the dist column before grouping:

select dist, count(dist)
from (select round(pow(10,ceil(log(10,distance+0.0001))))
           as dist from cust\_with\_dist) as foo
group by dist

The distance is added 0.0001 to prevent log(0) exceptions, by using the ceil() function the data is grouped into intervals “up-to”, the floor() function would give “as least”. The result is

 dist | count
------+-------
    0 |   142
   10 |   235
  100 |   111
 1000 |     7

If you exchange “10″ by “5″ you’ll get distances intervals of 0, 5, 125, 625 and so on.

EJB 3.0 Annotations Cheat Sheet

Published
by
Philipp Meier
on 2005-5-13
in java
. 15 Comments

Update: The Annotations Cheat Sheet got it’s own page here

I just made Version 1.0 of my EJB 3.0 Annotations Cheat Sheet - just download it from here as pdf or OpenOffice Document. I’d greatly appreciate any feedback about errors and possible improvements. The sheet is based on the EJB 3.0 early draft 2.

Preview of cheat sheet.

Update

Version 1.1 contains some formatting cleanup and fixes some typos. Thanks to Emmanuel Bernard for pointing out the typos. I checked the EJB 3.0 Peristence edr 2 but it reads that all collections except many-to-many are fetched EAGER by default. The links above were updated accordingly.

Second Update

Fixed broken links.

jga: Now, I see a use for 1.5 static method imports

Published
by
Philipp Meier
on 2005-3-28
in java
. 0 Comments

For quite some time I’ve considered the static method import in java 1.5 rather useless and only usefull for lazy programmers who wanted to avoid typing “java.text.” in front of “NumberFormat”. The page
jga: using the java 1.5 forloop shows an application of jga’s generic functor objects. By making use of the static import feature the code is actually very easy to read and reminds me more of perl than of java:


for(PlantType f : unique(transform(fruitsByType, getType))) {
System.out.println(f);
}

The same code without static method import would lead to either artificially short method and class names or make the code unreadable:


for(PlantType f : Algorithms.unique(Algorithms.transform(fruitsByType, getType))) {
System.out.println(f);
}

Like every powerful feature, also static method import is tempting and likely to be over-used. Nevertheless it solves today’s problems.

Another example where static method import helps is JUnit. The Assert class wich provides a nice set of assert helper methods is extended by the TestCase class which all Test classes have to extend. This is annoying because JUnit dictates a implementation hierarchy just to have the possibility of calling assertEquals instead of Assert.assertEquals. The static import of all methods in Assert which are needed decouples the tests’ implementation hierarchy from the testing framework. TestNG, an alternative Java testing framework, is free from this coupling and relies on static method import. Please note that you can still extend the Assert class to your test case class if you dislike static method import or it’s not available.

Updated the 2nd example according the the comment received from “Complex Lex”.

Use static method to initialize classes before super class constructor is called.

Published
by
Philipp Meier
on 2005-1-19
in java
. 0 Comments

Java does not allow to call any method before linking super() in a constructor for good reasons. Sometime this limitation hurst. Consider to the following case: In a subclass of a hypothetical class Message you want to mangle the message before using the super constructor. The following fails:


public class BrokenSpecialMessage extends Message {
public BrokenSpecialMessage(String name) {
Calendar cal = Calendar.getInstance();
cal.roll(Calendar.DAY_OF_YEAR, -1);
String newName = MessageFormat.format(
"Yesterday at {0,date}, the message {1} was created",
new Object[]{cal, name});
super(”At ” + newName);
}
}


/java/BrokenSpecialMessage.java
Error: line (11) Message(java.lang.String) in Message cannot be applied to ()
Error: line (17) call to super must be first statement in constructor

This is annoying because beside this simple case the “pre”-super logic cannot be collapsed into a easy statement. The solution is to use a static class method:


class SpecialMessage extends Message {
public SpecialMessage(String message) {
super("At " + formatMessage(message));
}

private static String formatMessage(String name) {
Calendar cal = Calendar.getInstance();
cal.roll(Calendar.DAY_OF_YEAR, -1);
String newName = MessageFormat.format(
“Yesterday at {0,date}, the message {1} was created”,
new Object[]{cal, name});
return newName;
}

}