Category Archives: Java Pad Server

Laziness pays off !

I think software engineers are supposed to be lazy as far as development is concerned. Confused ? Let me explain, software engineers are supposed to write good reusable code so that they won’t have to write same thing over and over again, hence be lazy ! I know this sounds funny, but recently while working on my own project as described in my previous post, I had a chance of being “lazy” so I wanted to share the experience on the same with you all …

In my almost 6 years of software development experience, I had to work on a lot of tools. Trust me when I say “a lot”, I mean it. I had to work on like 7-8 tools for various purposes – be it for an upgrade of platform or as a regression tool or as a performance driver or as a validation tool. In all those tools one thing what I always hated doing was loading some configuration into some JAVA POJOs. Those who have worked on ground up piece of software will know this is something you have to write for almost everything and it just sucks to write similar thing over and over again ! So when I started working on my recent project, I decided to make sure I will do something about this problem and try to write something generic so that I can be lazy in future. ­čÖé

If you see what we all as developers need is to read some specific configuration, say from a properties file or an XML and populate the same in memory as JAVA POJO which represents configuration e.g. For my socket server and client, I need configuration such as server host name, server port etc. After I do that, I’ll need to make server multi-threaded and now I’ll need no of threads as a configuration. So one thing is sure – as we work on the problem at hand, configuration we need can also grow.

Now lets take a look at what process we follow to do all of above in scenario say when we want to load configuration from a properties file:

  1. Add property to properties file
  2. Add same property as attribute to Java POJO class along with getter, setter methods following Java Bean standard
  3. Add code which will read from properties file and call respective setter method on Java POJO

This seems okay once, but when you change configuration and add new properties, you have to go back do all 3 steps over and over again. It doesn’t stop here, you can’t even use same code across your projects because its too dependent on POJO and property names.

So how about writing something generic which can easily adapt for property additions and can also work across different project so that you can truly reuse it ? What we basically need is to take POJO and property names out of the equation. Way to do this is by making sure that our “configuration loader” can work on any given class of POJO and is able to associate property names with attribute names of POJO class. Java gives you some very powerful tools to do this which is called “reflection”. Reflection gives us a way to prospect a class and find out all information about it like what methods, fields a class has.

Now instead of directly jumping to most complex situation, lets lay some assumptions such as: Property name in properties file should match field name in POJO. Now new steps to load configuration would be as follows:

  1. Prospect class of POJO and find out all public setter methods having just one argument.
  2. Instantiate POJO object using POJO class
  3. For each property name in properties file, find setter method in POJO class
  4. Convert property value to expected datatype of setter method in POJO class
  5. Set property value on POJO field using setter method

Using these steps, we have made sure that we can work on any combination of properties file and POJO class. We have created a generic facility which can give us POJO sourced from a properties file. This approach is however not without limitations, if you go through new steps you will notice we have following limitations:

  1. POJO class must have default constructor so that we can instantiate object
  2. Property names and field names should match

Obviously there are ways to work around these limitations but you get the basic point – we have successfully created configuration loader which will let us become lazy !

You can find such implementation on GitHub as part of my pet “Java Pad Server” project as follows:

Actual implementation of configuration loader can be found in a class here, junit tests for the same can be found here.

Project can be found here on GitHub. Don’t forget to visit our org here for other interesting project.

Opening Act

It has always been really hard for me to think of something really nice as opening act, this time I have deliberately tried not to think of anything for opening act, instead let me directly jump into who I am and what am I doing here without wasting your time !

I am Sid, working professional (!) for an MNC company in security domain. Like 10% other ppl of my experience, I am not too happy with limited things I get to do at workplace. So this is just an effort to get out of work cycle and do something that I would want to learn.

Now coming back to part where I explain what the hell is that I am doing here – well I am going to try few things on technology, philosophy and other things here which I would love to work on. Now my aim here to popularize new term that I like to use for some software engineers – “Experimental Software Engineers”. Like we have “Experimental Physicists” ! This term crossed my mind when I was in office discussing how a certain approach would work against another approach technically. Now instead of just speculating on how some thing would work, why not set up an experiment and try it out ?

So here I am trying to adopt my own philosophy of being an “Experimental Programmer”. So as a start, I am going to start with a simple problem and incrementally add complexity to the problem statement and thereby add complexity to solution as well. So lets start by defining problem statement –

We will have a system where multiple clients will send data to a plain socket server. Data that clients send to server is nothing by collection of words. Server processes this data by counting unique number of words in each data. Clients can send multiple data lines in each connection to server. Data is sent intermittently not consistently.

Sound simple right ? Now this is very basic problem statement and as I said before, I’ll make this complex after we get successful “experiment” for current problem statement. Lets take a look at what we are looking for in our experiment:

  1. Wait time for each client connection
  2. Overall throughput of data lines / second that can be achieved
  3. CPU, Memory consumption

Now since we have so much to measure, we also need to make sure that we setup our “experiment” in such a way that experiment itself is not affected by any other external factors. This means we have to same environment for all of our experiments. For simplicity I have created a simple Ubuntu Server setup on Amazon where I’ll be running our experiment. Clients can be situated on my laptop / any other public machine which can talk to my Amazon EC server.

Lastly, one thing I would like to mention here is that it’s not just me who will be working on this, we are a group of individuals who would be working on this project. In case you want to look at the code we are developing, you can visit GitHub account for our org here.