For my last quarter at RIT, I decided to take as few courses as possible to stay a full-time student (and thus keep my scholarships) and still graduate. Since I’m required to do a 2 credit honors project, I figured that if I also did a 2 credit independent study and took 2 other courses, I would have a total of 12 credits, which is full-time. To that end, I’ve decided to do an independent study around observable collections in Java. Time to put my money where my mouth is, I suppose.
As I described in my independent study forms, the project will have three parts:
- An observable collections framework that acts as a replacement for the collections in java.util. This means that the collections will have the exact same functionality, with the exception of the added methods for registering to listen for events. The framework will also be configurable in how it delivers events, e.g. what threading model to use, order of delivered events, etc. At some point, this may grow to include some type of concept of application boundaries; think: what if two different people want to use the collections framework, but want different models for how events are delivered. Do you allow one to override the other? To inspect the other? Do you force configuration on a per-collection basis?
- A partial (possibly complete) Swing replacement that takes advantage of these observable collections. This allows you to follow the “set it and forget it” paradigm, where once you hook up the model-view components, you don’t have to worry about them anymore (at least for the trivial relationships). For the more complicated controller relationships, you have a more simple and well-defined point to hook in to the model and view in order to override the default behavior.
- Attempting to figure out metrics by which to measure the success of this project and employing them. It would be nice to say, at the end of the quarter, that this project gives you some type of benefit, along the lines of saved headaches, less lines of code, less complexity, etc. What I’m not sure about is a more well-defined metric to use. LOC is certainly a possibility, but I don’t think it can quite capture simplicity or ease-of-use.
You know, I originally wanted to have a different 3rd component, and I might still, so I’ll list it here:
- Observable-collection-aware and observable classes: A way of tagging your class as being aware of collections or being observable and having some type of metaprogramming facility do all of the heavy lifting. The ideal scenario would be something along the lines of an interface you implement (say, ObservableCollectionAware), and tags you place on methods that have some type of modification behavior, like annotations for @Setter, @Add, @Change, @Delete (or something like that). The metaprogramming facility would step in and place some code before and after the setter to automatically take care of the observable-ness of the whole situation.
For those of you who are familiar with Ruby, what that is really asking for is for mixins and a metaprogramming facility in Java. Before the end of the quarter, this project might become “Java Mixins”, or maybe more generally “Metaprogramming in Java”. We’ll see.