Category: english

Following text comes with limited warranty – I’m not saying that what we did was the best solution to problem but it was the simplest one. At least we thought so.

We recently replaced our in-house logging for something more “standard”; log4j-based based logger. The original code developed by out former employee was a mixture of spaghetti code and huge amount of non-threadsafe WTFs. We spent some time fixing it but finally we’ve decided to replace it. In order to incorporate our additional features that had been part of the original logger, we extended java.util.logging.Logger. So far, so good; but then the real hell started. There comes the first mistake one should learn from – never ever replace anything that works with something that hadn’t been even tested properly.

After a while with new logger we noticed our server application started to die with OutOfMemoryException. As there was a lot of changes made everywhere no one really suspected logger. But nothing could be further from the truth; wrong usage of ByteArrayOutputStream which was never reset() caused the trouble, we found that after couple of hours of profiling as no one would suspect “runtime” classes to eat the memory.

Having fixed something so obvious we thought we were done. Well, not really. Server did not crash in two days, it went down after a week. Same exception, same source – new logger.

In order to explain the situation I have to start with out new features. We wanted to have similar log files separated by given parameter, all our topics are members of huge enum, some of the values can have an annotation specifying destination filename and default parameter. If such parameter is present in log record, it’s written in file based on given data; this helps us to sort data according to their source, even if log entries are created by the same code; quick example will explain it faster – imagine application reading data from email accounts – such an application would log with our logger to N+1 files named:

application.log
application_HOTMAIL.log
application_GMAIL.log
...

I guess you got the idea. In order to do that we needed a place where those parameters are stored and instances of java.util.logging.Logger class seemed as a logical place. We extended this class and our implementation added support for those additional data.

Simple, but… there comes the catch. Loggers live in hierarchical structure, each logger has a parent. Whenever new logger is created it’s assigned to a parent (parent could be root logger, of course). Each logger keeps its children in a java.util.List, see following excerpt from Sun’s Logger.java:

    private Logger parent;    // our nearest parent.
    private ArrayList kids;   // WeakReferences to loggers that have us as parent

    public void setParent(Logger parent) {
	if (parent == null) {
	    throw new NullPointerException();
  	}
	(...)
	doSetParent(parent);
    }

  private void doSetParent(Logger newParent) {
	synchronized (treeLock) {
	    // Remove ourself from any previous parent.
	   (...)

	    // Set our new parent.
	    parent = newParent;
	    if (parent.kids == null) {
	        parent.kids = new ArrayList(2);
	    }
	    parent.kids.add(new WeakReference(this));
	}
    }

There are weak references, good. But wait – who’s cleaning up kids collection? Nobody? There we go…

This class is a joke. All important fields are private, it’s not implementing any interface, there is no simple way how to fix the problem. As a logger I wanted to get rid of myself when I’m finalized – no way, you can’t even call setParent(null), it’s gonna throw an exception and fail to do anything else. Saddest thing of all is that kids collection is not used anywhere for anything reasonable – it’s just sitting there eating heap. And you can’t do anything about it. Damn you, Sun.

Well,
it’s not easy to work with Swing components. I’m working on a special editor, it consists from N JTextPanes glued together. They resize according to amount of text they have inside on order to avoid scrollbars. So far it wasn’t so complicated. But now I got complicated – I wanted to be able to “walk” freely through the JTextPanes – using only keyboard arrows.

First I implemented jumping between current and next/previous with TAB key, this was not a big deal. What’s the problem with arrows? Well – in order to have it working as expected you need to be able to find out whether you’re at the last line or not. One would guess that reading document structure would work but if you have lines longer then JTextPane width the “internal” lines and visual ones differ. One “internal” line could split into multiple visual lines.

In cases like this I simply go and study – study the libraries – this kind of check needs to be somewhere, right? So we only have to find it. After half an hour of searching I found something that could work:

int newpos = text.getUI ().getNextVisualPositionFrom (text, pos, Position.Bias.Forward, direction, bias);

(complete reference for UI is here:
http://java.sun.com/…/MultiTextUI.html)

text is JTextComponent, pos is current position, Position.Bias defines the direction (back/forward), direction is int defined in SwingUtils (SOUTH, NORTH, etc…) and bias is Bias[1] returned back. I don’t care about Biases – I just call it with desired direction and get new position. And if it’s the same like the original one we probably hit the border. Voila!

I recently stumbled on NullPointerException in Transformer.transform (Source, Result) method, my application was working fine until yesterday, there was no update, no change in configuration of anything…

What I was doing there is a textbook example of usage of Transformer class:

	    Source source = new DOMSource (doc);
	    Result result = new StreamResult (new File (file));
	    Transformer transformer = TransformerFactory.newInstance ().newTransformer ();
	    transformer.transform (source, result);

Transformer is a part of JVM and it’s used mostly for saving Document to file, so first thoughts were to check the parameters passed. Yes, there was a valid path inside File, canWrite () returned true, the file was created indeed (albeit having zero size) but that was all. The only message I got came to stderr and read:

ERROR: ''

Very helpful, isn’t it? What next? I went to check the stacktrace:

javax.xml.transform.TransformerException: java.lang.NullPointerException
at com.sun.org.apache.xalan.internal.xsltc.trax. TransformerImpl.transform(TransformerImpl.java:651)
at com.sun.org.apache.xalan.internal.xsltc.trax. TransformerImpl.transform(TransformerImpl.java:281)
at xxx.Main.writeDocumentToFile(Main.java:151)
at xxx.Main.main(Main.java:332)
Caused by: java.lang.NullPointerException
at com.sun.org.apache.xml.internal.serializer. ToUnknownStream.characters(ToUnknownStream.java:312)
at com.sun.org.apache.xalan.internal.xsltc.trax. DOM2TO.parse(DOM2TO.java:229)
at com.sun.org.apache.xalan.internal.xsltc.trax. DOM2TO.parse(DOM2TO.java:215)
at com.sun.org.apache.xalan.internal.xsltc.trax. DOM2TO.parse(DOM2TO.java:215)
at com.sun.org.apache.xalan.internal.xsltc.trax. DOM2TO.parse(DOM2TO.java:215)
at com.sun.org.apache.xalan.internal.xsltc.trax. DOM2TO.parse(DOM2TO.java:121)
at com.sun.org.apache.xalan.internal.xsltc.trax. DOM2TO.parse(DOM2TO.java:85)
at com.sun.org.apache.xalan.internal.xsltc.trax. TransformerImpl.transformIdentity(TransformerImpl.java:596)
at com.sun.org.apache.xalan.internal.xsltc.trax. TransformerImpl.transform(TransformerImpl.java:642)
... 3 more
---------
java.lang.NullPointerException
at com.sun.org.apache.xml.internal.serializer. ToUnknownStream.characters(ToUnknownStream.java:312)
at com.sun.org.apache.xalan.internal.xsltc.trax. DOM2TO.parse(DOM2TO.java:229)
at com.sun.org.apache.xalan.internal.xsltc.trax. DOM2TO.parse(DOM2TO.java:215)
at com.sun.org.apache.xalan.internal.xsltc.trax. DOM2TO.parse(DOM2TO.java:215)
at com.sun.org.apache.xalan.internal.xsltc.trax. DOM2TO.parse(DOM2TO.java:215)
at com.sun.org.apache.xalan.internal.xsltc.trax. DOM2TO.parse(DOM2TO.java:121)
at com.sun.org.apache.xalan.internal.xsltc.trax. DOM2TO.parse(DOM2TO.java:85)
at com.sun.org.apache.xalan.internal.xsltc.trax. TransformerImpl.transformIdentity(TransformerImpl.java:596)
at com.sun.org.apache.xalan.internal.xsltc.trax. TransformerImpl.transform(TransformerImpl.java:642)
at com.sun.org.apache.xalan.internal.xsltc.trax. TransformerImpl.transform(TransformerImpl.java:281)
at imdbparser.Main.writeDocumentToFile(Main.java:151)
at imdbparser.Main.main(Main.java:332)


Fortunately I’m not afraid of going deep into the code, so I grabbed sources and checked the line where everything got started:
Caused by: java.lang.NullPointerException
at com.sun.org.apache.xml.internal.serializer. ToUnknownStream.characters(ToUnknownStream.java:312)


the code there looks like this:

    public void characters(String chars) throws SAXException
    {
        final int length = chars.length();
        (...)

Gotcha! The only possible cause of that is chars being null, fine but… why? Previous line in stacktrace finally helped to resolve the problem:

case Node.TEXT_NODE:
	    _handler.characters(node.getNodeValue());
	    break;

So there’s one or more #TEXT nodes in the document having null value! It was quite easy to find the problem having this information, it was on following ternary expression:

m != null ? m.name : getMName (files[i].getName ())

At first sight it looks good – there is a test on null value but what if mis not null and m.name is?

The Owls Are Not (always) What They Seem (Twin Peaks)