Hierarchical stopwatch measuring code performance

While developing software it is a good habit to keep an eye on performance of specific parts of code. There are obviously many ways to do it – we can for instance benchmark specific methods or modules as part of unit tests, we can use tools like JMeter to simulate larger number of users, we can run a profiler from time to time etc. Despite having all these advanced approaches in reach, sometimes the most convenient (or lazy) way to measure performance is to wrap code with something like this:

long t = System.currentTimeMillis();
doSomething();
System.out.println("took " + (System.currentTimeMillis() - t) + "ms");

There are definitely many cons to this approach – it’s not elegant, the results are scattered all over the log file, it can not be turned off and so on. If you happen to be using Spring Framework or Apache Commons, you might use one of their implementations of StopWatch class (here and here), which is a wrapper with some additional capabilities, like report formatting, providing of statistics etc.

Some time ago I was in a need to use a stop watch for a web application based on Spring. After spending some time with mentioned implementations it became obvious that what I needed was a slightly different mechanism – one that would allow me to see a hierarchical structure of time consumption of individual pieces of code. Something like:

run() : 2753 ms
	foo() : 2753 ms
		bar() : 417 ms
			bang() : 60 ms
			bang() : 119 ms
			bang() : 238 ms
		bar() : 2336 ms
			bang() : 477 ms
			bang() : 953 ms
			bang() : 906 ms

Cross-site scripting and HttpOnly attribute

Microsoft Internet Explorer⁽¹⁾ has an interesting feature which is not very well known. If a cookie has been set with attribute ‘HttpOnly’ then the browser will forbid any access to it from client-side code. Javascript will not be able to read, write or acknowledge information stored in the cookie.

At first sight this might not seem to be very useful, but if we bring into the picture security of web applications and especially cross-site scripting (XSS) vulnerabilities – things get interesting. One of the classical examples of XSS attack is the one in which a hacker manages to read user’s session identifier from a cookie and use it to access a resource⁽²⁾.

The most obvious way to remediate that would be to use HttpOnly attribute while setting the JSESSIONID cookie. Unfortunately this step is done by the application server itself and as on now most of them do not use HttpOnly⁽³⁾. What we might try to do is to rewrite the cookie after it has been created as shown here: http://keepitlocked.net/archive/2007/11/05/java-and-httponly.aspx.

But there’s also another way which you might consider.