Monday Apr 28, 2008

JavaOne 2008

JavaOne is coming soon: next week! This annual gathering in San Francisco has been a tradition I've kept for more years than I care to remember. This year I am presenting, along with Scott Morrison of Layer 7 Technologies, a technical session entitled "The Third Leg of SOA: Identity." (IIRC, it is scheduled for Thursday May 8th, at 1:30 PM.) Scott has incredible expertise in SOA security and governance issues, and very deep experience solving these problems using Java. Together we'll explore some of the issues and solutions needed in securing and governing SOA systems in general, using Java technologies and some very interesting architectural patterns. If you've got an existing SOA system (or at least some pieces you are assembling), or are contemplating the jump in service orientation, and you happen to be attending JavaOne, please check out our session. You'll learn some important lessons about SOA security and governance, and get to admire our Really Cool Graphics :-).

Tuesday May 15, 2007


Okay, I confess. I am very interested in computer language parsing. I've written parsers by hand, including one for a full-blown macro assembler. It's still something of a hobby of mine, and has been since the 70's.

So it wasn't surprising that, way back in 1989, I read with great interest an article in the ACM SIGPLAN Notices: the user manual for something called the Purdue Compiler Construction Tool Set, PCCTS 1.00B. This described a compiler generator that differed from things like LEX/YACC in a very important way: it generated vertical-descent parsers, just like a Real Human Being would (and like I had been doing for years). This made understanding the generated code very easy, and debugging the input grammar (which was converted into the parser code in a straightforward way) much easier than with YACC.

In 1989 I used PCCTS to create a mini-language that was used to describe high-level behaviours in a GUI framework I was creating at the time. (The language was actually part of the UI resources, allowing the developer to change UI behaviours without touching his C++ code.) PCCTS turned out to be an invaluable tool, since it let me create my mini-language without having to hand-craft the parser, which is a tedious, error-prone activity. Instead, I maintained a simple grammar description. As we gained more experience with the UI framework (used to create a family of interactive graphic language editors), I was able to adapt and extend the language to add more high-level behaviours, allowing the UI developers to specify what they wanted in a declarative fashion. It was very cool, and very effective.

Since that first exposure I've been following PCCTS, which, when it migrated to a Java-based implementation, became known as ANTLR (ANother Tool for Language Recognition, pronounced "antler"). ANTLR 2.0 was a major leap forward in capability (LL(k) parsing, as opposed to the LL(1) parsing that PCCTS 1.0 supported). I've used ANTLR periodically over the years. One interesting use was to take a text-based memory dump (from the Forte 4GL run-time), and convert it into HTML pages, making it much, much easier to explore the memory (hyperlinks are a lot easier to use than grep!) Of course, roll-your-own mini-languages have been rather fun to create, with the aid of ANTLR, over the years, and have crept into my work when need. (The Open ESB WSDL 2.0 API was generated from a high-level API description.)

Now, nearly 20 years after 1.00B was published, ANTLR 3 is nearly ready. This introduces LL(\*) parsing, another leap forward, allow arbitrary lookahead while parsing, while still allowing the parser to be efficient at run-time. I've been beta-testing a new book describing ANTLR 3, and it is a very nice exploration of language theory, practical parsing (and parser generator) issues, and the ins-and-outs of using ANTLR 3.

So if you're like me, and have an interest in language parsing, check out Tools, grammars, full source code, you name it. Enjoy!

Tuesday Apr 18, 2006

Events as a first-class concept

Event-based programs have been with us for a long time, and are getting more common. Things ranging from major business happenings to an XML element being parsed to a mouse movement are processed as events, delivered in various ways to code. Regardless of the use case, events are generated by a producer, and delivered to consumers (zero or more). Events can be delivered from producer to consumer synchronously (with the possibility of the consumer affecting the producer, by means of the event data), or asynchronously, where consumer is informed of an event separately from the producer "sending" it.

Events are, in the Java world, usually represented by objects. The mechanism for the producer to send an event, and the mechanism used to receive an event, is generally by convention. JavaBean propertyChangeEvents and propertyChangeListners are a perfect example of a synchronous delivery mechanism. Code and convention, mixed with the safefy that a strongly type language gives us, are combined to make for a workable event handling system.

What would it look like if we elevated the concept of events to the Java language itself? What if posting an event was a simple as:

    post bean.Changed;
and registering for an event was as simple as:
    Timer timer = new Timer(5000);

    switch event  {
       case bean.Changed :
           // ...
       case okButton.Click :
           // ...
       case timer.Expired :
           // ...
and an event processing loop looks something like:
    do event {
        case addButton.Click :
            // ...
        case updateButton.Click :
            // ...
        case entryField.MouseOverEvent :
            // ...
    } until (done)
or even the ability to use events to convey the normal and abnormal termination of a thread:
    Thread thread;
    // Initialise the thread.

    switch event {
        case thread.Done :
        case thread.Aborted :
        postregister : // do this after this thread is registered for the events in this switch
You get the idea. Obviously this needs further thought, but the basic ideas are well-founded, since I have lifted them from the Forté language, TOOL.

Aside from the syntactic niceties, are there any other advantages to this? Decidedly yes! Firstly, it makes it very easy to wait for events from multiple sources. Next, the run-time is now "event" aware, so it can do some useful things, like find deadlocks, or provide management reports about the state of each thread that is blocked on events (very useful for debugging multi-threaded apps).

This also avoids some of Java's low-level inter-thread communication mechanisms (Object.wait()/notify()), which are difficult for the average programmer to use, and make code fairly unreadable. This mechanism also makes the compiler more useful, since it adds some degree of type-safety to events.

Just a thought...




« July 2016