Inside the Library Architect’s Mind: Stream-of-Consciousness on JConch

(This is a stream-of-consciousness blog post: I’m just going to spew whatever comes into my head. If you haven’t taken a look at it before, see JConch on GoogleCode to get an idea what I’m talking about. I’m on SVN revision 77 at the moment.)

Okay, so I need to build the producer/consumer chains, which are really just a poor replacement for microthreads. Do I just want to do microthreads instead? Not right now: that’s going to be pretty ugly without stuff like variant types kicking around. Okay, producer/consumer it is.

Alright, so I’d like to prevent this system from being able to be built in a really broken way: if I can get the type system to enforce that things are properly configured, that’d be cool. This is really where monads can come in, but I don’t want to go down that road in Java, either. And I want something that can be configured through a Groovy builder or through Spring configuration, too. Now, both of those could leverage constructors, which allows me to do the normal stunt of enforcing all the data up front.

Unfortunately, there’s a chicken-and-egg problem. If I want to make sure that the producer has a pipelink, but I want to make sure a pipelink has a producer, then things have kinda fallen apart. So, maybe we make sure that we have pipelinks for the actual producers and consumers, but pipelinks aren’t guarantied to have either. That’s probably fair, because things may add or remove themselves from the various pipelinks. And we have the bounded pipelinks in order to prevent too much data from getting shoved into there. We’ve still got some concurrency problems, particularly if there’s some kind of thread pool or single-threaded excitement: what if we need to release a thread in order to let it become a consumer? I dunno…I’ll have to tackle this later. Maybe throw off a new thread to perform the actual add? That might work. Turtles all the way down…

Right now, I’ve got a requirement that a sink and source are both registered before you can call add and get. That’s probably fair.

Okay, so now that we’ve got that figured out…

Hey, this “Coverville” stuff is pretty good. I should save episode #400 — there’s some cool guitar parts in there I might want to learn.

Okay, so now that I’ve got that figured out…what do I think of the current arrangement? Right now, I’ve got a lot of abstract and interface classes, which violates my own rule #1. On the other hand, we’re definitely going to have multiple implementations. That’s kinda the whole point. Okay, so I guess I’ll stick with that. Although I may want to set up some reasonable defaults. The SingleThreadThreadingModel is probably the most fair approach.

Hrm. This pipeline code needs to get cleaned up a bit, but it’s actually pretty good.

Okay, let’s go make sure the tests are enabled, and make sure they run. Check them out.

Then it’s in to an ANT task to throw out a bin, source, and javadoc JAR. Then maybe I’ll call it a 1.0_rc1. It’s actually pretty good, and I’d like to move on to the example code and the Groovy builder.