Back in December of 2008 I made a post to this blog about a major refactoring of OpenJUMP’s core. In that post I outlined my reasons for attempting that refactoring. It took me almost a year, but late in the fall of 2009 I started to work on that refactoring. After a couple months of very frustrating effort, I decided to make a drastic change. I decided I would abandon my efforts to fix the problems I saw with the OpenJUMP core, and that I would instead use the original JUMP 1.2 source code from Vivid Solutions as the basis of BizzJUMP.
I’ve now begun working on this effort in earnest, and I hope to make my first (unstable release) of BizzJUMP From Jump Source (FJS) sometime next week. What does this change mean?
There are some definite disadvantages. In its early stages BizzJUMP is going to be more limited than OpenJUMP. It won’t have the support for internationalization (translation of the GUI into other languages) and it won’t have all of the plug-ins. It means I won’t be spending as much time studying and improving the OpenJUMP source code. It also means I won’t have as much time for the OpenJUMP branding and administration efforts.
However, in the long run, I think this is a change that needs to be made. I believe the core of OpenJUMP has some serious code rot problems. (I won't get into specifics here. Try a little refactoring of one of OpenJUMP's important sub-systems and you will find out what I am talking about.) I know the program currently works quite well, but in my opinion it has passed the point of being salvaged without a major effort by a team of experienced programmers (something I don’t have at my disposal). There have been many contributions and changes made to OpenJUMP. A majority of these were made by individual programmers or organizations that are no longer involved with the development of the program. Most of them are no longer maintaining there code, and often they are not around to answer questions about their code. Many of these changes were made to OpenJUMP without an examination of their overall impact on the architecture and long-term maintainability of the program. Too many of our contributors were focused on there own short term needs and not on the long term needs of the program itself.
There are still good people (and experienced programmers) involved with OpenJUMP. There are even some new programmers showing interest in the programmer’s mailing list. I know that development of OpenJUMP will continue. Most likely, the programmers still involved with OpenJUMP will not agree with my assessment of the core’s current condition. In my past discussions, most of them seem to be content with the core’s current condition and seem reluctant to do the major overhaul I know believe is necessary for the program to survive over the long term.
I hope to remain involved with OpenJUMP and the JUMP Pilot Project. I plan on staying subscribed to both the user and programmer mailing list. I want to help answer questions, provide suggestions, and learn from others. I hope to contribute bug fixes when I can, and to continue my participation in the debate about OpenJUMP’s evolution. This time I will participate as an observer instead of an active participant.
More direct control of BizzJUMP’s core will hopefully help me to avoid some of the mistakes that we made with OpenJUMP, and that I feel will ultimately lead to the death of the program if changes aren’t made. I’ll be following these policies for BizzJUMP development, and I hope they will make a discernable difference in the program’s stability, quality, and ease of maintenance:
- All new features of the program will be added to BizzJUMP via plug-ins whenever possible. New features will not be added to the core, and plug-ins will not be “embedded” in the core unless it is absolutely necessary to do so. I’ve already modified the plug-in system for BizzJUMP to make it possible to add new features without tweaking core source code. This includes letting plug-ins take actions as part of the program start-up process (but after all plug-ins have initialized) or as part of the program shutdown process and in letting plug-ins register with the core so they can expose there public interfaces to one another during run time.
- All contributions to the core must be accompanied by a comprehensive set of unit tests and good source code comments. External documentation of the source code is also encouraged. Comprehensive Javadoc comments are a must. This applies to all contributions, even my own.
- All contributions to the core must make use of the new system testing or integration testing framework I have built into BizzJUMP if this is appropriate. This is different from unit testing, but tests the interaction between components and sub-systems in BizzJUMP.
- I must be able to understand the source code or modifications from other individual programmers or organizations want to contribute to the BizzJUMP core. This is critical, because if code goes into the core I must be able to maintain it for the long term. Code I can’t understand won’t be maintained, and code that won’t be maintained won’t be getting in. I’ll be asking contributors to tell me how they are using BizzJUMP and how long they plan on being involved with the project. I will strongly encourage contributions via plug-in and will strongly discourage modifications to the core.
- I will be making regular releases of BizzJUMP. Every even month in the year I will be making a maintenance release that contains mostly refactoring, reorganization, bug fixes, and improved documentation. Every odd month I will be making a release that includes new features for programmers and/or users. Every six months I will be making a stable release of BizzJUMP. Smaller minor unstable releases will be made during the month as appropriate.
- I will keep BizzJUMP's dependencies on external libraries to a minimum. When possible, I will make dependencies I create as small and modular as I can. I will be utilizing and sharing code with libraries like GeoTools and Jodd as much as possible.
My work on the maintenance releases will include trying to reach three (3) of the goals I outlined in December of 2008:
- Improve the separation of the “model” and the “view” within the BizzJUMP core.
- Separate generic utility code and JUMP specific utility code.
- Extract an OpenJUMP “model” library for use in other Java programs.
It will be interesting to see what the future holds for OpenJUMP. I hope BizzJUMP will be successful and that OpenJUMP will ultimately benefit from some of my ideas for BizzJUMP development.
I’ll post a link to the BizzJUMP web site and the link to the first release some time next week.
The Sunburned Surveyor
Posts
