Performance Automated Test as Comparison Test

Lately I was thinking how to teach to use JUnit to execute some performance test. I gave a try to both p-unit and JPerf. Apart the fact they do not seem to be actively maintained any more, they suffered, in my point of view, from a dependency on the system clock. This sounded very strange to me, because measuring performances with the system clock gives results that are hardly generalized to other machines.

So, what could be a solution ? Just use two codes that perform the same task. One is the reference, while the other is the one performances are measured related to the reference.

If you’re interested I would point you to the very detailed Francesco’s post about the matter.

 

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!

Http commons too standard for some web servers

I spent a whole day trying to figure out how to use http components to send a file from a java program mimicking a POST multipart/form-data form.

The problem was that while a common HTML form worked with no problems at all, the POST generated with http commons was always rejected by the server.

So, I decided to dump the HTTP requests sent by the browser and by http components, and here’s what I got.

Request generated from the browser

------WebKitFormBoundaryYuxYFZoJg4fx2Tfu

Content-Disposition: form-data; name="filename"; filename="index.idx"
Content-Type: application/octet-stream
[file content]

------WebKitFormBoundaryYuxYFZoJg4fx2Tfu--

Request generated from http commons

--xFwQ1jzWbqQIKivTUrK68BurHld66kpMCz3Fv9P

Content-Disposition: form-data; name="filename"; filename="index.idx"
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
[file content]
--xFwQ1jzWbqQIKivTUrK68BurHld66kpMCz3Fv9P--

As you can see there’s a “Content-Transfer-Encoding: binary” header that is the one that caused the problem in the server. After a while I discover than when you create a new MultipartEntity, you can optionally specify a mode of operation. Currently supported modes are HttpMultipartMode.STRICT and HttpMultipartMode.BROWSER_COMPATIBLE. It’s not worth to mention that the default mode in STRICT, that maybe does not work with old or not fully standard web servers. If BROWSER_COMPATIBLE is specified instead, the data sent by http commons does not contain any Content-Transfer-Encoding header, and the delivery of the file terminates successfully.

Here’s the piece of code:

MultipartEntity reqEntity = new MultipartEntity(HttpMultipartMode.BROWSER_COMPATIBLE);