The Goldfish Chronicles

Dynamic Proxies are kind of fun. I’ve been thinking a lot recently on business objects and how they’re bbasically pretty easy things that shouldn’t take much work.

It seems a lot of people agree with me as the Java world is full of Object to Relational mappers that attempt to do lots of stunning things. So much of my thoughts must be repeats of what is already out there.

First off though, I was thinking about Random objects, cued by a colleague.A RandomBean is very nice. Sitting on top of a random structure it allows a random anything to be created [ideal world] which is perfect for stubbing code and some unit tests. So my first business object playing in this period of thinking was a RandomBean structure. This works nicely.

Previously I had decided that all business objects should enforce the Null pattern. So absolutely NO NullPointerExceptions in the system. To do this I was code generating, but although I like writing code generators, I’m not convinced they are great for a project [though they are great for a coder wanting to impress].
Much nicer however to have this automatic, so dynamic proxies for the implementations of the business objects. Maybe a nice generator so I don’t have to code the interfaces by hand. This appears to be working nicely. Although I’ve not tackled more interesting things, like indexed and bound properties. Still, shouldn’t be hard.

So the next step is to add a NullProxy thingymebob. Hook that into the Impl so Null pattern is enforced. So, when I get around to dotting t’s etc [ie implementation], there will be a nice structure for taking an Interface and getting a library to do all the work.

Next? Next I’ve been thinking about object relational. Yeah yeah, everyone does this. But I do sit and think, it would be nice to plug an SQL in somewhere, then map column names in the result set to property names in an interface. It’s almost like bean-generics. I write my type with its properties, and then there is a whole series of generic implementations which use proxies to merge type [ie design] and functionality together into an easy to put together set of bits.

It sounds fun anyways. But bound to already be out there somewhere.

Rockin. 1.0 of String Taglib released.

My first submission to Apache finally gets out the 1.0 door. Now to start hacking on it and merging lots of the tags.

Had a few days off while a friend was over. Did lots of touristy things and didn’t really do a lot of work/java [apart from the Lang release]. So now it’s back to the usual tricks.

First orders of business, release String Taglib 1.0 and start work on the new GenJavaCore lib. Lots of code removed from Core already that’s now in Lang or Collections. Oh, and assist in achieving the next work deadline.

And it’s away!

Rather nervous updating the main Jakarta website, but I think it went okay

Well, I’ve nearly finished the release of Commons Lang 1.0 Just the matter of placing a news item on the Jakarta website and sending email to the mail lists to go. Having to hold on that as I don’t have permission to commit to the main website.

But if people are ready to go, you can grab the build from the Lang webpage.

This means all the coders can start pushing in all the ideas which have been stewing by the wayside, and projects can start feeling happy about being dependent on a beta release.

So, very exciting.

Nice little review of XmlWriter at Java-Channel. “Worst I have seen. Sucks and down right useless”, says Al Green.

Wonderful to have feedback, just wish he’d said more. Someone else replies neutrally and says they like to use NanoXml-Lite. I’ve always liked the look of NanoXml, it’s why I never bothered to push my tiny-XmlParser, Nano had most of the ground covered in a similar sized jar. I’ll have to see how well it handles large files etc. So far XmlWriter has beaten the opposition hands down for ease of code and performance.

People seem to miss the point sometimes. If SAX exists for inputting when you want tighter speed than DOM, what do you use to output….

What’s more interesting about the reviews is this is the first time I’ve ever seen java-channel degenerate into a bulletin board style site. I nearly replied, but the only way to do so is to submit a review, and that seems abhorrent. Away from the code itself, it’s a very odd feeling to get such an irritating and poor bad review. Especially as the site allows no way to contact the user and figure out what their beef is.

On the other hand, Pete Cassetta has been using it down in Texas for a few months now and loves it. Pete’s a perfect example of open source, he’s found something which answers part of his itch, he’s added to it [and resubmitted back to the project], most of his submissions have gone in, and it’s fulfilling his itch. Most enjoyably of all, this is Pete’s first experience with open source in this way, it’s great to pass on the open code addiction

[Hopefully Pete won’t mind any of that…]

I’ve released GenJavaCore 1.0. It represents a couple of years of the core classes of my personal code library, with 201 classes, and has been in very successful use in my day to day work, as well as on my home projects. I’ve no idea if it’s been of use to people outside of places where I have worked, there have been 373 downloads of the jar over the last 5 months, but I’ve only discussed the library with a few users, so hard to tell if it’s meeting peoples needs. 373 is nothing fancy, but it’s more than I expected when I began.Plans for the future are:

1) Remove anything which is better done in Jakarta Commons. This includes anything which went into Commons Lang [tbr soon!], my code which matches CLI in functionality, possibly my BeanViewer code if I decide I prefer beanutils and any collections in Commons Collections.

2) Pencil io code as going into Jakarta Commons IO. My next big project aim at Jakarta when I can find time. Along with String taglib, Lang further work.

3) Look to the future with GenJavaCore. Create APIs that sit above core components, such as the new random package, the HtmlScraper class, IO Finder, XmlWriter, XMLParser etc. Support any small classes which are deemed not up to the job at Jakarta, such as NumericStringComparator [very useful, not generic enough for Jakarta yet] and UrlComparator.

So there’s life in the library yet. But v2.0 will represent a paradigm shift I believe, moving up to a slightly higher level in its main focus. Doing this will still create many low-level components, but many of them will hopefully go straight to Jakarta somewhere. If the idea is good.