An open letter to Thoughtworks Tech Radar Team

Dear Thoughtworks Radar Team,

I attended your Tech Radar webinar this Tuesday. Its a great iniative from your side to come up with something like and sharing it with the rest of the world. I would like to share some of my thoughts on the same.

• One hour to cover all the quadrants was very less. Because of this, you had to rush through some points and there was very less time for Q&A. I know this is a free webinar and you are putting in a lot of effort and money into imparting your research and learning to the outside world. However, it would be great if you have it as a 4 or 2 part webinar covering either 1 or 2 quadrants respectively.
• In the techniques section, I feel we need to include 'Application Security as a first class citizen' on par with performance test. A security flaw in an application is the most embarrassing moment for any organization. Most of the times, they are implicit in the user stories. It is the duty of the development team to identify, test and code them as early as possible. I would like to know if you guys are using any tool for this specifically apart from including it in your Functional testing.

On the good side, there were a lot of take away for a developer like me. A lot of new ideas were presented; some of the holds category made a lot of sense after listening and reading through them thereafter. I'm eagerly looking forward for the next edition.

Yours truly,
A Developer still learning.

PS: For others, here's the link to their radar.

Upgrade to Play 2.0? - Not now

What is the first thing for a seasoned Java developer to leave Spring/J2EE and move to something cool like Play? Of course, its easy setup and improvement in productivity. When I tried play 1.x series, I was very happy. After a few months, I recommended and used it for one of our internal projects and also successfully hosted it to heroku. It had matured a lot with new and useful modules.

Then saw the announcement of Play 2.0 which was completely being rewritten in Scala. As every other person, I too was excited about it and the twitter feed was full of praise once its released. And add on top of it, its inclusion in the Typesafe stack that created more buzz. So, with lot of excitement, I wanted to evaluate so that I can upgrade my application to this latest and greatest version.

First, I tried the Play-Scala module with their todoList example. As promised, the setup time was negligibly small and it lived up to the promise. But the real problem started right after that. Any change to your source code and the next page load takes a lot of time. Its definitely a lot better than the old J2EE-RAD setup but very bad when compared with its predecessor. I tried it with the java module and faced with the same issue.

There are some promises on their groups that they are working on improving the performance which is good. The two main issues must be the compile time of the Scala code (this is pure guess considering similar issues in other projects) and new feature that compiles and watches more components. Hopefully, they figure out a solution soon.

Until then, I'm going to stick with Play 1.2.4 for the application that we developed. As of now, we don't have any specific need to upgrade it to the next version. But its a definitely good thing to upgrade the application to incorporate any such things in the future.

Anti-If Campaign for Cincy Clean Coders

Below is the presentation I used for my talk on Anti-If Campaign for Cincy Clean Coders today.

The source code used in the presentation is available in github.

Anti-IF Campaign on Prezi

Dumping the thread - Websphere Performance Analysis

There are numerous occasions when we land up working in a performance problem be it at a development box or a defect opened from Production or Performance testing environment. While there are good profiling tools to help us get to the root of the issue like JProbe or YourKit, they come with a price tag with them. If there's a constraint on the team budget you wouldn't be able to use these tools. You can still workaround and use the trial version but if you read through the fine prints in the license file, you and your project stakeholders can be in trouble. So, stay out if not officially working on evaluating on these tools.

Though it could be a handicap there are other options that can be of use. In this mail, I'm going to demonstrate how to get the thread dump for your Websphere (WAS) server for performance analysis.

What is a thread dump?
A thread dump is a list of all the Java threads that are currently active in a Java Virtual Machine (JVM). When the jvm receives the signal for the same, it collects all the thread statistics and outputs it to a .txt file.

How do I generate it?
The most reliable way to generate a thread dump in WAS is using wsadmin utility. The steps for the same are as follows:
1.Navigate to the bin directory
cd <was_root>/profiles/<PROFILE_NAME>/bin/

2. Connect to deployment manager using wsadmin script
wsadmin.bat -conntype SOAP -username -password

3. The above command opens a wsadmin prompt. Now set the object variable to be used for generating the dumps
wsadmin> set jvm [$AdminControl completeObjectName type=JVM,process=,node=,*]

4.Run this command:
wsadmin> $AdminControl invoke $jvm dumpThreads

5. If you want to force heap dump, run the following command:
wsadmin> $AdminControl invoke $jvm generateHeapDump

Besides, if you have unix based systems like Linux/Mac, you can generate threaddump by just running the command:
kill -3 <pid>.

use ps -ef | grep java or ps -ef | grep to get the process-id(pid).

If you run WAS in console mode in Windows, Ctrl+Break helps to generate the dump but I have never tried it before.

A sample for generating a thread dump in a machine with node 5184Node01 and hosted locally in port 9443 with user/pass (ADMIN/password) is as follows:
wsadmin.bat localhost 9443 -username ADMIN -password password
The following commands will be run in wsadmin prompt.
set jvm [$AdminControl completeObjectName type=JVM,process=server1,node=5184Node01,*]
$AdminControl invoke $jvm dumpThreads

How to read the logs?
There are several ways to do it. Doing it manually is one of the most painful thing. IBM alphaworks has a cool tool for the same - IBM Thread and Monitor Dump Analyzer for Java shortly called as JCA. The ReadMe html inside the jar and the FAQ section talk a lot about the usage and interpretation of the data. I have used this a lot in the past and it helped us fix a lot of problems.

All said and done, try them in your leisure or when you are dealing with performance problems.

Effective Enums - 1

I'm planning to start a small series of one of my favorite inclusions in Java 5 - Enums. Joshua Bloch in his book Effective Java has dedicated an entire chapter on the same. This series will also be loosely based on the same.

In short, I want to have a Loan constant that can help me get the interest rate, maximum repay period and to check if one is eligible provided you enter the age and credit score. Here is my implementation in Java 5 for the same using enum.

Now, there are some constraints for a developer on the environment he works. Lets say if you are forced to work on Java 1.4, how do we implement this feature.

Lets create a new interface for Enums


Lets now implement our Loan enum here:

Phew! Its done.

Answer:Why is toArray() a generic method in Java Collections

At the outset, a special thanks to Joshua Marotti and Kevin from CinJUG to help me get to the solution. This is the solution to the question of my earlier post: Why is toArray() a generic method in Java Collections.

Consider the following scenario:

class Bar{}

class Foo extends Bar{}

List foos = new ArrayList();
foos.add(new Foo());
foos.add(new Foo());

Bar[] bars = new Bar[ foos.size()];
bars = foos.toArray(bars);

This works fine with the current code but will fail at compile if the method use the class level parameterized type as I had mentioned in the previous post. This is the use case why the method is declared generic. However, it doesn't prevent us from writing the below code which would compile just fine but fail at runtime with ArrayStoreException.

String[] strings = new String[foos.size()];
strings = foos.toArray(strings);

Per Joshua Bloch, we should follow PECS while using generics. Producer Extends, Consumer Super. Its probably the reason, the constructor for classes implementing collections has the extends parameter.

public ArrayList(Collection<? extends E> c)

Unfortunately, the language allows only wildcards for super. If it had supported type declaration with super, we could've solved the ArrayStoreException with the following usage.

<T super E> T[] toArray(T[] a)

On the other hand, I see Scala offers something on this line in scala.collection.immutable.List
def copyToArray [B >: A] (xs: Array[B]): Unit

There's a fabulous explanation on codeidol that discusses generics and collections in a very deep sense (suggested by Joshua Marotti). The chapter about "reification" that has some talks on toarrays and why it is the way it is and is a great read: http://codeidol.com/java/javagenerics/Reification/

Diamond Problem and Scala Traits

In object-oriented programming languages with multiple inheritance and knowledge organization, the diamond problem is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If a method in D calls a method defined in A (and does not override the method), and B and C have overridden that method differently, then from which class does it inherit: B, or C?



Java's approach to this problem was to prevent developers to extend from multiple classes but provide them options to implement multiple Interface(s). Scala provides a more clean implementation similar to the Ruby's mixin concept (I'm 0% into Ruby) called Traits. So, how does Scala solve this problem. Check the code below:
TraitLearn.scala

abstract class A{
        def isWhat():Boolean
}

trait  B extends A{
        override def isWhat():Boolean = true;
}

trait C extends A{
        override def isWhat():Boolean = false;
}

val a = new A with C with B;
println(a.isWhat());

The output is:

scala TraitLearn.scala
true

So, instead of getting confused to identify which method to execute it has left it to the discretion of the developer. The actual purpose of traits is not what is shown above but what I like it more than the interface is its ability to have partial implementation.

By the way, I bought a new MacBook Pro and the very first thing to try in it was Scala. :-)