The Goldfish Chronicles

Ideas for Movable Type:

All pages have the right hand nav.
Voting option, rate a blog and have a list of the top rated blogs.
Author’s favourites. Always appears in a favourites list.
Make the right hand nav an Include.
Add a ‘what I’m reading’ section. Generic??
Add a Links system for other websites. Weblogs?
Add Category description. Appears at top in Category mode.
Add polls!

My design:

Use drop downs instead of link-lists.
Put my sites under the title.
Look into quoting other feeds.

One of my favourite websites is www.java-channel.org. It’s a site which, similar to Rusty-Harold’s Cafe Au Lait, lists new Java projects. It feels more like a freshmeat/slashdot mix than a cafe au lait though.

Anyway, it’s a great way to keep in touch with links to new Java articles and new Java products and there’s a weekly e-mail listing that week’s entries.

The Event/Listener pattern in Java is a java-specific version of the Observer/Observable pattern. To be honest I find the Event/Listener one nicer, it’s less academic and dry, but that’s probably just due to years of Java.

Anyway, one of the real pains, for me, is having to implement the notification list each time. A bit boring. So I worked on a Notifier recently. Something very simple. The first version had a Notifier which told a Notifiable of each listener Object and event EventObject. So your code simply had to add/remove listeners and class-cast the actual listener call. But that’s not good enough…. So how about if the following code could be done?

[javacode]
Notifier not = new Notifier();
not.setListenerMethod(”bing”);
not.addListener( new TestListenerImpl() ); //which implementsTestListener
not.notify(new TestEvent(”TEST”));
[/javacode]

Okay, it might not be enough, but it seems to do the job. It could take the Listener class instead of “bing” and then could a) ensure type safety on the Listener, and b) assume that the only method with a single EventObject parameter is the listener method, oh, and c) ensure only one kind of listener is added.

Inheritence seems to make it all a bit painful, so some work still needed Anyway, hopefully a nice simple usable class.

Example Java code available here.

Having mentioned that Java newsletter [see below] I feel I ought to plug my own, else I’ll be up for a darwin award. I write the tips for builder.com [about to hit my first year]. You can subscribe at the following page and there’s also an example.

My wife pointed out the following java newsletter to me:

http://www.javaspecialists.co.za/archive/archive.html

The previous newsletters look pretty good, so I’ve signed myself up willingly.
Anything that’s not covered in adverts is a welcome addition to my day-to-day Java input.

[Ah, she got the url from the rebelutionary weblog of Mike Cannon Brookes.]

I imagine most coders have met this one once or often. You’re writing a thread, therefore implementing Runnable, and you want to throw an exception. Except the Runnable interface doesn’t have exceptions on it, so you can’t throw anything.

35. public void run() throws SQLException {
Bear in mind that I use CascadedRuntimeException as that’s the name in my current library. Jakarta Commons Lang uses NestedRuntimeException and JDK 1.4 uses the getCause method. [I think Lang will be supporting getCauses via reflection among other options, is being debated on the mail list currently].

    public void someMethod(final SomeObject sobj) throws SQLException {        final String exMsg = “Exception:”+sobj.getName()+System.currentTimeMillis();        // or any other vaguely unique String.        //        Runnable run = new Runnable() {            public void run() {                try {                    …. do SQL code ….                } catch(SQLException sqle) {                    throw new CascadedRuntimeException(exMsg, sqle);                }            }        };        Thread thread = new Thread(run);        try {            thread.start();        } catch(CascadedRuntimeException nre) {            if(nre.getMessage() == exMsg) {                throw (SQLException)nre.getWrappedThrowable();            } else {                throw nre;            }        }    }

Anyway, point being that that ugly code allows me to trick my method into passing up the correct SQLException.

I’ve spent the last year or so doing low-level [for me] coding. StringUtils, Collection extensions, Comparators, a command line argument parser, a host of basic helpers and tools that I felt I needed.

Some of them are now at Jakarta Commons and I can stop relying on my version, others are now deprecated because Jakarta Commons has better versions. CLI being a prime example.

So now that I can happily list a chunk of components that I would expect to use on any project [and I will do in another entry], I’m thinking about the next step. It has to be a step back towards the OO Design I was focusing on so much a year or more ago, it has to however be very reusable and provide a foundation/building-block to strengthen the position I was in.

So my thoughts are drifting towards a common user/role pattern and a common address pattern. In fact, any kind of business-logic pattern which I can find enough reusability in. The big problem is, how generic must it be. I’m not trying to release these as OMG standards, it’s just intended to be something simple, yet good, which will work on 80% of projects. Either by importing or by copy and pasting. It must involve a stock of DDL and Java code to be reused somehow.

To be honest, I am under no illusions that these are new ideas. Jim Birchfield mentioned that Oracle have such a set, I’m sure OMG or OASIS or one of those industry standard bodies who seem to spend most of their time finding achievable comprimises have such a thing.

But this is on a different scope. While those companies will need to support large setups, and will have design by committee, I can aim low. Scratch my own itch so to speak.

The first one that came to mind was user-permission setup. These kind of things are always done, the system always starts with a user who has some plaintext password, then permissions of various types are needed, then roles, then it starts to get complex.

Here’s the list of things in the scope for JDK1.5 [JSR-176]. Having seen someone mention one of them I decided I needed to go hunt down each element and look into it. And maybe whine or comment about bits.

• JSR-003 JavaTM Management Extensions (JMXTM) Specification
• JSR-013 Decimal Arithmetic Enhancement
• JSR-014 Add Generic Types to the JavaTM Programming Language
• JSR-101 JavaTM APIs for XML RPC
• JSR-105 XML Digital Signature APIs
• JSR-106 XML Digital Encryption APIs
• JSR-114 JDBC Rowset Implementations
• JSR-121 Application Isolation API Specification
• JSR-163 JavaTM Platform Profiling Architecture

JSR-003

First off there is JMX. This is what JBoss is built upon [MBeans] and it’s not a bad concept. Quite fun to code with, and there’s this cool website front end to let you view the objects. Hopefully the JBoss JMX guys have some input to this JSR as they seem to have had one of the earliest implementations in this.

JSR-013

‘Decimal Arithmetic Enhancement’. An IBM thing it seems. To view it in a very summarisable view, it’s some enhancements to BigDecimal. It looks as though very little will actually change in the java.math APIs.

JSR-014

Next are ‘Generic Types’. Or templates from C++. Many Java developers are drooling at the thought at the moment. There was a large rumour that Generics would make their way into JDK 1.4, but they were held back to much dissapointment. For each JSR you can download specifications, see voting results, or sometimes even grab code as with JSR 13. More on these later I think. They’re the biggest one thing in JDK 1.5.

JSR-101

XML-RPC. S’been around for a bit in Java early releases and mentioned in early Java Xml books, so you’d not expect this one to have issues. And yet it’s the first one on my walk into JDK 1.5 that I’ve seen some disagreement, IBM voting no in an earlier vote. Anyways, I imagine that in large parts XML-RPC will be surpassed by SOAP, as that has better marketing. XML-RPC sounds like a pretty performant strategy, method calls over an XMLised protocol.

JSR-105

Interesting. An authentication system for XML chunks. Not a lot of information available on this one, it’s a security thing, so chances are it’ll take a version of Java to settle down into being secure.

JSR-106

XML Digital Encryption APIs. Pretty much the same as the last one. Which is no surprise as it has the same Lead.

JSR-114

java.sql.RowSet. Apparantly this is some kind of disconnected ResultSet. So I guess a standard class into which a tabular structure is loaded. I think that MS already have this? So it could be seen as a port of concepts from VB/C#. JDBC 2.1 proposed an interface for RowSet, this JSR provides the implementations. Must have a hunt through the latest JDBC [3.0 I think] to see how that reads sometime. I think this will be an important thing to get fully conversant with in JDK 1.5.

JSR-121

“Application Isolation”. What the hell? Something in the Threading world it seems. One use being in handling multiple JVMs. I get the feeling this will have articles devoted to it and still be a bitch to understand.

JSR-163

A profiling API. Think the Java Debugger Architecture with knobs on. This won’t be something that most of us deal with, but will make IDEs and products easier to write.

What else… I submitted XmlWriter to Jakarta Commons Util and am attempting to hassle the Xml Commons people into accepting it and XmlUtils. I’m worried they’ll frown on it for being ‘hacky’. I believe in it though, so might be able to preach and convert. The basic principles being: I believe in putting together a nice API so that when people want to do something in the basic-unfancy way, then they have a better tool than doing it utterly by hand. I feel that the alternative principle is the “But they should do it the proper, build an XML tree and serialise it way”. I hate that. Developers/designers who feel they know so much about their consumers that they create libraries that cut elements off or can only be developed in a certain way.

I agree that Open APIs [ones that don’t make things private without reason etc] are less dangerous to a consumer, but they’re also less useful. I guess there’s a perl/c++ coder inside me trying to get out.

At last, finished the submission of an article on JSTL for builder.com. I’ve been hacking at it for 2 months now it seems, somehow it just became this immovable object. It’s nothing special, just a cursory introduction to JavaServer Pages Standard Tag Library, but it’s the first article I’ve written that wasn’t about my own code.