-k.

Occasionally I like to dabble with parser generators. Today I came across VisualLangLab which claims to be a Visual IDE-Style LL(k) Parser Generator that uses an editable tree with icons for tokens and non-terminals to represent the grammar symbols and grammar rules.

The tool is completely interactive. Errors in the grammar are indicated by adorning the affected icons as the rule-tree is edited, and the generated parser code is displayed in an adjacent pane so the effect of edits on the rule-tree can be immediately verified.

The visual tree representation of grammar rules completely eliminates the need to use and understand cryptic specifications as used in YACC, ANTLR and JavaCC. The grammar is saved to (and read from) data files using pure-Java mechanisms.

The built-in scanner can also be customized for the application via the GUI.

Now I just need to find a reason to try it out

The first public release of Necessitas is now available.

Necessitas is an Eclipse plug-in that adds a class-path container to manage a projects jars using the ivy dependency manager. In short it gives you many of the advantages of ivy without leaving eclipse.

What it does now

• Downloads the declared dependencies to the ivy cache
• Adds the downloaded jars to your class-path
• Can be configured to update the jars each time the ivy.xml file is updated

Still to come

• The ability to specify an ivy config file to use
• The ability to specify the module configuration to use
• Maybe, the ability to automatically download and associate source files

I’ve found a couple of issues in the way that ivy exposes information about what is in the cache, what it needs to download etc. None of these are irresolvable they will just take some time and co-operation with the ivy crew (who are very responsive)

You can download it via the eclipse update manager from http://eclipse.oneill.id.au/updates/

XStream is one of those libraries that you keep asking yourself "what did I do before I used this?" (picocontainer is another one). It's smallish, clean and simple to use. More importatnly it has well defined extension points tht allow you to build additional, more specific code upon. Look for a jacket sample that take advantage of it "real soon now".

I’ve been tooling around writing a SOAP client that meets my needs of being simple to use and easy to work with (which for me means no generated classes). At the same time I decided to take a look into STaX parsing. All is going swimmingly using the reference implementation until I need to get the current namespace context from a start event. It comes back null (according to the documents the worst it should be is empty).

Okay I think, well this is StAX and there are a good number of implementations around. I’ll just grab one of those.

The first place I tried was codehaus as the reference implementation now lives there and probably has an update or two. Yep there’s an update version 1.1.1-dev. Switch jars fire the test up. The 1.1.1-dev implementation dies in the same manner as the 1.0 implementation (null returned from getNamespaceContext()).

Being at codehaus I thought I’d try their other StAX parser Woodstox. As version 2.0 is at release candidate status I thought I’d give it a shot first. Nope, peek() on the reader returns information for the current event (i.e. the one I have just consumed) rather than the next event. I use peek a lot so needless to say my code doesn’t work. Okay, well it is only rc-1 so I forgive them and give version 1.0.6 a shot. Nope, now an earlier test that calls a writer dies with namespace declaration problems. Bum, ah well I’m pretty sure Sun have a shiny new implementation in the updated web services pack.

Okay, download, run shell script, install a bunch of stuff I’m really not interested in. Ah finally. I add the link to sjsxp.jar to my environment and away we go. Nope, nextTag().asStartTag() returns an error indicating that we are not on a tag event (the event is a StartTagEvent object btw). Knowing better than to try and figure out issues in suns j2ee stack (I’ve had to use sun one application server and no amount of logic will help you find the problems), I give up on it.

Now I believe that Oracle and Bea both have StAX implementations though from reading their websites and forums it looks as though they both have requirements based on their deployment environments. So that leaves me in the unfortunate position of not being able to use any of the implementation I’ve tried without issues. For now I’ll ignore the problem (I’ll return the value as a string rather than a QName) and keep an eye out for updates.

After spending some time playing with the latest version of TestNG I’ve decided to begin the switch from JUnit. TestNG is an evolutionary step forward in unit testing for Java. For me a big advantage is that it makes it much easier to group my tests. Right now I use separate test directories which, although functional, is at times a pain in the ass, TestNG allows me to group using annotations. Setup is also a hell of a lot easier. I can choose if a method executes before each test or just once for the test class which makes expensive operations such as managing database connections easier to manage. The other bonus is test dependencies. I know, I know, there is the whole “tests should be independent argument”, but what is the point of testing operations on a connection if the test to create that connection fails?

To be honest the reason I’ve waited until now to switch has been the lack of IDE support for TestNG. That changed a couple of weeks ago when Cédric announced the TestNG Eclipse plug-in making it trivial to use TestNG directly from eclipse. I’m not changing everything over night (I have hundreds of test classes). New test classes are now written in TestNG and if I need to go back and extend or resolve an issue in a current test class I update it to TestNG. My old tests are run using TestNGs JUnit compatibility mode so that I get a single report for all my tests.

TestNG comes with a lot of documentation. For a shorter introduction I recommend you read TestNG makes Java unit testing a breeze.

I’ve added a page containing a cleaned up version of my notes for developing with PDFBox. Right now it describes how to set up an eclipse environment that works with the latest cvs.

In my experience there are a two well known libraries for generating PDFs using java, iText and FOP.

FOP is an XSL:FO implemenation. The only time I really use FO is to convert docbook files to PDF. FO doesn’t really suite the sort of page generation that I’m interested in.

I’ve used iText alot in the past but as time rolls on I find that I’m more and more disapointed in it. Don’t get me wrong, it works. My issue is that it’s really badly put together. If iText doesn’t do something the way you want it to you need to write the raw PDF using the PdfContentByte. There seems to be very little thought put into the layers of abstraction. By the time I’ve done the things I needed to do most of my code consists of calls to a PdfContentByte instance. It’s close to writing PDF by hand. I get some page and XObject managment but that’s about it.

So I was considering writing my own library, then I came across PDFBox. PDFBox isn’t as all encompassing as iText but it does have some really nice layers of seperation. It layers PDF “objects” like page, font etc, upon a series of low level objects like dictionary, number and array. This is precisely what is on my whiteboard at home. It also has explicit support for reading and extracting information from PDF files (it even comes with a Lucene indexer). I’ve walked the source and done a couple of small tests and it looks pretty good.