CertPal

Domain specific languages (DSL) are great tools to communicate with non-programmers. Normally this group includes business users that would like to configure a system / rule using a fluent language (as in – a natural language). It also includes those like my 8 year old neighbor that knows absolutely nothing about programming. He would love to tell the computer how to perform a small series of operations, without delving into the specifics. Coincidentally, I have been reading up on methodologies to approach DSLs and was introduced to ANTLR.

Enter ANTLR:

What my neighbor needs is an English like grammar. This grammar needs to be parsed into something meaningful at runtime. Every time the grammar changes, the parser would need to change too. ANTLR, is a ‘parser generator’. Once a grammar is defined, ANTLR can code-gen a lexer and a parser for this grammar. The lexer identifies tokens in any input that adheres to the grammar and the parser makes sense of these tokens.

Google recently donated a code profiling product to eclipse. A related code analytics product named CodePro is worth a look. It integrates with eclipse nicely. Lets take it for a test drive

Code review:

Hello world

package com.test;
 
public class HelloWorld
{
 
    public static void main(String... args)
    {
        new HelloWorld().go(11);
    }
 
    public void go(int i)
    {
        System.out.println("Hello world");
        if(i==10)
        {
            throw new RuntimeException();
        }
        System.out.println(i);
    }
}

Jettison is a library that provides a streaming parser for the JSON data format. Reading that sentence again makes you want to compare it to Stax, the streaming parser for XML. Jettison provides implementation classes that inherit from the same interfaces that a caller would use for XML reading / writing. Diving into some code reveals how JSON is written using this API…

    public void go()
    {
        try
        {
            MappedNamespaceConvention con = new MappedNamespaceConvention();
            XMLStreamWriter writer = new MappedXMLStreamWriter(con, new PrintWriter(System.out));
            writer.writeStartDocument();
            writer.writeStartElement("alice");
            writer.writeCharacters("bob");
            writer.writeEndElement();
            writer.writeEndDocument();
            writer.flush();
            writer.close();
        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
    }

Output: {“alice”:”bob”}

Notice that the XMLStreamWriter is the one in the javax.xml.stream package. The underlying data format that is written using this interface is abstracted. You could use the XMLStreamWriter to write a XML document for example. A XMLStreamReader can be used in the same way to read a XML or JSON document.

Every once in a while, there comes a need to convert an OutputStream into an Inputstream. The PipedInputStream and PipedOutPutstream classes allow one to achieve this. The idea behind the piped stream is that at one end of the pipe, a writer thread writes to a PipedOutputStream. A PipedInputStream thread concurrently reads whatever is written on the other side. Here is an example use case…

Assume that a thread streams random words and another thread needs to read these words and write them to System.out. Lets call the producer of the words, a DataSource, and the client the DataConsumer (which is the consumer of the producer). The DataConsumer has a problem. Some of the words from the DataSource are deemed inappropriate by the DataConsumer. The consumer would rather receive ‘***’ than the inappropriate word.

Any system that logs vast amounts of information, needs to think about performance. The activity of logging cannot be a synchronous blocking call that returns only when the message has been logged to a persistence store. Enterprise logging systems usually make use of a message bus to carry messages asynchronously to their target persistence store. Be it a database or a file.

Talking about logging brings us to System.out.println() (Lets call is SOP for short). It is a surprisingly commonly method to “log” messages. SOP is not meant to be used as a logging system, but unfortunately there is no dearth of projects that have these statements scattered around the code base. The adverse effects that this statement can bring on the performance of the system is often not recognized as well as it should be.

Why is SOP a bottleneck for performance ? This is why…