-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/

Generating logging information from the eclipse framework is pretty straight forward. Create an .options file and start eclipse with: eclipse -debug <path to your .options file> -vm <path to your jre>\bin\java. The debug information will be written to the console.

For example an .options file with the following contents would log information on the JDT builders:

org.eclipse.jdt.core/debug=true
org.eclipse.jdt.core/debug/builder=true

Over the last couple of nights I’ve been working to shore up the jacket javadoc and started writing a short introduction / tutorial. I plan to release a new version early next week.

I’m interested in getting peoples opinions on what to do with the fault detail node. At the moment it’s ignored but obviously this can’t go on forever. My initial thought has been to store the StAX events for the node and allow you to access the information via an event reader. What do you think? What features are you looking for?

As a side note I’ve just created a mailing list for those interested in jacket development.

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".

A new version (0.2) of Jacket which fixes a bug in fault handling, allows you to set proxy information and includes a simple sample that retrieves the location of the current Dilbert strip (much more interesting than the weather ) is available from the project page.

Version 0.2 (31-05-2005)

• Added proxy configuration
• Fixed a bug in SOAP Fault handling
• Added the Dilbert sample

I’ve just completed work on the first public version of my SOAP client Jacket. An intentionally simple client that gives you control of the result document processing.

You’ll find an all to short set of notes and access to the downloads at http://kevin.oneill.id.au/jacket/. Take a look and let me know what you think.

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.

I’ve spent the last eighteen months working on a large java project for one of Australia’s largest companies. The project is split into three primary streams. The server, the client and legacy data migration.

My team has been responsible for the server side of the application. We are responsible for storing several terra bytes of structured and unstructured information and providing access for hundreds of concurrent users. It’s been a challenge (and there are still some aspects that we need to do better), but we have generally been able to stick to our deadlines, so has the team doing the legacy migration. Unfortunately the team doing the client application has not been able to deliver, so a little over two weeks ago I was moved over to lead the team. What a mess.

The code has more issues than a schizophrenic ax murderer and more bugs than a Louisiana swamp. It’s riddled with insanity, how they got this far I have no idea. As an example at some point someone decided that it would be a good idea to provide application level events. Something happens you blast of an event and those that are interested get notified. Not all that insane you say, well they didn’t stop there. No you see they now had a framework. The next bright spark decided, “well if it’s good for notifications, hell it’ll be great for requests.” So now when you want to call a method on a service you send an event. The service executes the event and calls back to the listener attached to the event to inform it what has occurred, sometimes. Other times the request triggers a broadcast of the result so the caller needs to be able to listen for these general announcements. Then of course there is the routing of the message, oh, the routing. Half a dozen proxies and several thread later you request is made. Needless to say debugging event execution is very difficult. So another bright spark decided, “well hell, his is all a bit hard and all this asynchronous processing and threads make my head spin how about we allow you to just send the event synchronously?” So now the services (many of which aren’t inherently thread-safe) are being called from a number of different threads. Of course to make unit tests easier to write and understand the system switches to an entirely different mode of operation.

When I took over there were java files with over five and a half thousand lines of code. Large numbers of of classes that no one knew the function of and a runtime dependency on junit. Every developer either blamed another for the state of the code or had decided that they would just ignore the world around them and spot fix their own little patch of grass. The combined effect was that the application was collapsing in on itself. Bugs would appear then disappear. There was no realistic chance that the application would ever be delivered in a usable fashion to the business.

There are no really bad developers in the team. They have just not delivered on their talent. Now I have to deliver the application. Things are changing. Attitudes are changing. It’s a real challenge given the timelines. It’s a lot more work than it looked like from the outside. It’s going to be fun. I just hope that I have some friends when I finish.