" /> Bill de hÓra: February 2003 Archives

« January 2003 | Main | March 2003 »

February 28, 2003

PS2: disc read error

I started getting DREs for movies a while back, and the problem gradually got worse. Yesterday, I ran a lens cleaner on the PS2 and cleaned the DVDs in question. That fixed it.

Some people get DREs for games too. There probably isn't a single cause, but it seems that Sony are fixing or replacing consoles, in or out of warranty, if you jump through enough hoops.

February 26, 2003

Axis: 17021 is notabug

Sam Ruby: In the name of interop?

I can't believe this is being seriously considered as a bug. And might actually be patched around. Reminds me of Mark Pilgrim's parsing RSS uber alles, but much worse. This is how it ends I suppose.

[search for 17021]

February 25, 2003

John Sowa on the Semantic Web

[seen on chat@fipa.org]

Developing XML as a richer version of HTML was generally a good idea. But what botched the semantic web is that promoting a universal syntax does nothing to promote semantics. To avoid further confusion, it would be a good idea to rename it "the syntactic web".

February 23, 2003

Here be dragons

The Mountain of Worthless Information

Ted Neward asks about rule driven programming:

In many respects, this should come as a welcome relief to enterprise system programmers, since it now means that a large part of the coding effort of the "business logic" in the system can be done in a tool that better fits the problem domain. If that were the case, then, why haven't rules engine become the new "Hot Topic' within the industry?

I've asked myself the same thing. Once you've been bitten by the Prolog or Jess bug, businesss logic programming in a systems language can seems very awkward.

Ted says:

The problem that the current crop of rules engines face is that the language by which we express the rules is frequently a language that Java developers have never, ever seen before.


Well true, there is no accounting for developer taste, but perhaps the problem is not just syntax.

Ted is interested in drools because the XML syntax may appeal to developers. But even if you accept the premise that developer reluctance is the bottleneck, arguably coding business logic in XML is at least as much a bogosity as coding business logic in Java (make no mistake, this is a form of coding). At the very least, an editing tool that hid the markup from sight would be needed. And I think if I must hack code in XML, I'd just as rather use XSLT or XQuery instead of a new syntax. As well as drools syntax, lets not forget the RuleML specification, which has close ties to the Rule API JSR.

XQuery btw is the W3C sanctioned XML Query Language, a hybrid of SQL and XSLT, that ends up looking a bit like a shell script. 'Software platypus' is a good term for it. Anyway, XQuery could prove to be useful as a target language for rules programming. And there are a number of currently used languages in the enterprise that could be leveraged for rules programming. It doesn't take long to build a conditon-action pair system out of XPath or regular expressions (and that's what many SOAP routers and firewalls will look like on the inside). Heck, you can even throw this sort of thing together with dependency checkers like make or Ant (is not a scripting language! I know).

Or you could use SQL. Most everything you might want to say in Prolog or an XML rules language, you can say in good old SQL with a SELECT clause, and optionally, some triggers. That's because all these languages are based on what AI types call 'existential conjuctive logic', or ec logic, a tractable subset of predicate calculus. It'll be inefficient (as you're working with syntax trees via a relational structure), but it will work. And guess what? Chris Date is a strong advocate of using a rules based language to describe business logic. His book, ''What not How?" is a manifesto of sorts for rules programming.

So arguably we already the languages needed for rules in the enterprise, it's matter of using them that way. But if we were look at the developers again, I think the real issue you will find is not that Prolog or Jess or drools, or XSLT is syntactically weird, but that thinking in terms of rules and recursive functions is weird, for I would dare to say, the majority of procedural and OO programmers, no matter what the rules language is. Try running the line 'a SQL query is a theorem about a database' past your developer colleages to see how they respond. Or show them a non-trivial makefile. You're working against years of training that teaches people to think.. like programmers.

It is easy to write rules that are computationally inefficient (even if you have the Rete algorithm implementated like drools does). And as I said above, if a rules system sits above a relational database performance may be unacceptable, since relational databases cannot easily store tree structures in an efficient manner. Much of the stuff a business will want to apply rules over will be in RDB tables.

One of the big lessons learned from the expert systems collapse in the 1980s was that it can cost just too much money to get a factbase in place; gathering data in relational form and writing procedural code and SQL proved to be cheaper and quicker, albeit dirtier. You absolutely want the business to drive the evolution of a factbase.

As for drools itself (nice code base), there is one immediate downside with its approach. Java is the wrong language to use to populate a factbase. That's something that should be done by the business, ideally without the intermediate step of going through a programmer - in much the same way, we don't like to ask web designers to deal with Servlet code. In Prolog, you would generally use Prolog itself to write down facts (they tend to look a bit like RDF triples actually). Often, facts are just degenerate rules (they have no action against the conditonal, so the conditional becomes an inert fact).

The single biggest lesson learned by AI is that it is a mistake to treat rules and facts as configuration files to an engine. How knowledge is declared is far more important that the algorithm applied to it. This is the one of the main reasons the Semantic Web effort has been bogged down in the minutiae of knowldge representation for the last two years. It's a painful but important process.

Having said all that, Prolog is a fun language and anything that gets compound logic out of Java like drools does, is a good thing. I like rules technologies and Prolog is one of my favourite languages. But there are real costs and risks asociated with using them. Like so many technologies the devil is in the details.

If this stuff takes off, and I think it's inevitable someday, business rules systems will require specialist maintainers or analysts (a Rules Base Administrator, or RBA), who also understand the problem domain. Because version control becomes an issue for large rule sets. A large rule base will probably contain inconsistent or contradictory rules resulting in unpredictable, undesirable and inefficient effects, unless a specialist maintainer is appointed. A lot of research was done on automating the management of factbases using Truth Maintanance Systems (TMS) in the 1980s, but I don't know how much of that work made it out of the labs.

Acolytes of rules technology I think believe that business rules software can replace hoards of programmers and programming, since business people will write the rules themselves. This is a very seductive message. I'm sure I remember the same thing being said about SQL and RDBs, but in hindsight seems that RDBs have generated their own programming industry - I don't think anyone expected that.

review: Patterns of Enterprise Application Architecture


Patterns of Enterprise Application Architecture

Patterns, Enterprises and Architectures, oh my! But the most important words on the cover are "Martin Fowler". He has already written three fine books on software development. I want to do two things - first say some nice things to encourage you to read it (it's a great book), and second, concentrate on the things I didn't like so well.

The format is similar to Refactoring, geenral discussions at the beginning and end, the patterns catlog in the middle, with cheatsheets and a list inside the covers. That makes it easy to dip in and out of the text, and like Refactoring it should become a valuable communications tool for developers, providing a vocabulary for application development. Much of the book deals with the mismatch between objects and relational databases. Fowler tackles that problem head on, with nearly twenty patterns and a chapter devoted to it. If you are working against an object-relational boundary, or protecting your application from database dependencies and find the GoF book dated or irrelevant, this is an excellent resource. It is also helpful in determining which patterns are suitable to either the J2EE or .NET platforms with examples in C# and Java, helping to appreciate patterns that are actually workarounds for limitations in the respective platforms.

If you're experienced in building or designing enterprise systems, there's not much here you won't know already so there might not be any great revelations. And currently, pattern bashing is becoming a popular past-time. But that doesn't take away from the point that this is one of the best written, and best organized books on the application of design patterns. It's probably the best book written on n-tiered application design.

Some places where the book fell down for me:


  • As mentioned a large number of the patterns present are there in order to let developers work effectively with databases, over a third perhaps. If you want to control the risks of implementing business logic on top of a database, this is the book to start with, but the broader question, when and whether to use a database at all, is not asked.

  • I would have preferred to see some messaging patterns than the lightweight treatment on concurrency. Messaging is on the rise as an integration tool. He does say that messaging patterns were deliberately excluded, so perhaps we can look forward to a future book focusing on them.

  • The Front Controller pattern, despite being received wisdom these days, may well be the antipattern for web development, if not used judiciously. Designs based on decorators (and Fowler does mention that possibility), but other options such as state machines, or even aspects aren't considered.

  • With a REST hat on, I'm not so sure about assertions that state is best left on the server in a client-server and web applications. Client sided state is mentioned, but is limited to cookies and some treatment of URLs. I've commented on this assertion before, but ultimately it falls to those of us who feel REST has a value proposition to produce an argument as to why centralizing state is a problem, especially in light of the fact that the web does not function according to REST advocacy in this area.

Sun: 5 year plan

Diego Doval: Sun's five year plan

NYT:

Mr. McNealy, 48, met with his senior managers last year and asked each for a commitment to stay for five years.

Diego comments:

I remember last year when those high-profile departures were taken as a sign of weakness for Sun. However, in light of this information, what it actually showed was strength since the executive team that is in place now will be able to see through the current strategy to completion. Very impressive.

Agreed. I wonder what might happen if Sun asked for a similar commitment from the J2EE vendors, Open Source and those involved in the JCP. That would be a community.

February 22, 2003

Charles Miller: page links v comments

The Fishbowl: Introduce Yourself! Comments and Weblogging

Essentially, responses in the blogosphere promote conversation, and widen the field of discussion. Responses in comments tend to bury it. That said, it seems that I'm in the minority, and being annoying.

Oo hacking with Python

SourceForge.net: Project Info - OOpyRep

OOpyREP is a python code generating filter and library. It reads a OpenOffice.org file and creates a python representation of the document structure as well as contents.

JSR-172: J2ME Web Services Specification

JSR-000172 - J2ME(TM) Web Services Specification - Public Review

JSR-172 specifies a subset of XML for J2ME, while calling it XML. This hasn't gone down very well on xml-dev with Tim Bray and Elliotte Rusty Harold voicing objections.

February 21, 2003

Bad day at at Black Rock

Compare and contrast:

Simon Phipps: Cozumel, alone. [via Sean McGrath]

Robert Scoble: The human face of Microsoft . [via Jon Udell]

February 20, 2003

UML diagram for Web Service Architecture Document

Architecture

MT: It just works (and it's in Perl)

In the middle of scanning some weblogs (by the way, there's a excellent set of exchanges going on between Mark Baker, Jorgen Thelin and Werner Vogel at the moment about REST and reliable messaging). I see that Moveable Type has bumped up to 2.62. So I go for an upgrade. It took as long as the download (3 mins) and the FTP upload onto my web account* (6 mins). And that's it. Carry on scanning. It's ridiculous. Everything works. After a recent traumatic experience with software configuration, it's embarrassing to be reminded so brutally that stuff can be made to work right out of the box. My hat is off to Benjamin and Mena G. Trott.


* This thing is running on a UKShells account, I haven't found anything in Ireland that really matches them. Granted, the current Euro Sterling exchange rate isn't helping any.

February 19, 2003

Cameron Purdy on Lexing and exception wrapping

/dev/null [Cameron]

Instead of:

        catch (EOFException e)
            {
            logError(ERROR, ERR_UNEXPECTED_EOF, null,
                    m_script.getLine(), m_script.getOffset(), 0);
            throw new CompilerException();
            }
        catch (UnicodeDataFormatException e)
            {
            logError(ERROR, ERR_UNICODE_ESCAPE, null,
                    m_script.getLine(), m_script.getOffset(), 0);
            throw new CompilerException();
            }
        catch (IOException e)
            {
            logError(ERROR, ERR_UNEXPECTED_IO, new String[] {e.toString()},
                    m_script.getLine(), m_script.getOffset(), 0);
            throw new CompilerException();
            }

How about:

        catch (EOFException e)
            {
            logError(ERROR, ERR_UNEXPECTED_EOF, null,
                    m_script.getLine(), m_script.getOffset(), 0);
            throw new CompilerException(e);
            }
        catch (UnicodeDataFormatException e)
            {
            logError(ERROR, ERR_UNICODE_ESCAPE, null,
                    m_script.getLine(), m_script.getOffset(), 0);
            throw new CompilerException(e);
            }
        catch (IOException e)
            {
            logError(ERROR, ERR_UNEXPECTED_IO, new String[] {e.toString()},
                    m_script.getLine(), m_script.getOffset(), 0);
            throw new CompilerException(e);
            }

Quit Carping

A logo for the WSA

WSA is the W3C webservices architecture group, a fine list, yet prone to long meta type threads on ImportantWebStuff. Frank McCabe I know from JSR-87 (JAS) and his work on FIPA styles software agents. Seems he has a wicked sense of humor :)

T. S. Eliot on systems design

It is impossible to design a system so perfect that no one needs to be good.

[via a Bill Caputo .sig]

Rick Jelliffe on technical editing

xml-dev

When I worked in technical editing, one of the first things we were taught was "make a checklist; don't do everything at once". Consistency is so important for reference publishing. Enter the text; spell and grammar check; mark up basic structures; check terminology is consistent; mark up figures; mark up index entries; check that the headings are accurate for their body text still; check that the same structures are marked up the same way; print off a draft and check the text and tables; print off a galley and get it proofread; tweak the text to prevent widows, add PIs to force breaks and keeps for better layout, etc. I think anyone (except perhaps enormous Brainiacs) who has written a book or any kind of professional material will use a checklist. I once asked Don Stollee (a project manager who works on large markup projects, often defence or aeronautical) what the most important thing for efficient markup was: his answer was dividing the job up into subtasks: rekeying tables would be one tasks, markingup references would be another. People usually work the most efficiently whenthey can concentrate on one thing at a time.

February 17, 2003

Browser distortion field

[via Danny Ayers] Opera thinks MSN is a muppet.

I thought that stuff with MSN and Opera was long dead. Seems not, if MSN are still throwing up garbage to Opera users. Unbelievable.

Shark jumping Google revisited

People are starting to wonder about Google.

[Shark jumping Google]

Optimal routing policies

Underway in Ireland

From personal experience, mostly gleaned by peering over the shoulder of Liam Noonan's bandwidth throttling research, I know that adding more interconnections to a network doesn't improve service. As the Columbia paper shows, you might run into something called Braess' paradox, which says that if you introduce more interconnections so that messages can hop from one path to another partway along, this actually makes the trip longer for everyone -- pretty much like changing lanes in a traffic jam.

Exactly. Now if you could get the people charged with uneviable task of determining the UK and Ireland's transport policies to take some lessons from networking, queing theory and logistics I'd have some more faith in the future of transport infrastracture for both countries.

Solutions in routing could be achieved using reinforcing pheromone trails (as ants do). These are interesting because the paths dissipate quickly after going unused. Eric Bonneabeau among others has interesting results in this area. A technology worth looking at for routing policies is Reinforcment Learning (using a Markov decision process or Q-learning). I'm pretty sure the future of cache management, heap sizing and object/thread pooling lies with reinforcement learning - eventually the penny drops that you can get the computer to figure out what to do instead of having to confugure it by hand. To close the Irish angle, there's a chap at DCU Mark Humphries, who has extended Q-learning in his PhD.

Axis and caching

axis and caching

This thread pretty much sums up what I meant when I said:

Web caching depends architecturally on intermediaries (or proxies) understanding what they can and cannot cache from entities they know nothing about. In other words, while it is not fully adequate, HTTP is designed with caching in mind and documents can be cached. Web services, particulary SOAP messages, have no such facility.

It's difficult to build internet scale systems without having a good story on caching (pure p2p models notwithstanding). Web caching is an analog to middleware object pooling, but requiring more transparency to allow third parties to interact.

The thread is also a fine example of needing to think about whether the semantics of your bespoke application methods are consistent with respect to the HTTP methods you happen to be tunneling through. This issue of caching, alone, should indicate that HTTP is not really a transport protocol despite web services realpolitik.

February 13, 2003

Jon Udell interviews Ward Cunningham

Stop what you're doing. Ward Cunningham is quite possibly the most vital actor and thinker on software development over the last ten years.

Darren Hobbs: just say no

Darren Hobbs: No, please no!

On SuperX++:

I can feel my wrists ache just reading it

Honestly though, having XML as the underlying construct instead of ASCII is missing the point a bit. What would be great is proper base support for Unicode in a programming language. Java tries, but comes up wanting - you can treat the String class as a UTF-16 codepoint API, but it's not exactly intuitive (or even documented, being something that only really got thrashed out during development of the nio.* libraries)

Otherwise, as far as XML programming languages are concerned - just say Lisp :)

Diego Doval: openoffice thru java

Abort, Retry, Fail?: February 7, 2003 Archives

Diego Doval:

It seems to be a design more influenced by the "all things to all platforms" mentality of CORBA rather than Java's simplicity. I'd sure would like to see a simple, streamlined Java-only API. Burdening Java with a framework that has to support the complexity (and potential ugliness) of C++ makes no sense to me.

It'll be interesting to see how Diego and Rickard get on with Oo over time. So far in Propylon we're happy. Clyde and Sean twigged initially that using Oo would be a good thing. As a result we've been doing a good bit of work with Oo over the last few months for Irish eGoverment and that has included going through the Java APIs.

But if there is one issue it's this - the surface area of the Oo APIs is huge. It reminds me not so much of CORBA (though its programming model has that ORBy RPC feel to it) but of the java.* APIs or .NET system libraries. Starting out, it took a couple of days to just to get a handle on what was going on, never mind get anything cool or interesting done with it. Nonetheless barring the odd glitch and some minor dissonance I seem to have with how Writer styling works, it's a good setup.

In all fairness, the Sun Oo/StarOffice guys in Dublin and Frankfurt have been very helpful, and the Oo dev lists is a good place to go with questions. But my preference over time has been to deal with XML files directly (though calling to a running Oo server process it to transform documents is still a useful-to-have and that's what we use in one project). A section of the Oo community seems to feel the same way - the xmerge project is targeting the file format direct to provide transformations in and out of of various formats and there is also work under way with Docbook transformations.

Wiith some work, Oo has just as bright future on the server as the desktop. For that alone, a simplified API would be most welcome. One thing that would be great is WebDAV integration for Oo desktop clients (Oo has a basic HTTP client to deal with linking so there is something to work off, and we've noodled in work about throwing something together along those lines if we could find some spare cycles) But to be honest it could well be in there already - after a few months, I still feel I've only touched a fraction of the functionality in the product.

.

February 11, 2003

xerces.hell

A whole new level of classpath nonsense has presented itself in the last few days.

Start.

So, I've got this code to validate a messaging envelope (not SOAP-based). The validation component sits at the front of an XML pipeline. I'm adding a config file for loading up document schemas and DTDs. Very nice, no code changes to the validator for new versions of a schema. The config file is pointed to by a .properties entry. Lots of unit tests with good coverage, testing the configuration as well as the behaviour. And using Ant the classpath is udner control (more on this).

Deploy to JBoss. First burp, the .properties file in the container is using backslashes, so the path to the config is a mashup. Fixed that, but it took a while to see.

Bounce JBoss. Second burp. MethodInvocationException, no such method. Hmm. Track it down to a class called CCI, the actual configurator (it loads individual schema files bound to a version numbers of the schema proper). The ctr for CCI isn't happy for some reason:


public CCI() throws Exception
{
itsDocumentBuilderFactory = DocumentBuilderFactory.newInstance();
itsDocumentBuilderFactory.setValidating(true);
itsDocumentBuilderFactory.setIgnoringElementContentWhitespace(true);
itsDocumentBuilderFactory.setIgnoringComments(true);
itsDocumentBuilderFactory.setCoalescing(false);
itsDocumentBuilderFactory.setNamespaceAware(false);
itsDocumentBuilderFactory.setExpandEntityReferences(false);
itsDocumentBuilder = itsDocumentBuilderFactory.newDocumentBuilder();
}

Looks fine, compiles fine, test fine. Doesn't run in the container. I'm lost. After some checking, it turns out that this line:

    itsDocumentBuilderFactory.setIgnoringElementContentWhitespace(true);

is the problem. More checking. I'm really lost now. Start moving jarfiles around and around, namely xerces.jar and xercesImpl.jar. [I'm sure XML parsing jars are closely related to rabbits, because they seem to pop up everywhere in the system. You look in a folder, come back to it an hour later and there's a new one sitting there].

I find the xerces.jar that is being loaded and put it into the build classpath for IDEA and Ant. Wow. they both tell me that indeed there is no such method as :


itsDocumentBuilderFactory.setIgnoringElementContentWhitespace(true);

on DocumentBuilderFactory. Oh really? Well that flag is needed, to avoid checking for (ignorable) ws nodes as the XML is walked (before you ask, yes, it's not a mixed content model and each config file has the dtd inlined). The jar has no version information in its manifest entry.

So I take it out of the classpath, and drop in xerces from Ant 1.5.1 (the one I'm building and testing against, that happens to work fine). Bounce JBoss. Out of memory exception. I'm not going there. Try another xerces or two from who knows where else - more out of memory exceptions. Eventually, I use Tomcat 4.0.1's.

Success.

No. Wait. Third burp. The system property. org.xml.sax.driver is not set anymore (according to Jing's RELAX NG validator). Ok, set the driver.

Success.

After all that, I go back and add the (ignorable) ws checking anyway. God knows I don't want this breaking because the classpath has changed.

Finish.

Time elapsed, nearly 2 days. I am rage. I feel so damn stupid.

It would have taken much longer without this call, which tells where a class came from:


Object o = ...
o.getClass().getProtectionDomain().getCodeSource().getLocation().toString();

Without this call, I would have probably broken down like a baby and written a SAX handler (even though the config file structure is recursive and a DOM tree is handy for that). It's going into the logging framework for this system, I hope soon.

Here is an example of how to use Ant to add manifest info to a jar:


<target name="mdb-jar" depends="compile" description="generate the mdb-jar file">
<mkdir dir="${build.lib}"/>
<mkdir dir="${build.classes}/${meta.inf}"/>
<copy todir="${build.classes}/${meta.inf}">
<fileset dir="${src.dir}/${meta.inf}/MDB-INF">
</fileset>
</copy>
<jar jarfile="${build.lib}/${mdb.jar.name}">
<manifest>
<attribute name="Built-By" value="${user.name}"/>
<attribute name="Sealed" value="${mdb.jar.Sealed}"/>
<attribute name="Specification-Title" value="${mdb.jar.Specification-Title}"/>
<attribute name="Specification-Version" value="${mdb.jar.Specification-Version}"/>
<attribute name="Specification-Vendor" value="${mdb.jar.Specification-Vendor}"/>
<attribute name="Implementation-Title" value="${mdb.jar.Implementation-Title}"/>
<attribute name="Implementation-Version" value="${mdb.jar.Implementation-Version}"/>
<attribute name="Implementation-Vendor" value="${mdb.jar.Implementation-Vendor}"/>
</manifest>
<fileset dir="${build.classes}">
<include name="${meta.inf}/**"/>
<patternset refid="jar.target.mdb.inclusion.set"/>
</fileset>
</jar>
<delete dir="${build.classes}/${meta.inf}"/>
</target>

February 05, 2003

There is no such thing as the perfect information model

Sean McGrath - Realities of electronic information management

There is no such thing as the perfect information model. While I'm at it, here is another tip: No information model survives the first encounter with real information in the real world.

February 02, 2003

OOPs

jutopia

Jon Tiersen links to Tabelizers OOP myths. Of course it helps to define what you mean by OOP. To me, OOP is a programming technique for managing dependencies in software. Personally I don't go in for using OO to model the world. I'd rather in order of preference:

  • Not have to model the world, if I can help it.
  • Let someone else good at modelling the world do it.
  • Use the Relational Databases to model the world
  • Use Conceptual Graphs to model the world
  • Use RDF to model the world

None of the above approaches are as good as OOP is at helping me manage code - though they certainly reduce the amount of it I have to produce.

fingerfood selection of OO characteristics.
Why OO Sucks

Dave Ely and Bob McWhirter on Exceptions

Ztuff

Dave Ely and Bob McWhirter responded to my little rant on exceptions. They really don't like the idea of String based exceptions, and are worth quoting at length:

Bob McWhirter:

I truly think that the idiom of using String messages as parameters for an exception and the getMessage() method have contributed to the uselessness of many exceptions. You're right that we all tend to getMessage() or printStackTrace(). I wouldn't say our exceptions are poor, but that our exception handling is. I try very hard to have meaningful constructors with meaningful parameters, and no messages, in my Exception hierarchy. public class NoSuchThingException extends Exception { public NoSuchThingException(ThingRepo repo, String thingId) { ... } public ThingRepo getThingRepo() { ... } pulibc getThingId() { .... } } The getMessage() is implemented in the class, and constructs a message using the accessors to the parameters of the constructor. So, my exception attempts to provide enough -context- to gracefully handle the exception. When all you get from your Exception is a String message, you have few options. With member data, your handling capabilities expand, and the usefulness of exceptions as a whole increases. If you really think exceptions are pointless, always throw a RuntimeException. You can still catch them when you need to, but otherwise, you can completely ignore them and have the JVM bomb out with the stacktrace you want.

Dave Ely:

Although I understand where this feeling comes from, I disagree with the whole darned concept. Exceptions are one of the more powerful and well done refinements that C++ introduced to C. They allow us to enforce the idiom of one entry point, one return point unless things go badly wrong. When done well, they also allow method level determinism of what can and can not be dealt with, and for more advanced applications, turning a problem into a solution. [...] This is same darned problem people still have in the C++ world, and most of them have never figured it out. String based exceptions are completely useless unless you employ parsers at every level of the application (and they make internationalization nearly impossible). Java has further contributed to the problem by making exceptions have some sort of context (a stack trace for example) but has not allowed developers to easily construct one exception type from another and retain that context. Inexperienced (and seasoned) developers alike are liable to create new exception types at the drop of hat for reasons I've never been able to fathom.

No argument there. I'm playing Devil's advocate by claiming exceptions are pointless when really the problem is that they're being abused by developers, particularly checked exceptions in Java.

The main objection to exceptions is that they make code complicated for questionable benefit. There are all these specialised exceptions, which aren't needed, and which result in the developers working against or around the system, because their job is that bit harder with the exception handling as designed. The whole point of exceptions was that it would simplify error handling - I'm not sure that's how things have worked out. Here is what (as likely as not) will happen to specialised, domain-oriented exceptions from worst to best case:


  • They'll get swallowed.
  • They'll get wrapped in an equally specious exception at a package boundary, and rethrown.
  • They'll get wrapped in a more general exception, and rethrown.
  • The code will reroute its excecution path in graceful fashion.

If you do get a wrapped exception, maybe the wrapper exception won't actually carry the cause exception's information through (personally I've seen my fair share of truncated InvocationTargetExceptions and ServletExceptions). Otherwise, I hope you've got the source to the dependency that failed - 'cos if you don't you working blind.

Exceptions need to be as general as possible to make them useful and used. This works just like security. The more hoops people have to jump through to obtain a secure system, the less secure the system becomes, because people will do dodgy (and maybe stupid) things to attain the levels of comfort they were at before the policy came along buggered everything for them. To someone, those hoops are crucial - to everyone else they're a pita. And paraphrasing William Gibson, You are One and They are Many. Dissonance happens and people will tend work around restrictive policies.

Worst of all, much of the time the specialised exceptions aren't needed; they're a twist on premature optimization, something that seemed like a good idea at the time. Designing them into mainline code is asking for trouble. The reason they're not needed is because exceptional behaviour doesn't have a whole lot to do with your domain, other than having happened there. The relationship between something like a boundary or resource exception and domain objects is tenuous at best, certainly not enough to require TheDomainBoundaryException. The stack trace should provide as much context about the domain than any kind of OO Hungarian error notation will.

Dave and Bob nonetheless have a valid point , getting applications to respond well to exceptions begs the code to respond to the exception's type, and not some number scraped out of getMessage(). To effect this, a protocol for failure needs to be designed. However, very little Java code works that way (though it sounds like Dave Ely is doing something very close).

It may well be that handling a class of exception behaviour in one place is a good thing and that an AOP approach could help normalize the code. I wonder then, is anyone using dynamic proxies or compiled aspects against exceptions as well as mainline code?

But most of time, an exception is thrown and it'll keep being thrown, up the stack until it reaches the attention of a human. The odd time it'll reach some code that can actually do something useful with it, other than log it and keep chugging. If what we do with 90% of exceptions is a glorified log line, then the design principles applied to logging can be applied to exceptions the primary one being get the line noise out of the way of the programmer's main line. But if you are actually doing something behaviorally interesting with exceptions, different rules apply, and my hat is off to you.

By the way, there are over 250 exception types in 1.4 JDK. I wonder, do we even need half of them? A quarter? An eighth? It's worth remembering, that as introduced by Java, checked exceptions are something of an experiment for mainstream programming. Python doesn't use them and C# dropped them. Bruce Eckel has this to say:

Checked exceptions seem like a really good idea at first. But it's all based on our unchallenged assumption that static type checking detects your problems and is always best. Java is the first language (that I know of) that uses checked exceptions and is thus the first experiment. However, the kind of code you must write around these things and the common phenomenon of "swallowed" exceptions begins to suggest there's a problem.

Disclosure: on JSR-87 (Java Agent Services), we're in public review and simply have too many exceptions in the API (more than 10). In fairness there's a lot that can go wrong, but we do have to factor some of those types out to make the API more usable. So I'm a guilty party, but learning.

CategoryException
Bruce Eckel
Robert Di Falco

Ross Judson: AOP + Rules

Spiral Dive

Want to learn something new and truly mind-expanding? Go find Ernest Friedman-Hill's Jess system. Read the manual, think hard, and you'll find out where computer science is going in the long run. Yes, he's created a CLIPS system for Java, and perhaps that on its own is not worthy of what I've just said. But when you start thinking about what you can accomplish with it, and what happens when you attempt to create aspect-based systems and couple them with rule programming, you get to a very interesting place.

I second learning something like Jess or Prolog. By the way, if you use XSLT and SQL (and who doesn't), you're as good as working in the same language family. As for mixing AOP with rules, that's something I'd like to hear more about.

Classpath - fixme

Well I knew the Java CLASSPATHwas a pita, but there seems to be a thing in the air that it needs to be fixed. Here's a few quotes from January:

Ted Leung:

The Java classpath mechanism is probably the number one source of wasted time. Just look in any java related mailing list and you'll find piles of messages related to hosed classpaths. Why isn't there a JSR to replace the classpath mechanism?

James Strachan

Classpaths and ClassLoaders can be very frustrating. The real problem isn't the design of the ClassLoader per se, its we need some packaging mechanism on top of it that can correctly (and automatically) load all the corrent jars for us.

Ted Neward:

All this really does, though, is help underscore how fundamentally broken the Java ClassLoader model really is. CLASSPATH is a gross hack and should be deprecated immediately (as in entirely absent from JDK 1.5 and up), and issues like verisoning and JAR-to-JAR dependencies resolved in a more sane and reasonable fashion. Anybody out there in bloggerland willing to go in with me on a new JSR?

Steve Loughran:

happyaxis.jsp does this for stuff in the Axis webapp; lets us track down situations where things are visible at different levels (and with catalina on java1.4 you do need to install bits of axis at different levels). Code worth stealing (indeed ant -diagnostics) already has. A new JSR? hmmm. How about we just knock a new version of java.exe that ignores CLASSPATH and takes either a classic java command line or an in-file declaration of what to run, like the tag in ant.

Markus Kohler:

What I really would like to do is to tell my build script, that I have project A which depends on B, and whether B exports it's symbols. That's the way one can setup projects in Eclipse. I don't care about whether the jar file name of B has changed lately, that would have to be encapsulated in B's build script. I also do not want to have to adapt the classpath of A just because
someone has splitted A into C and D.

Specifying the classpath in an XML or any other configuration file may improve the situation a little bit, but my idea would be to specify the dependencies within the jar files. Actually the jar file spec already defines a "Class-Path" attribute. This is a step forward, but I think it's not the best solution. Instead of referencing jar-files, one should have identifiers (+ a version number) within each jar file and then should reference only identifiers with an optional version number when specifying dependencies.

Carlos Perez:

Isn't this easily done in Ant, here's an example: [...] In short, you got everything self contained in a single XML file. Better yet, you can leverage ANT's filesets to the tilt, enumerate explicitly your jars or use a query mechanism.

February 01, 2003

A REST-centric messaging API

Just throwing this out to see what people think. It's a hybrid of HTTP, SOAP, JAS, JavaSpaces and JMS after throwing away 95% of them - whether I kept the right 5% is the question! The API elements reflect a strong REST bias. I wanted to show what REST might look like in API form, much of the diiscussion surrounding REST is quite abstract.

The notion is that there are things called authorities, which communicate by sending and receiving messages. Messages are made of an action, headers and an entity (payload). Authorities have resources under their control and messages are used to manipulate and understand resources by making requests through an authority. Authorities are also resources.

At some point I need to think about reflecting asynchronicity in the interfaces, right now the calls look synchronous- that's REST's client-server origins leaking through. Communications are constrained using protocols (a protocol is a collection of names for headers and actions, the names are expected to imply a semantics).

public interface Resource {
  java.net.URL identity();
  Authority authority();
}
public interface Authority extends Resource {
  Message create(java.net.URL url);
  Message delete(Message req);
  Message change(Message req);
  Message snapshot(Message req);
  Message metadata(Message req);
  java.util.List protocols();
}
public interface Message {
  Protocol protocol();
  Action action();
  Entity entity();
  java.util.Map headers();
  Resource about();
  Resource from();
}
public interface Action {
  String name();
  Protocol protocol();
}
public interface Entity {
  Boolean accept(EntityVisitor v);
}
public interface EntityVisitor {
  Boolean apply(Entity e);
}
public interface Protocol extends Resource {
  java.util.List headers();
  java.util.List actions();
}

public interface StorageService

Kalixia :: 2002-12-02

An interesting storage interface. Very like a JavaSpace.

Splleing mistakes considered embrassing

Cafe con Leche XML News and Resources

I went to Cafe con Leche looking for something Elliotte wrote about webservices. And I find he's quoted a mail I sent to the W3C TAG list as his quote of the day. Which is an honour. But good grief, I need to sort out my spelling! It's not good that I foist this laziness onto others. Mozilla is installing a spellchecker now...

Nick Chalko: versioning 101

Show me the code

Thanks to Nick Chalko for writing down the major/minor/patch (he calls patch, 'point') scheme. Good links out to stuff like krysalis and a (the?) jakarta-commons versioning policy (which was new to me).