Detect Cycle Dependency with JDepend4Eclipse

September 27th, 2008 thiamteck Posted in Eclipse, Java No Comments »

Cycle dependency among packages is dependency among package where 2 or more packages depend on each other. For example, package A depend on package B, while package B also depend on package A. Another exaple is package A depend on package B, package B depend in package C, package C depend on package A.

The cycle dependency is often undesire as it increase coupling among packages.

JDepend is a tool to generate metrics based on package dependencies. While JDepend4Eclipse is the Eclipse plugin for JDepend.

Using this plugin, you can identify the dependency cycles easily. Below is the screen:

AddThis Social Bookmark Button

Java Logging Wrapper with Static Binding – SLF4J

September 16th, 2008 thiamteck Posted in API, Java 2 Comments »

When think of logging wrapper for Java, I believe Apache Common Logging come in to most developers mind. Even if you don’t use it, the API/framework you use are very likely depend on it.

It able to auto discover your actual implementation, with the cost of complexity. The class loader and reflection based dynamic binding might behave unexpectedly in different application servers.

Why spend long time to understand a logging wrapper since it is never the main concern of your application?

Just switch to SLF4J – “Simple Logging Facade for Java”. As its name imply, it try to be simple instead of act smart with those class loading hack. It support for log4j, common-logging, Java util logging, Logback, etc.

If you code with SLF4J, your code will typically look like this:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Toolbox{
	Logger logger = LoggerFactory.getLogger(this.getClass().getName());

	public helloWorld(){
		logger.info("Hello World");
	}
}

All you need to do is place the SLF4J API jar file (slf4j-api-1.5.2.jar), your logging implementation jar file (said log4j.jar), and SLF4J adapter for the logging platform of your choice (slf4j-log4j12-1.5.2.jar) into your classpath. And It is done.

If you would like to change to Java util logging, just delete the ‘slf4j-log4j12-1.5.2.jar’, and place the adapter for Java util logging (‘slf4j-jdk14-1.5.2.jar’) into your classpath. And it will work perfectly without recompile. The only things to watch out is: there should always be only one adapter in classpath.

Besides adapter for different logging API, SLF4J also come with a set of bridge for various logging API. Said you have use an API that depend Apache Commons Logging, your application is code with log4j. And you would like to use Java Util logging as actual logging implementation.

The steps are as simple as 123:
1) Delete the common-logging and log4j jar file from classpath, place the bridging jar file (jcl-over-slf4j-1.5.2.jar, log4j-over-slf4j-1.5.2.jar) into classpath
2) Place SJF4J API (slf4j-api-1.5.2.jar) into classpath
3) Place adapter for Java util logging (‘slf4j-jdk14-1.5.2.jar’) into classpath

All call to common-logging and log4j will be intercepted by SLF4J and pipe to Java util logging. And all is done with just static binding.

For those who curious on how it can be done, I will suggest you to open the bridging and adapter jar file to have a look. It is really a good real world example of mock classes and adapter pattern.

AddThis Social Bookmark Button

FindBugs – One Click Java Source Code Review

August 30th, 2008 thiamteck Posted in Java No Comments »

Having code review is good to identify overlooked bad practice that lead to future problem. But the cost is high and the benefit is very dependent on the skill level of the person who review the code.

FindBugs logo So what about have a software to do it for you? FindBugs is the answer. As the name imply, FindBugs is focus on identified bugs pattern.

FindBugs will inspect the Java code that don’t break you program today, but open a chance for defect in future. Besides those well known example of override equals() must also override hashCode(), an example of such code might be as simple as 3 line of codes below:

public void setBirthday(java.util.Date aBirthday){
this.birthday = aBirthday;
}

It is just a setter, how can this code cause a bug? FindBugs answer for this is: “EI2: May expose internal representation by incorporating reference to mutable object (EI_EXPOSE_REP2)”. And this is the explanation:

This code stores a reference to an externally mutable object into the internal representation of the object. If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Storing a copy of the object is better approach in many situations.

And the complete list of bugs pattern is having 339 items as in version 1.3.5-rc1, you may check it out here.

FindBugs also cac be integrated into Eclipse as an Eclipse plugin. Just follow the simples steps in the manual and you will get it work in your Eclipse within few minutes.

AddThis Social Bookmark Button