The Mind Electric’s ElectricXML is yet another tree-based API for processing XML documents with Java. It has a reputation for being particularly easy to use. It’s also small. The JAR archive for ElectricXML 4.0 is around 10% of the size of the JAR archive for dom4j 1.3. Finally, the Mind Electric has also claimed in the past that ElectricXML is much faster and more memory efficient than DOM and JDOM. However, their benchmarks were a little too scant and a little too contrived to convince me.

Example 5.9 shows this chapter’s standard example program implemented in ElectricXML. As with the previous examples the input number is read from the command line. This is wrapped up in an XML request document built in memory using the ElectricXML API, which is then serialized onto an output stream connected to the server. Finally the server’s response document is read and parsed.

import java.net.*;
import java.io.*;
import electric.xml.*;


public class FibonacciElectricXMLClient {

  private static String defaultServer 
   = "http://www.elharo.com/fibonacci/XML-RPC";  
  
  public static void main(String[] args) {
      
    if (args.length <= 0) {
      System.out.println(
       "Usage: java FibonacciElectricXMLClient number url"
      );
      return;
    }
    
    String server = defaultServer;
    if (args.length >= 2) server = args[1];
      
    try {
      // Build request document
      Document request = new Document();
      request.setRoot("methodCall");
      Element methodCall = request.getRoot();
      Element methodName = methodCall.addElement("methodName");
      methodName.setText("calculateFibonacci");
      Element params = methodCall.addElement("params");
      Element param = params.addElement("param");
      Element value = param.addElement("value");
      // Had to break the naming convention here because of a 
      // conflict with the Java keyword int
      Element intElement = value.addElement("int");
      intElement.setText(args[0]);
      
      // Transmit the request documentf
      URL u = new URL(server);
      URLConnection uc = u.openConnection();
      HttpURLConnection connection = (HttpURLConnection) uc;
      connection.setDoOutput(true);
      connection.setDoInput(true); 
      connection.setRequestMethod("POST");
      OutputStream out = connection.getOutputStream();
      request.write(out);        
      out.flush();
      out.close();        

      // Read the response
      InputStream in = connection.getInputStream();
      Document response = new Document(in);
      in.close();
      connection.disconnect();
      
      // Walk down the tree
      String result = response.getRoot()
                       .getElement("params")
                       .getElement("param")
                       .getElement("value")
                       .getElement("double")
                       .getTextString();
      System.out.println(result);
      
    }
    catch (Exception e) {
      System.err.println(e); 
    }
  
  } 

}

By this point, you should be experiencing a sense of deja vu. The creation of the XML-RPC request document is very similar to how it’s done in dom4j. Navigating the response document to locate the double element is very similar to how this is done in JDOM. There are only so many plausible ways to design a tree-based API for processing XML. The most original part of the ElectricXML API is that no separate serializer class is used to write the document onto the OutputStream. Instead the Document, Element and other classes have a write() method. The OutputStream onto which the node will be serialized is passed to this method. Each node takes responsibility for its own serialization.

My major technical concern about ElectricXML is that its reputation for ease of use has been achieved primarily by catering to developers’ preconceptions and prejudices about XML. In other words, the API is designed around what developers think the XML specification says, rather than what it actually does say. For example, ElectricXML routinely deletes white space in element content (sometimes mistakenly called ignorable white space) even though the XML specification explicitly states, “An XML processor must always pass all characters in a document that are not markup through to the application.” The client application is free to ignore white space characters if it doesn’t need them, just like it’s free to ignore anything else it doesn’t need; but the parser is not free to make that decision for the client application. Worse yet, the ElectricXML namespace model focuses on namespace prefixes instead of namespace URIs. This certainly matches how most developers expect namespaces to work, but it is not in fact how they do work. I agree that the XML’s namespace syntax is needlessly complicated and confusing. Nonetheless, an XML API cannot fix the problem by pretending XML is less complicated than it really is. ElectricXML may feel easier at first than more XML-compatible APIs like SAX, DOM, and JDOM; but it’s bound to cause more pain in the long run.

I also have one major non-technical concern about ElectricXML. Whereas all the other APIs discussed here are released as various forms of open source, ElectricXML is not. The license limits what you’re allowed to do with the software including preventing you from competing with it, so necessary forks are prohibited. ElectricXML is still free-beer, and source code is provided.