Maven 3.0 was just released and the Java build tool has come a long way since version 2 was released almost six years back. Maven 2 had reached a stage where it was difficult to extend and its code was difficult to understand. In version 3.0 many of the Maven internals have been revamped to overcome all the issues associated with Maven 2. In this article, I run down the top 10 features in Maven 3.
Reduce Boilerplate Code for DAO’s — Hades Introduction
Most web applications will have DAO’s for accessing the database layer. A DAO provides an interface for some type of database or persistence mechanism, providing CRUD and finders operations without exposing any database details. So, in your application you will have different DAO’s for different entities. Most of the time, code that you have written in one DAO will get duplicated in other DAO’s because much of the functionality in DAO’s is same (like CRUD and finder methods).
One of way of avoiding this problem is to have generic DAO and have your domain classes inherit this generic DAO implementation. You can also add finders using Spring AOP; this approach is explained Per Mellqvist in this article. There is a problem with the approach: this boiler plate code becomes part of your application source code and you will have to maintain it. The more code you write, there are more chances of new bugs getting introduced in your application. So, to avoid writing this code in an application, we can use an open source framework called Hades.
Speed up your build with Maven 3
I have been trying to find ways to make my project’s maven build run fast. It is very frustrating and annoying when your project’s full build takes 12 minutes to complete. It does not happen too often in a day because you work at module level, but 2-3 times a day you need to build the full project and if your build takes this long, it really slows you down. These days builds take a lot of time because you embed all sorts of plugins in your build like checkstyle, findbugs, cobertura (It is evil because it run your test twice), etc. Although, It does give you time to have coffee but 12 minutes is way too much. So, I was really pissed off.
Few days back I was checking my tweets and found out that Maven is releasing its new version and it will have some performance improvements. Maven 3 is the latest version of maven which is expected to be released today. So, I decided to play with it. I downloaded the beta version of Maven 3, changed my windows path system variable to point to Maven 3 and ran a mvn clean install on my project. Without any build failures or other problems, the build just ran fine. I have heard that when Maven 2 was released people had hard time migrating from version 1 to 2 as it was not backward compatible. But Maven 3.0 is completely backward compatible and most of the plugins will also work fine. To my surprise, the build took 9 minutes. This is still a high number but it was way better than 12 minutes. Seeing this decrease in build time motivated me to read more about Maven 3.
After reading some blogs and watching Jason Van Zyl presentation, I found out that there are lot of new features in Maven 3. One of the new features in Maven3 is Parallel Builds. Parallel build analyzes your project’s dependency graph and schedule modules that can be run in parallel. This is a very cool feature and it really sped up the build. To run a paralled build, you can type
mvn -T 4 clean install mvn -T 2C clean install
The first command will run your build with 4 threads and second command will build your project with 2 threads per core. How fast your build will become, depends a lot on your project/build structure, how your unit tests are distributed in modules so it may vary from project to project. For my project with 4 threads, the build time got reduced to under 6 minutes, which I think is great. You should try out some combination with number of threads or number of threads per core to find out the best possible combination for your project. I am very happy that build time of my project got reduced to almost half.
In his presentation, Jason Van Zyl talks a shell based tool called Maven Shell which can also further improve the performance. Maven Shell is maven embedded in a long lived shell process. It does not comes bundled with maven 3 so you have to download it from http://shell.sonatype.org/. I tried running my project build inside Maven Shell but it gives PermGen space error all the time. I tried changing the perm gen memory setting but it didn’t helped. Maven shell is expected to run much fast because it caches the parsed POMs.
Maven 3 is definitely worth spending time so have a look at it. I have just touched the tip of iceberg , there are lot of new features in Maven 3. I will try and talk about others in my future blogs.
Creating Application using Spring Roo and Deploying on Google App Engine
Spring Roo is an Rapid Application Development tool which helps you in rapidly building spring based enterprise applications in the Java programming language. Google App Engine is a Cloud Computing Technology which lets you run your application on Google’s infrastructure. Using Spring Roo, you can develop applications which can be deployed on Google App Engine. In this tutorial, we will develop a simple application which can run on Google App Engine.
Read more
Pragmatic look at Method Injection
Intent
Method injection lets container inject methods instead of objects and provides dynamic sub classing.
Also Known As
Method decoration (or AOP injection)
Motivation
Sometimes it happens that we need to have a factory method in our class which creates a new object each time we access the class. For example, we might have a RequestProcessor which has a method called process which takes a request as an input and returns a response as an output. Before the response is generated, request has to be validated and then passed to a service class which will process the request and returns the response.As can be seen in the code below we are creating a new ValidatorImpl instance each time process method is called. RequestProcessor requires a new instance each time because Validator might have some state which should be different for each request.
public class RequestProcessor implements Processor { private Service service; public Response process(Request request) { Validator validator = getNewValidatorInstance(); List<String> errorMessages = validator.validate(request); if (!errorMessages.isEmpty()) { throw new RuntimeException("Validation Error"); } Response response = service.makeServiceCall(request); return response; } protected ValidatorImpl getNewValidatorInstance() { return new ValidatorImpl(); } }
RequestProcessor bean is managed by dependency injection container like spring where as Validator is being instantiated within the RequestProcessor. This solution looks like ideal but it has few shortcomings :-
- RequestProcessor is tightly coupled to the Validator implementation details.
- If Validator had any constructor dependencies, then RequestProcessor need to know them also. For example, if Validator has a dependency on some Helper class which is injected in Validator constructor then RequestProcessor needs to do know about helper also.
There is also another approach that you can take in which container will manage the Validator bean(prototype) and you can make bean aware of the container by implementing ApplicationContextAware interface.
public class RequestProcessor implements Processor,ApplicationContextAware { private Service service; private ApplicationContext applicationContext; public Response process(Request request) { Validator validator = getNewValidatorInstance(); List<String> errorMessages = validator.validate(request); if (!errorMessages.isEmpty()) { throw new RuntimeException("Validation Error"); } Response response = getService().makeServiceCall(request); return response; } protected Validator getNewValidatorInstance() { return (Validator)applicationContext.getBean("validator"); } public void setApplicationContext(ApplicationContext applicationContext) throws BeansException { this.applicationContext = applicationContext; } public void setService(Service service) { this.service = service; } public Service getService() { return service; } }
This approach also has its drawback as the application business logic is now coupled with Spring framework.
Method injection provides a better way to handle such cases.Method injection is an injection type in which methods are injected instead of objects. The key to Method injection is that the method can be overridden to return the another bean in the container.In Spring method injection uses CGLIB library to dynamically override a class.
Applicability
Use Method injection when
- you want to avoid container dependency as we have seen in the second approach, in which you have to inject a non singleton bean inside a singleton bean.
- you want to avoid subclassing. For example, suppose that RequestProcessor is processing two types of response and depending upon the the type of report , we use different validators. So, we can have subclass RequestProcessor and have Report1RequestProcessor which just provides the Validator required for Report1.
public class Report1RequestProcessor extends RequestProcessor { @Override protected Validator getNewValidatorInstance() { return new ValidatorImpl(); } } public abstract class RequestProcessor implements Processor { private Service service; public Response process(Request request) { Validator validator = getNewValidatorInstance(); List<String> errorMessages = validator.validate(request); if (!errorMessages.isEmpty()) { throw new RuntimeException("Validation Error"); } Response response = getService().makeServiceCall(request); return response; } protected abstract Validator getNewValidatorInstance(); public void setService(Service service) { this.service = service; } public Service getService() { return service; } }
Implementation
Method injection provides a cleaner solution. Dependency Injection container like Spring will override getNewValidatorInstance() method and your business code will be independent of both the spring framework infrastructure code as well as Concrete implementation of Validator interface. So, you can code to interface.
public abstract class RequestProcessor implements Processor { private Service service; public Response process(Request request) { Validator validator = getNewValidatorInstance(); List<String> errorMessages = validator.validate(request); if (!errorMessages.isEmpty()) { throw new RuntimeException("Validation Error"); } Response response = getService().makeServiceCall(request); return response; } protected abstract Validator getNewValidatorInstance(); public void setService(Service service) { this.service = service; } public Service getService() { return service; } }
The method requires a following signature
<public|protected> [abstract] <return-type> methodName(no-arguments);
If the class does not provide implementation as in our class RequestProcessor, Spring dynamically generates a subclass which
implements the method otherwise it overrides the method. application-context.xml will look like this
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd"> <bean id="service" class="com.shekhar.methodinjection.ExampleService" /> <bean id="requestProcessor" class="com.shekhar.methodinjection.RequestProcessor"> <property name="service" ref="service"></property> <lookup-method bean="validator" name="getNewValidatorInstance"/> </bean> <bean id="validator" class="com.shekhar.methodinjection.ValidatorImpl" scope="prototype"> </bean> </beans>
This is how method injection can be used in our applications.
Consequences
Method injection has following benefits:
1) Provides dynamic subclassing
2) Getting rid of container infrastructure code in scenarios where Singleton bean needs to have non singleton or prototype bean.
Method injection has following Liabilities :
1) Unit testing – Unit testing will become difficult as we have to test the abstract class. You can avoid this by making the method which provides you the instance as non-abstract but that method implementation will be redundant as container will always override it.
2) Adds magic in your code – Anyone not familiar with method injection will have hard time finding out how the code is working. So, it might make your code hard to understand.
Hope this helps you understand Method Injection. It is useful in specific cases as covered in this article.
Applying Design Patterns with Java Enums
Over the weekend I was reading about Enum – a Java 5 feature which we normally use to define a set of constants like Month
public enum Month { JANUARY(1), FEBRUARY(2), MARCH(3), APRIL(4), MAY(5), JUNE(6), JULY(7), AUGUST(8), SEPTEMBER(9),OCTOBER(10),NOVEMBER(11),DECEMBER(12); private int monthIndex; private Month(int monthIndex) { this.monthIndex = monthIndex; } public int getMonthIndex() { return this.monthIndex; } }
While reading about enums I was thinking that when enums have all the capabilities to be like a class then why we only use enums for defining constants. Most of the time we don’t even add any new method to the enum and we just use the default methods provided in an enum. Enum have default methods like name(),ordinal(), valueOf() etc because every enum extends a class called java.lang.Enum which has these methods.
In this blog, I will discuss how different design patterns can be used with enum.
Using enum for implementing Singleton – A Singleton ensures that a class has only one instance, and provide global point of access to it. Normally we create a singleton by making the constructor private and then exposing the instance either through static final member or exposing it through a static method like getInstance(). I will take an example of factory like SessionFactory because factories are mostly implemented as Singleton because an application typically needs one instance of a SessionFactory.
public class SessionFactory { public static final SessionFactory SESSION_FACTORY = new SessionFactory(); private SessionFactory() { } public void doSomething() { System.out.println("I am doing something"); } }
public class SessionFactory { private static final SessionFactory SESSION_FACTORY = new SessionFactory(); private SessionFactory() { } public static SessionFactory getInstance(){ return SESSION_FACTORY; } public void doSomething() { System.out.println("I am doing something"); } }
The above two approaches to create singleton can broke if your SessionFactory class is Serializable, as it is not sufficient merely to add implements Serializable to its declaration. Each time a serialized instance is deserialized, a new instance of SessionFactory will be created. In order to avoid this, you should declare all instance fields transient and provide a readResolve method (readResolve method allows a class to replace/resolve the object read from the stream before it is returned to the caller ) .
private Object readResolve() { return SESSION_FACTORY; }
From Java 5 onwards, there is a new approach for implementing Singleton i.e. using enums.
public enum SessionFactory { SESSION_FACTORY; public void doSomething() { System.out.println("I am doing something"); } }
Using this approach, you don’t have to worry about serialization problems as enums (are serializable by default) handles it for you. This approach is more cleaner and is considered to be the best way to implement a singleton. Use this approach next time you need to implement a singleton.
Using enums for strategies : The Gang of Four definition of Strategy pattern is ” Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it”. Suppose, we are adding Validation logic in our application and you have different validation rules which can be applied. So, we can have one interface called ValidationRule interface (which defines different validation rules or strategies)
interface ValidationRule { void validate(input,result); }
and then we define two validation rule strategies called Rule1 and Rule 2 which implements ValidationRule interface.
class Rule1 implements ValidationRule{ public void validate(input,result){ [business logic here .....]; } } class Rule2 implements ValidationRule{ public void validate(input,result){ [business logic here .....]; } }
Then we inject a list of ValidationRule strategies into a Validator class using spring dependency injection.
class Validator { ValidationResult result; List<ValidationRule> rules; public void setRules(List<ValidationRule> rules){ this.rules=rules; } public ValidationResult validate(input){ for(ValidationRule rule:rules){ rule.validate(input,this.result); } } }
<bean id="validator"> <property name="rules"> <list> <bean class="com.shekhar.business.rules.Rule1"/> <bean class="com.shekhar.business.rules.Rule2"/> </list> </property> </bean>
This was one way of using strategies with normal Java classes and interfaces.
In the second approach, Instead of making Rule1 and Rule2 as classes we can make them as enums.
enum Rule1 implements ValidationRule { Rule1; public void validate(input,result) { // business logic } } enum Rule2 implements ValidationRule { Rule2; public void validate(input,result) { // business logic } }
You can also inject the enums using spring like this.
<bean name="validator" class="test.Validator"> <property name="rules"> <list> <ref bean="rule1"/> <ref bean="rule2"/> </list> </property> </bean> <bean id="rule1" class="test.Rule1" factory-method="valueOf"> <constructor-arg> <value>RULE1</value> </constructor-arg> </bean> <bean id="rule2" class="test.Rule2" factory-method="valueOf"> <constructor-arg> <value>RULE2</value> </constructor-arg> </bean>
The enum bean created by spring will always be a singleton whether you define a bean as singleton or prototype because enums are singleton.
The enum strategies approach can have advantage over the class strategies approach if you want to persist the strategies into the database using an ORM like hibernate that has support for java enum.
Using enum with template methods : The enum Rule1 and Rule2 can be moved to a single enum called ValidationRules which will define a template method called validate which all the defined set of instance will implement.
public enum ValidationRules { RULE1(){ @Override public void validate() { } }, RULE2(){ @Override public void validate() { } }; // template method public abstract void validate(); }
As you can see we have defined a template method called validate and both the instances RULE1 and RULE2 are providing an implementation of this method.
Running Java Control Panel through command line in Windows Vista
Today, I was wondering how I can run java control panel on my windows vista machine using command line.
To run it, Go to command line and run command
javaws -viewer
New Java Puzzler Found while reading Java Puzzler book
Today, while solving puzzles from Java Puzzler book I myself created a new Java Puzzle. So, in this blog I am writing about that puzzle.
Puzzle
Will the code given below results in an infinite loop.
public class MyJavaPuzzle { public static void main(String[] args) { Double i = Double.NaN; while(i != i){ System.out.println("Infinite Loop"); } } }
Solve this puzzle and have fun. Happy Puzzling!!!
Post your answer and explanation in comments.
What we should not write on company’s blog?
These days organization expects their employees to write blogs/publish articles so that the organization gains more visibility. I believe blogs are a very good way by which you can gain more popularity and visibility in the developer’s community. But I see lot of blogs published on company’s official blog as developer’s personal experience or personal learning. These blogs lack the content and value as expected from a company blog. People just write the blog for the heck of writing it.
In my opinion writing such blogs does not increase the organization visibility.There should be a difference between what you should write in your personal blog to what you should write in an organization blog.
The blogs that you should write on a personal blog rather than on company blog are:-
1) Hello World blogs = These type of blogs does not provide any value as you can find such blogs all over the web. They just contain a very basic explanation of the concept or framework with or without a Hello World program. These blogs have one characteristic that the person who wrote this blog will also never read it again.
2) Opinionated blogs = These type of blogs contain your opinion about a topic, concept or an event. Writing opinionated blogs is not bad but
if you are writing your opinion on the company’s blog then it in a way represent your organization opinion also. So, when ever you write an opinionated blog, please match it with your organization values.
3) Blog with links to other blogs/articles= These blogs does not have any content of their own they just point to other links (video or text).
These are some of the types of blogs that should not be written on an official blog. Company’s blog should have good content and quality should matter over number of blogs published. Please post in your comments on what you think.
Reasons for incompetent software developers in India
Reasons for incompetent software developers in India
Most of the times, I have heard that Indian developers don’t have the quality as compared to their counterparts who are working in western countries. Development teams in western countries often blame their offshore counterparts for slowing them down. It has been said that Indians are not technically competent; write poor code, they don’t give any suggestions for the problems, etc.
In my opinion, most of these are true. Yes, we are not at par with developers in western countries and we sometimes really suck. Please note that this is just my personal opinion and not all software developers in India are bad. It’s the problem of quantity versus quality. In this blog, I will be putting up some reasons why I feel Indians developers lag behind developers from other countries.
Reasons
- Developer by chance not by choice = In India anybody can become a software developer whatever his/her qualification is. I, myself, was a mechanical engineer, but in the college campus was recruited by a Software company so I ended up becoming software developer. Likewise I have so many friends who become software developer by chance. Most of the college students who join any Software company does not know anything about software development or have any knowledge about programming.
- College education does not help = I have graduated from one of the good college in India but I can tell you one thing that the quality of education in India is very poor whichever college you get graduated from. In India, importance is given to marks than to practical learning, students just cram the things and get score but practically they know nothing. I recently interview a guy who had close to 6 years of experience, graduated from a good college in Computer Science with a very high percentage, was not able to write a Fibonacci series program.
- Developers don’t keep themselves updated = If you ask a developer which last technical book you read or how you keep yourself updated, most of the times you will not get any answer. Nobody wants to learn or improve themselves. Whenever I get a chance to speak to developers I ask which last technical book they have read 99% of the time answer is either none or Head First SCJP book.
- Everybody wants to become a manager = In India you can become team leader at 5 years of work experience. Once you become team leader, your next goal is to become manager and for becoming manager you need to be good at giving your work to others, doing dirty politics, and most important doing nothing. So, you can see, we do not know anything about programming when we enter the software development world and at an experience of 5 years most of the developers start thinking about becoming manager. Last week I was giving Java 8 training to a set of developers with average experience of less than 4 years and I asked a question how many of you think you will be coding 5 years down the line. No one raised their hand. I was shocked to see this.
- No contribution to open-source community = I don’t know any of my friends or friends of friends including me who has contributed to open-source community. We can only use the open-source project and if we find any bug in the project we will never fix it but blame the developers who wrote the code.
There can be more reasons but at this point of time I can think of these 5 only. I am trying to make myself a better developer by reading, writing, listening. Tell me what you guys think?