The very mention of this word brings out different memories and emotions for different people. More so if is a framework for be used within a large company, by a completely different team than the one writing it.

To make sure that the next time you hear this word, you have positive memories; use the evaluation sheet below, before adopting the framework. If you are the one writing the framework, make sure you have good answers to these.

Why in-house frameworks?

Before we begin, let’s recap why we need in-house frameworks in the first place.

Each company, more so is it is an ‘enterprise’ has a certain set of internal standards and a ‘way to do things’. Be those be related to security, encryption, authentication, authorisation or be it about data retention, traceability, logging or monitoring. The foremost benefit of an in-house framework is out-of-the-box support for these standards and hence any solution built on them is preapproved by the standards committee, while saving the developers from reinventing the wheel for these.

These frameworks also know the company’s domain and can provide a lot of helper functions at the least to a full blown DSL on the other extreme. Thus an in-house framework is a good thing to have if it can pass the evaluation criteria.

How to evaluate an in-house framework?

Well, it is no different from evaluating a external framework, be it commercial or an open-source one.

• What is the origin of the framework?
  • Was it created from a blank slate, based on past project learning? If so, has it been battle-tested? You don’t want to be the guinea pig.
  • Was it extracted out of software delivered? Is it still tightly coupled to the environment the original software ran in?
• What is the team’s motivation to maintain this framework?
  • Is the framework their primary task or is it a distraction? This is especially the case when the framework is either extracted from a project or was primarily written for a specific project.
• What is the development model?
  • Does it mimic a commercial vendor? What is the governance model around support and enhancement request?
  • Or does it mimic open-source model? What is the governance model around roadmap, vision and acceptance of patches?
  • Does the framework team have a consistent vision to avoid the framework from acquiring feature-bloat, and at the same time is it extensible enough for a team using it?
• What is the learning curve? How well documented it the framework?
  • This is the single most important question to ask. For external frameworks, you have the internet to help you out, but for internal ones, the documentation is normally the only hope. In addition, you can hire people with skills in external framework, but will need to train every new hire on the internal framework, so it better have a short learning curve.
• What is the release and support model?
  • You don’t want to be using a framework which does not have a specific release cadence and a know support model for older versions. Neither should the support model allow proliferation of versions in the
    wild, nor should it force and upgrade every 3 months.
• Finally, will it last?
  • Is there organisational and budget support for the framework team?
  • Will the framework continue to live after the lead developers have left?

Stack trace in Java

Command Line

If the application is running as a console application, you can try one of these:

Sending a signal to the Java Virtual Machine

On UNIX platforms you can send a signal to a program by using the kill command. This is the quit signal, which is handled by the JVM. For example, on Solaris you can use the command kill -QUIT process_id, where process_id is the process number of your Java program.

Alternatively you can enter the key sequence <ctrl>\ in the window where the Java program was started. Sending this signal instructs a signal handler in the JVM, to recursively print out all the information on the threads and monitors inside the JVM.

To generate a stack trace on Windows, enter the key sequence <ctrl><break> in the window where the Java program is running, or click the Close button on the window.
(Excerpt from http://java.sun.com/developer/technicalArticles/Programming/Stacktrace/)

If the application is not running in a console, you can use the jstack tool that ships with J2EE since 1.5

jstack [ option ] pid
jstack [ option ] executable core
jstack [ option ] [server-id@]remote-hostname-or-IP

GUI Tools

Since the JVM provides APIs to hook in and get the thread state and other information, there are several tools in the market that allows you to see the state of the running application including the thread stack trace. One such freely available option is VisualVM. In fact it ships with JDK these days. Although VisualVM is pretty self explanatory, here are some instructions to get you started. http://docs.oracle.com/javase/6/docs/technotes/guides/visualvm/threads.html

You could also use jConsole for similar purpose, but I prefer VisualVM. Check this for more information: http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html#DeadlockDetection

Programmatically capturing the stack trace

from within an appilcation, you can call : Thread.getAllStackTraces(). But if you want to do the same from a different application, ThreadMXBean exposes the needed data, which can be retrieved by using the JMX interface.

Dumping thread Stack trace in .NET

.NET does not seem to have the variety of options like Java. The only reasonable option I have seen so far is the Managed Stack Explorer. This can be run from the command line as

mse /s /p <pid>

or as a GUI application:

Since it is an open source (MSPL) project, I took a peek into its source to check the API used. It depends on some sample code released by the CLR Team called mdbg. This in turn is a managed layer on the unmanaged CLR Debugging Services API.

From what I see there seems to be no direct way to get a stack trace in .NET, apart from either using the debugger API, or rolling your own on top of the StackTrace class. Check this question on StackOverflow.

In this world of concurrent, multi-threaded programming, functional style of programming makes more sense. And one of the key tenets of functional programming is immutability. Even in OO languages, a few benefits of FP can be derived if the objects are made immutable.

Clone gone wrong

We follow a similar approach in our application. But this is not always possible, especially the mutable by default approach of Java. To overcome this, we pass around clones of instances, instead of the instance itself. This works in most cases, but we experienced a very subtle bug last week, where one thread was changing the values on a clone held by another thread, in spite of having no reference to it.

The cause

After lot of disbelief and head scratching, the reason was there, right in front. We were calling the instance.clone() to create a clone. The clone function defined in the Object class (more or less) takes each variable and makes a copy if it and assigns it to the variable of the new instance. This works great for stack variable, but the for the ones on the heap, only the reference is copied, in effect both the clones have reference to the same instance of the member variable. In other words, it does a shallow copy and you might actually need a deep copy sometimes.

Before Clone

After Clone

The effect

Thus any change made to MyClassInstance.OtherClass after MyClassClone was created also changes the MyClassClone.OtherClass, leading to confusing side effects.

The solution

Once the problem is understood, the solution is obvious. Just override the clone method and clone any reference classes in it.

Check http://stackoverflow.com/questions/2890340/question-about-cloning-in-java for more.

Software Developement is not a game of Janga

I spent last two weeks deep diving into code written by our contractors and writing some test against the same. This was a pleasant break from my regular duties of an architect. As an architect I am always trying to ensure the code follows pragmatic design principle and I really dig SOLID and TDD.

<aside>

S.O.L.I.D. (a.k.a. S.O.L.D.I.)

The charm of Uncle Bob is, he can give a concrete shape to abstract ideas. I have been following the principles laid out by SOLID for some time, but he makes them fit together and remove ambiguity.

So, what is SOLID principle?
SOLID stands for:

The Single Responsibility Principle – A class should have one, and only one, reason to change.

Do one thing and do it well. Haven’t we heard this before?

The Open Closed Principle – You should be able to extend a classes behaviour, without modifying it.

You achieve this mostly by following the other principles.

The Liskov Substitution Principle – Derived classes must be substitutable for their base classes.

The class performing actions on the base class or any of its subclasses need not know the difference.

The Dependency Inversion Principle – Depend on abstractions, not on concretions.

DI is the new – new . Seriously, DI makes a big difference in testability and abstraction. You could fail at DI if you violate Liskov substitution principle. And if you do follow DI, you are mostly guaranteed to adhere to Open Close principle.

The Interface Segregation Principle – Make fine grained interfaces that are client specific.

This one is a bit difficult to grasp, but think about it and it is simple. All it says is to “Keep is Simple”. Why create an interface which has 10 methods, when the client only needs 3 of those. If you think you need 10 methods, because somewhere down the road you will need them, well, “You Ain’t Gonna Need It”.

</aside>

Coming back to the subject at hand, here’s a summary of the two weeks.

Week 1

I spent week one reviewing, writing test cases and refactoring a new application. This application is written on Spring Framework with a bit of secret sauce. It adheres mostly to the SOLID principles but has the tests all wrong. They violated most unit testing ‘laws’. Long story short, they were integration test and not unit tests.

Created mocks and stubs, injected these into the container and then wrote unit tests using the mocks. After the exercise, I was happy with the removal of all test dependencies and that the tests ran blazing fast. As an added benefit, I could now see the code coverage and compare them build on build.

Following this, I trained the contractors. Gave them a brief overview on unit testing the right way, and then showed how it could be done. Did a pair programming session and helped them write some tests.

Week 2

Buoyed by success of week one, I decided to attack the big hairy monster. This is a J2EE application with myriad dependences. DB, JMS, RMI, Tibco Rendezvous; you name it, you got it. The application has grown organically for 10 years and developed by multiple teams. The unit tests take 2 hours to complete! Mostly since they aren’t unit tests at all.

As advised by Michael Feathers in the book “Working Effectively with Legacy Code”, I started by writing tests and breaking dependencies.

I was successful in breaking dependencies, but I had to perform some nasty hacks. Since the classes were not open to modification and depended directly on the J2EE container I had to mock the container. On the bright side, since EJB 1.1 and 2.0 required certain interfaces, I could easily mock the Home classes and write dummy implementations where needed.

Then I hit a million line tall code wall. This God object knows everything and does everything, and I mean everything. This is an ugly artefact in an otherwise well written application. It violates every single design principle and has a directory of who’s who of anti-patterns. And the methods in the class are to be called in a particular order, else you will invite God’s wrath. The methods do more than they advertised, do not throw or return errors, least cohesion, and what not.

Due to this, the tests I wrote can only validate a complete workflow and not individual steps. At least the tests are not dependent on external factors and run fast. The next task on my plate is to refactor the god object into smaller classes that follow the SOLID principles.

To do so, I am following the advice in the book “Working Effectively with Legacy Code”.

Please share your advice, tips and experiences on the same.