Generating JavaDoc with Eclipse or Maven

Generating JavaDocs is an integral part of every Java project and there are various options of generating the required documentation.

Option 1 :  Using Eclipse and JDK's JavaDoc tool.

This is the simplest option. If you are using Eclipse and have the path to the JDK (not JRE) set in the Eclipse > Windows Preferences > Installed JRE option set correctly (as shown in the screenshot below), Eclipse should be able to find the JavaDoc tool.

Set the path to your installed JDK

JavaDoc Tool in Eclipse

That's it. Clicking on the Javadoc option will bring up a wizard that will prompt you for the Destination folder for the generated JavaDocs. Apart from generating the JavaDocs, the tool will also create a stylesheet.css for the JavaDocs that can be edited if required.

Option 2 :  Using Maven and the JavaDoc plugin.

Add the plugin definition to your pom.xml

               
                
                     ...........
                  
                  org.apache.maven.plugins
                  maven-javadoc-plugin
                  2.9
                  
                    C:/javadoc/stylesheet.css
                     public
                  
                  
                
                  

In the snippet above, I have added the plugin definition and configuration to the build section. It can also be repeated in the section. This will allow me to run the Javadoc generation goal during the build cycle. I have also specified a path to a stylesheet file that will define the look and feel of the JavaDoc generated.

To generate the JavaDoc using Maven, use mvn javadoc:javadoc

More details on this option is available here.

Guava : Using Java Collections the Google Way

Recently Guava came out with release 14.0.1 which include a number of bug fixes and enhancements. As a utility library, Guava provides an impressive list of extensions and tools for using Java collections with an aim towards improving code readability, transparently managing Java collections and introducing useful checks and frequently used utility methods that simplify the generation of quality code.

With respect to Java Collections, Guava provides utility methods for creating Immutable collections, and provides some new Collections. If just looking for implementing various checks on your Java Collections, there are a number of Collection Utilities that allow you to create an equivalent Java Collection while writing code that is cleaner and easier to read.

For example, constructing a generic collection before Java 7 would amount to the following line of code:

• List list = new ArrayList();

In Guava, this could be simplied to  List list = Lists.newArrayList();

And this approach could be further extended to include the List size and initialise the List as follows:

• List list = Lists.newArrayList(100); // create a list with a 100 elements.
• List list = Lists.newArrayList("red","blue","green"); // create and initialise a list with some values

Similarly Guava has many utility methods for dealing with nulls in Collections, managing String and performing operations on the Java Math library that is not available in the JDK. If using the Apache Commons Library, Guava is definitely worth a check out !!

ZK 6.0 and the MVVM pattern

Previously I wrote about my experience in using ZK, an event driven UI framework that simplifies UI development for J2EE applications. Currently, the latest release of ZK is 6.5.1.2 which came out in December, 2012. The transition from version 5 to 6 was significant as it included a number of new features, including an upgrade in the jQuery library from 1.4 to 1.6, the use of Advanced templates, new controls and finally most notably among all these changes, the ability to use a new data binding approach called the ZK Bind which was based on the MVVM pattern.

While the MVVM pattern is not a new concept, its introduction in ZK is certainly timely and serves to simplify the development and maintainability of the user interface code. Since ZK is an event-driven framework, it has component which generate events and these in turn need to be handled by the controller which in turn lead to interactions with the model. In ZK 5, the model needed to know about the different components, which were generating events. In ZK 6.0, this layer of interaction has been made transparent  via an implementation of the MVVM pattern, which uses annotions in the ZUL and the model class to tie the components, their events and the model objects all together.

This example is a very simple introduction to the basic approach of using MVVM in ZK. As evident, in the ViewModel: HelloViewModel.java, there is no need for the model to know about the different components it needs to interact with as was the case in ZK 5. The annotations in the ZUL page and the model class wire the components, the events generated and the changes in the model all together without the need for any Java  code to be written.

While applying the annotations and the new approach in building UIs, might take some getting used to, there is no doubt that the implementation of the MVVM pattern using the Binder (ZK Bind) simplifies the UI development and code maintenance. It also provides a cleaner separation of the user interface from the business objects.

Being Agile : Should I be in a Scrum or work on a Kanban?

After having worked in the Scrum philosophy for several projects, I recently got the opportunity to experience the Kanban way of being Agile. While there are several common between the two flavours of Agile, the overall focus of the two modes is what is the biggest differentiators. In Agile, the focus is on the quantity of work that is delivered while in Kanban, the focus is more on quality.Kanban limits the work in progress with a goal of reducing multi-tasking and maximising output. When working in a Kanban system, the term Flow of Value describes how current work can give maximum returns.Measuring the output of Kanban teams is done in terms of an established Cadence that recognises the ability of a team to deliver high quality work consistently.

The following table gives some comparison points between the Scrum and the Kanban philosophies.

Scrum	Kanban
Focus is on quantity of work delivered in a sprint.	Focus is on quality of work delivered in a phase or cycle. There are no Iterations and the need for Estimations is not high.
New stories can be started while others are in progress.	Emphasis is given on completing in-progress stories with a priority for fixing bugs that come up in existing  stories.
Team members have clearly defined roles, such as Scum-Master, Product Owner.	No such roles are maintained.
Different meetings such as Pre-planning meetings and Retrospectives have significant bearing on the sprints	Meetings are called as and when required.

After 6 months of employing the Kanban approach, there were some immediate gains visible. Since there were no sprint failures, the morale of the team got a boost which in turn led to greater productivity. Since the WIP limits were strictly adhered to, there was some buffer time which gave rise to the opportunity to focus on creating more unit tests, upgrading to recent versions of developer tools or helping reduce bottle necks in am existing Kanban. While the idea of downing tools and not starting anything new might sound incredulous to a lot of people, slide 9 in this presentation comparing Kanban to Scrum gives a good guide on managing idle team members. Obviously the Kanban approach requires more discipline and trust among team members but if applied in the correct way, can help achieve some immediate goals.