I'm still not as far along on the protocol library as I wanted to be last weekend. After volunteering, working, partying, thrift-store scrounging, and spending quality time with my lady, I haven't had much time for programming. But that's okay.
I've learned several new technologies while planning the protocol sub-project. First, I brushed up on my Subversion commands and put the beginnings of the protocol library up on SourceForge. I've used Subversion before to check out snapshots, but this is my first experience managing a Subversion repository, so bear with me if I do anything weird! The project on SourceForge includes all my Eclipse project files, so if you use Eclipse you can easily import it. In the future, I may export an Ant project and put that up as well. I compared the Subclipse and Subversive plugins, and chose Subversive because it seems to have the best integration with Eclipse. I spent a couple days learning to write XML Schemas, and then about a week developing a schema I was happy with. I compared a few validating XML editors, including XML Copy Editor (XCE) and the XML editing perspective for Eclipse. XCE is a great stand-alone editor, but I decided to go with the Eclipse plugin, despite the fact that each additional plugin increases the IDE's already considerable appetite for my netbook's limited memory. I studied the three approaches to reading XML that are built into Java's standard library — DOM, SAX, and XPath — and chose XPath for its clarity and simplicity. Finally, I began studying the CodeModel API for Java source generation. CodeModel was created by Sun, but it seems to have been abandoned when Java was sold to Oracle. It's poorly documented and lacks the polish of other Sun APIs, but it's working well for me so far.
The master documents for the library are the XML document and schema in the resource folder of the source tree. With the exception of two or three hand-coded files, the entire library (including its documentation) will be generated from these XML files.
One of the advantages of code generation is that I can refactor the library very easily. For example, I had a hard time deciding whether to extend the Message class for every message type, or provide a helper class with static methods to set the parameters of generic Message objects. With code generation I can do both, and with less potential for error. Not only am I freed from writing and maintaining hundreds of classes, but users of the library have the choice of two different performance options. If a program doesn't reference the type-safe message dispatchers or listeners, the JVM shouldn't load the multitude of Message subclasses, minimizing startup time and memory usage.
Then again, this may not even be a serious concern. Once upon a time, I read in one of Sun's official Java books that there is significant overhead for each class loaded by the JVM. However, I'm also aware that JVM performance is much better than it used to be, and hardware is much more powerful, so what was significant back in the days of Java 1.2 may not be so significant anymore. Using CodeModel, I wrote a program that loads a thousand classes. The startup time and memory use weren't too frightening, even on my 2010-vintage netbook. It might be worse with classes that actually do something, but the results still relieved my worries.
I need to learn more about CodeModel before I can finish the program that generates the library. We'll see how far I get doing it the "right" way before I give up and start taking shortcuts.
No comments:
Post a Comment