ADF Faces vs JSF (Taskflows)

You might be familiar with the term ADF; it stands for Application Development Framework. It is a framework by Oracle that simplifies application development, while enjoying all the best practices and standards built into the framework. I would put it in this way: if you want to create the same productive application using another technology stack/framework, you may need to code a whole lot more for it.

In fact, ADF Faces is built on top of JSF standard framework (JSR-127), while offering a whole lot more functionality and improvements to it such as new UI components and simplifies web development. However, some people felt that the learning curve is too steep for ADF, especially the ADF BC (business components). That itself can be another post of its own. In this post, I shall focus on the differences between ADF Task Flows and JSF Task Flows.

JSF Page Flow	ADF Task Flow
The entire application must be represented in a single page navigation file (faces-config.xml). Although you can have multiple copies of faces-config.xml in a project, the application loads these files as one at runtime.	The application can be broken up into a series of modular flows that call one another.
All nodes within a JSF page flow must be JSF pages. No other types of objects can exist within the JSF page flow	You can add to the task flow diagram nodes such as views, method calls, and calls to other task flows
Navigation is only between pages	Navigation is between pages as well as other activities, including routers
Application fragments cannot be reused	ADF task flows are reusable within the same or an entirely different application. After you break up your application into task flows, you may decide to reuse task flows containing common functionality
No shared memory scope between multiple requests except for session scope	Shared memory scope (for example, page flow scope) enables data to be passed between activities within the task flow. Page flow scope defines a unique storage area for each instance of an ADF bounded task flow
Can be converted to an ADF taskflow	Cannot be converted back to JSF Page Flow

Source: http://docs.oracle.com/cd/E23943_01/web.1111/b31974/taskflows.htm

Best Practices for Software Version Control

This post contains some of the best practices for using version control systems in your project (for ease of reference, I shall refer to it as SVN). As a software developer, you will almost definitely used one of the variants of version control systems (e.g. JDeveloper's SVN plugin, TortoiseSVN..), thus good version control practices are as important as good programming practices. The recommendations listed in this wiki are by no means exhaustive, but the principles should easily transfer to other systems as well.

Here are 3 tips:

1. Commit often and in logical chunks

The basic work cycle is always update your working copy before doing any changes to files. By doing “update to head”, resolve any conflicts, run a build and make sure there are no failures before checking in code. In general, it is preferred to commit changes in logical chunks. This means that changes that belong together should be committed together, changes that don't shouldn't.

If many code changes are done to a project at the same time, split them up in to logical parts and commit them in multiple sessions. This makes it much easier to track the history of individual changes, which will save time when trying to find and fix bugs or doing code reviews.

2. Write meaningful commit comments

Although often under-utilised, comments should be brief but detailed enough to describe what was changed. If several changes were made, write one line or sentence about each part. If the list of changes gets too long, consider splitting the commit into smaller parts. Otherwise, it can be problematic when code commits are not fine-grained, e.g. submit a week's worth of changes to multiple modules in a large pile. Thus, comments can be very useful to distinguish trivial from non-trivial changes in the repository.

Prefix your comments with Identifiers

Prefixing commit comments with identifiers is a good way to indicate the type of change made. It also allows easier filtering of content later when we do code reviews.

Identifier	Indication
FIX	Issue fixes / Improvements
ADD	Change Requests / New files
REMOVE	Delete files
TEST	Add/remove logs for debugging purposes
DOCS	Documentation only changes e.g. code comment
STYLE	Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)

Reference the Bug ID

If the change is about fixing a specific bug, do reference the bug number in the commit message (assuming your project has some sort of bug tracking database or system).

3. Do all file operations in SVN

Whenever there is a need to copy, delete, move or rename files or folders in the repository, do so using the corresponding file operations in the version control system. If this is done only on the local file system, the history of those changes will be lost forever.

Conclusion

Consider giving the above suggestions a try, you might like it. Please share your thoughts and feel free to add on to the list of best practices too. If you are interested in more practices on working with SVN, this is a recommended book:

Version Control with Subversion, by Ben Collins-Sussman, Brian W. Fitzpatrick and C. Michael Pilato

ConcurrentHashMap over Hashtable for cache lookup

A Legacy Class?

Hashtable is a legacy class before Java Collections Framewpork (JCF) was introduced. The synchronized methods of Hashtable obtain lock on the entire hashtable object during any retrieval or update operations. This can lead to increased response time under heavy load and impacts performance.

A better alternative?

Java SE 5 introduced ConcurrentHashMap, a map implementation which provides better concurrency and scalability as compared to Hashtable. Since the underlying data is stored in a series of buckets in a hashmap (note that a hashtable is also a hashmap implementation), it would be more efficient to lock only a bucket while accessing a map instead of obtaining lock on the entire map.

In other words, ConcurrentHashMap uses this mechanism which provides multiple bucket locks and reduces lock contention when multiple threads access a ConcurrentHashMap object concurrently. This improves performance over a Hashtable, especially in a highly concurrent system.

Multiple internal buckets of ConcurrentHashMap 

Simple Benchmark (in milliseconds)

Hashtable
Cache put (100,000 objects): 626.8
Cache get (100,000 objects): 0.45
Cache put (500,000 objects): 3,544.6
Cache get (500,000 objects): 0.47

ConcurrentHashMap
Cache put (100,000 objects): 501.2
Cache get (100,000 objects): 0.22
Cache put (500,000 objects): 3,159
Cache get (500,000 objects): 0.24

Summary

In summary, both classes are thread-safe. In terms of performance, ConcurrentHashMap also performs better than HashTable with improvements in object put/get in/from cache. Developers should consider replacing usage of Hashtable with ConcurrentHashMaps in projects to improve performance and efficiency.

Double alternatives for precise arithmetic

We sure have used double data type in our programming while performing simple or complex arithmetic calculations. Doubles tend to be good enough for most applications (not involving money of course), because if you are dealing with money, you need exact precision. 

Consider this:

double first = 2.00; 

double second = 1.10; 

System.out.println(first - second);

The result?

0.8999999999999999

The problem comes when double suffers from a "loss of precision" and becomes very noticeable when working with either very big numbers or very small numbers. You may be tempted to use print formatting to set the precision in terms of decimal placings, but that still do not solve the root issue.

Especially for monetary-critical applications, (i) you may want to consider using BigDecimal as it is an exact way of representing numbers. With BigDecimal this would not happen. (ii) use int or long to represent cents.

1. Using BigDecimal

Example

BigDecimal first = new BigDecimal("2.00"); 

BigDecimal second = new BigDecimal("1.10"); 

System.out.println(first.subtract(second));

Returns 

0.90

When using BigDecimal, note that it'll take up more memory, creates more garbage and is probably slower for most operations, as compared to using primitive types.


2. Using int or long

Example

System.out.println((200 - 110) + " cents");

Returns

90 cents 

In summary, avoid floating point calculations (e.g. float, double) when working with monetary or precision-critical applications. Consider greatly the use of int, long or BigDecimal instead.