Reading and writing simple XML documents using w3c DOM library

Generating a new XML document

1. Obtain a new instance of an XML parser and a new document builder instance

DocumentBuilderFactory builderFactory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = builderFactory.newDocumentBuilder();

2. Obtain a new DOM document from the former factory

Document document = builder.newDocument();

3. Generating the XML tree content

3.1. The root tag element (that I called for convenience “my-root”)

Element rootElement = document.createElement("my-root");

3.2. A child tag element (that I called for convenience “my-child”), setting to it an attribute name “my-attribute” with a value “my-value”

Element documentElement = document.createElement("my-child");
documentElement.setAttribute("my-attribute", "my-value");

4. Saving the XML tree to a file

XMLSerializer serializer = new XMLSerializer();
serializer.setOutputByteStream(new FileOutputStream(file));


Lists, Maps and hashCode

List’s are better suited when iterative operations are to be performed on your objects (use Iterators for this):

Iterator iterator = list.iterator();
while (iterator.hasNext()) {
Class object =;
// do something

Map’s are better suited when search operations are to be performed on your objects, as Maps are (Key, Value) associative arrays:


However, in order to make the Map’s search/fetch operations really efficient one must implement / override the int hashCode() method of Java Object’s, as Java uses this method to perform search / operations in Maps (see HashMaps, HashTables, …).

int hashCode(), what and how?
One might wander what is this method that, for Classes with several int‘s, String‘s, Object‘s, …etc attributes, returns a single int! If so, different Objects might have the same hashCode!

The answer is YES! Different objects might have the same hashCode. Even more, if your int hashCode() returns a different and unique hashCode for each different Object, you’re doing wrong and your code is not efficient at all! However, the hashCode must be the same if two objects are equal from the application point of view. This is why we generally advice people to override the boolean equals() method each time the int hashCode() is implemented.

The illustration is quite simple: as (Key, Value) pairs are added to the Map, Java will save a reference of the (Key, Value) pair in a (a bi-dimensional) table where the row index is determined by Key’s hashCode. So (Key, Value) of equal Key’s hashCode will find themselves on the same row and thus (Key, Value) pairs are grouped into subgroups (subgroups are the rows of the table) and searching / fetching a Value within a Map by it’s Key is reduced to a search on the row index containing the corresponding pair.

You understand now (I hope) why Key objects returning a unique hashCode value for each Object is not efficient since it will create a table with as many rows as Keys’s references … In the opposite way, returning the same hashCode for all objects will create a single row for all (Key, Value) pairs.

All the staff is to write a int hashCode() method that wisely spreads and divides your (Key, Value) pairs into subgroups of equal but not huge capacity (what do I define by huge? Only god knows!) … think of using “modulo” in computing your hashCode It surely will be of great help!

Hope this might help!

String tests in Java

NEVER test your input Strings this way:

public boolean equals(String arg) {
return arg.equals(MY_CONSTANT_STRING);

What happens if the input String “arg” is null ?! You’ll get a NullPointerException.
Rather than a cumbersome test of the input String nullity, implement your test this way (Java best practices) :

public boolean equals(String arg) {
return MY_CONSTANT_STRING.equals(arg);