Diff in Java

A workmate of mine is currently deep involved in a big deploy. He has to take a huge amount of sql scripts out of our SCM, check them manually to discover if the other programmers have followed the internal coding standard and fix them if this is not the case.

While it is still a mistery to me why nobody though to it, I started the development of a small tool that could possibly automatically check and fix all the errors.

Part of this tool is a diff style window that show the user what the tool is fixing. It seems that diff in Java is a quite required feature, so, here’s my solution.

Obviously I didn’t reinvented the weel and my implementation is 100% based on the one published on wikibooks. My implementation consist of a couple of class.
The first one is able to give access to strings line by line.

  1. public class LineFile {
  2.  
  3.  private List lines;
  4.  
  5.  public LineFile(InputStream in) {
  6.   try {
  7.    lines = IOUtils.readLines(in);
  8.   } catch (Exception e) {
  9.    throw new RuntimeException(e);
  10.   }
  11.  }
  12.  
  13.  public LineFile(File f) {
  14.   try{
  15.    lines = IOUtils.readLines(new FileInputStream(f));
  16.   }catch(Exception e){
  17.    throw new RuntimeException(e);
  18.   }
  19.  }
  20.  
  21.  public LineFile(String from) {
  22.   try {
  23.    lines = IOUtils.readLines(new ByteArrayInputStream(from.getBytes()));
  24.   } catch (IOException e) {
  25.    throw new RuntimeException(e);
  26.   }
  27.  }
  28.  
  29. public String lineAt(int index){
  30.  if(index>=0 && index<lines.size()){
  31.  return lines.get(index);
  32.  }
  33.  return null;
  34.  }
  35.  
  36.  public int lines() {
  37.  return lines!=null ? lines.size() : 0;
  38.  }
  39. }

The second one is the actual implementation of the diff algorithm, and is based on considering each line as the most little element the algorithm can consider.

  1. public class LineFile {
  2.  
  3.  private List<String> lines;
  4.  
  5.  public LineFile(InputStream in) {
  6.   try {
  7.    lines = IOUtils.readLines(in);
  8.   } catch (Exception e) {
  9.    throw new RuntimeException(e);
  10.   }  
  11.  }
  12.  
  13.  public LineFile(File f) {
  14.   try{
  15.    lines = IOUtils.readLines(new FileInputStream(f));  
  16.   }catch(Exception e){
  17.    throw new RuntimeException(e);
  18.   }
  19.  }
  20.  
  21.  public LineFile(String from) {
  22.   try {
  23.    lines = IOUtils.readLines(new ByteArrayInputStream(from.getBytes()));
  24.   } catch (IOException e) {
  25.    throw new RuntimeException(e);
  26.   }
  27.  }
  28.  
  29.  public String lineAt(int index){
  30.   if(index>=0 && index<lines.size()){
  31.    return lines.get(index);
  32.   }
  33.   return null;
  34.  }
  35.  
  36.  public int lines() {
  37.   return lines!=null ? lines.size() : 0;
  38.  }
  39. }

Finally, to give you an idea of how it performs, here’s a couple of screenshots from the application.

If you need more details regarding the code, don’t hesitate and drop me a message!

A journey with Test and Performance Tools Platform (TPTP)

I got some spare time, so I decided to give TPTP a try. After all I was thinking about it for some months.
I got the chance to apply TPTP to an applet I’m working to. The applet’s main task is to upload a set of file to a remote server giving the user some useful feedbacks, mainly including a nice interface that represent the upload process and a log window. Here you can see some screenshots to have an idea.

Upload Applet / File View

Upload Applet / Log View

So, the first rule of optimization is usually to discover which is the section of code that behaves badly, that provides the worst performances. I run TPTP and I obtained the following report.

Performances of FileApplet before any optimization took place

Performances of FileApplet before any optimization took place.

Quite surprisingly the worst performance is from the writeLog() method. This is a private method invoked inside a org.apache.commons.logging.Log implementation that implements an Observable/Observer pattern. This pattern is used to allow the user interface to receive notifications when the log is written. Apart of any technical consideration, the bad things here is that the performances of the code that manages the log system has the main responsibility of making the application run slower! This is absolutely a nonsense, since logging is not the application core business and the user does not want to trade performances for log capabilities, definitely!

So, I tried to discover how to improve the performances of this method, and I stumbled on ByteArrayOutputStream . This is a class from Apache Commons IO that provides the same interface of the classic java.io implementation. The project already included the apache commons IO jar, so it was really easy to change the dependency. I also made some minor fixes in the class.

So, I applied the second rule of optimization. Remove the bottleneck and measure the improvements, to understand if the update was worthwhile. I run again the TPTP an I obtained the following situation.

File Applet performances after first fix.

The performances of the bottleneck have increased considerably. Afterward the writeLog() method lasted for ≈14% of the total run time, against a smaller ≈10%. Then I though about the reason why the method writeLog() was invoked even when the user did not visualize the log panel. What stroke me was that I never though about it, and I used the Observable/Observer pattern only to set the link between the interface and the log system. So I refactored the code to make the log interface start observing the log only when the user press the log button, and, obviously, it stops observing the log when the user leaves the log view. This makes the code a little more trickier, but removed completely the main source of poor performances. Any doubt ? Here’s the TPTP report obtained after the refactoring.

File Applet performances after bottleneck has completely removed.

File Applet performances after bottleneck has completely removed.

So, we can quite unsurprisingly conclude that the better improvement in performances comes from not using at all the bottleneck methods (at least when it is not strictly needed).

FormFramework for iPhone

I just terminated a short stint in a project with the goal of produce an iPhone application that gives access to the services provided by an hospital. The app had a lot of forms and, since all the development team considered quite painful the form management in iPhone application, we came out with a sort of framework to manage form backed by an UITableView.

The framework should be considered a very early release and since we extracted it from a working application it is currently not fully generalized.

Here’s a video that show the basic features of the framework including:

  • prex / next buttons;
  • backed by UITableView;
  • prebuilt fileds: plain, password, dates, credit cart expiration;
  • customizable by provided implementation, as show in the “numeric lock” field.

If you’d like to evaluate if FormFramework can be useful for you, just give a look at the following short video showing how to include the framework in a new iPhone app.

The project is available at https://github.com/danidemi/FormFramework . Just give me a feedback if you think it can be useful or if you’d like to join the project.

How to efficiently show file elaboration

In a project I recently worked in we have the problem to provide users of a web application a nice graphical interface that showed the upload of some files from the user’s PC to the application server. The interface had also the task to give a visual feedback about the elaboration occurring in the application server.

A first implementation

After some experiments with ugly progress bars I came out with the following interface, loosely inspired Google Chrome download bar.

Here you can see the main idea behind the file uploader interface implemented.
The progress bar around the file icon:

  • is turned off when the file is ready to be uploaded;
  • is blue while uploading;
  • turns fully green if the upload succeeds;
  • turns fully red in case the upload fails.

More over while the upload is progressing the length of the blue bar represents the amount of data already upload. There is also a spinner effect to make the user aware of the fact the system does not hang up.

A better implementation

What was missing here was in first hand the clear distinction between the upload phase, which can be perfectly shown, measuring the amount of data uploaded, and the elaboration phase on the application server. In the second hand there was not any feedback about the upload speed.

So I updated the first prototype in the following way.

Here the spinner rotates anticlockwise while uploading and clockwise while waiting for the application server to complete the elaboration of the just uploaded file. This gives quite clearly the user the idea that there is a first uploading phase for which the application can show the progress, and another phase which lasts for a undefined amount of time.

More over, during the upload phase, the spinner velocity is someway proportional to the upload speed, giving another visual feedback.

Drop me a comment if you need some feedback about this solution.