XML Parsing

It's been a while since I've blogged, although it's NOT from a lack of inspiration or lack of coming across anything interesting, I just haven't because of laziness I guess.
(Plus I highly doubt this gets blog read all that much!)

Anyway, just a quick one with this post. XML parsing - in Java there are generally 2 methods (1) DOM parsing and (2) SAX parsing.

In a nutshell...

DOM Parsing
From the XML input, you create a DOM (Document Object Model) tree using a DocumentBuilder.

SAX Parsing
SAX parsing is event driven, so you parse the tag as you see it.
From the XML input, you using the SAXParser when it encounters a tag, the tag handler method is called. I.e. the startElement method is called when the start tag is encountered and the end of a tag is encountered call the endElement method.

Performance
Now that we've distinguished there are 2 types of parsing, let's compare them (quickly).

For DOM Parsing, you're loading the whole DOM in memory. If you have a small enough XML file, then loading the whole DOM is ok.
When you encounter a large file, you will notice a performance impact as you end up parsing and loading a whole DOM in memory - where both parsing may take a while and then you need to have enough space for the DOM.

If you're processing XML files regularly or the system is performing other tasks this may not necessarily be a good idea to use DOM parsing.
So then you may want to switch to SAX parsing.

Tools
Because creating raw Java DocumentBuilder/SAxParser objects for XML parsing gets cumbersome you can use other libraries to do the work for you.
Here are a couple
e.g.

• Digester (commons.apache.org/digester) - you use XPath to know what element to add
• JAXB - XML binding and together with Spring (www.springsource.org) this is even nicer as you don't need to write the marshalling/unmarshalling code

* Note: JAXB can use either SAX or DOM parsing.

Resources

• http://www.javaworld.com/javaworld/jw-10-2002/jw-1025-opensourceprofile.html
• http://www.techrepublic.com/article/process-and-parse-xml-with-ease-using-jakarta-digester/6152183

Other exciting(!) topics I have mentally noted to blog about (and just haven't):

• Play Framework (http://www.playframework.org)
• Fingerprinting CSS files
• Maven Shade plugin
• JAXB binding (as well as JSON binding) in Spring
• DBUnit
• Using maven and Junit to separate running unit tests and integration tests
• Use TestNG in place of Junit for separating running unit tests and integration test
• JSON in place of XML for web services (great for use on mobile for instance)
• Caching (Ehcache, Memcached, Spymemcached, Grizzly-Memcached)

Designing Faster Sites

Most of the time we don't think about the way a page is styled or the HTML output could affect performance for users.

However you'd be surprised that the location of a css file or adding an additional meta-tag could give your site performance gains.

Most of the details of how to improve your site is talked about in this article.

Just a few highlights to mention:

* Loading CSS files at the head tag
By moving the CSS file as high as possible in the page gives the appearance the page is loading quicker. This is because the browser is able to download the CSS and begins rendering the styling earlier

* Use Expires or Cache-Control
By adding meta tags to tell the browser when to cache/not cache content can help save performance. This alleviates the amount of content the browser needs to download from the server.

* Put Javascript At The Bottom
If you can placing the Javascript at the bottom of the page helps parallel downloads in the browser (e.g. download images in parallel before Javascript is loaded). Javascript traditionally wasn't downloaded in parallel because of the order that Javascript needed to be executed and the changes that could be made to the DOM.

* Use GIFs over JPEG when possible
Smaller files that's why.

* CSS and Javascript As External Files
So that these files can be cached by the browser.

Also check out YSlow - this firefox plugin tells you what parts of your site (e.g. images) causes performance impacts on your site

I'll definitely be rolling these changes out myself on my site

Design & Markets

My friend introduced me to Etsy a few years ago (www.etsy.com) and lately, I have found myself addicted to the site. Etsy is mainly a site where people sell handmade items. I have noticed that vintage has it's own category on Etsy and I have lately been coming home from work and browsing the site for vintage treasures.

I should also talk about the handmade items that are sold. There are some pretty funky designers out there who create awesome handmade items such as jewellery, bags, t-shirts etc... It's like an online market place.

I love going to the markets - in Sydney I particularly recommend Glebe and Paddington, but you can also find pretty good stuff at Bondi markets, Kirribilli markets as well.

JMock and Multi Threading

I came across a problem recently regarding jMock and threading.
The problem was that the test seemed to have "passed", but the expectations set on the mock object were not executed.
The cause of this was because the test's thread was separate to the thread spawned by the program.

According to jMock - threading should be covered by integration testing, while jMock is meant to be used for unit testing - as such multi-threading is not supported.
However,there is a way around this...

Instead of spawning a thread in the program - create an interface which can be mocked. The implementation of the interface would have a method that accepted a Runnable class, and the thread would be spawned in this method.
The test would have it's own implementation of the interface, but instead of spawning a thread, the test would just execute the run() method of the Runnable class.

Here's a simple example:

public interface Runner {
    void start(Runnable handle);
}

public class RunnerImpl implements Runner {
    public void start(Runnable handle) {
    	Thread t = new Thread(handle);
    	t.start();
    }
}

public class ThreadHandle implements Runnable {
	public void run() {
		//actual behaviour when the thread runs
	}
}

public class Server {
	private Runner runner;
	private ThreadHandle handle;
	
	public Server (Runner runner, ThreadHandle handle) {
		this.runner = runner;
		this.handle = handle;
	}

	public void startUp() {
		//code...
		
		runner.start(handle);
	}
}

This would be the implementation class that the test would use:

public MockRunnerImpl implements Runner {
	public void start(Runnable handle) {
		handle.run(); //call run of the Runnable class instead of creating a thread and calling start()
	}
}

Another way around this is to use Executor - this is described on jMock's site here

While I'm on the topic of jMock, another tip (applicable to 1.x versions) - when mocking concrete classes, use cglib. An example of this can be found here