Jess InformationJess Home
Jess 7 Features
®, the Rule Engine for the JavaTM Platform
Charlemagne Developer's LogThe short articles on this page are based on thoughts I've had during the Jess 7 (Charlemagne) development process.
Jess 7 Released
Development of Jess 7 began soon after "Jess in Action" was published. It's been several years in the making and I'm very happy with how it's come out. The JessDE development environment is a big help in developing rule-based systems, and the new simplified APIs and language features will help people get started using Jess more easily.
Are we taking a rest? No, not at all! Development of Jess 7.1 is already underway, and planning for Jess 8 has begun. Performance enhancements, new language features, core engine additions, and JessDE additions are all in the works. Stay tuned!
The core of the Charlemagne release has stabilized, and so it's time to move Jess 7 into beta. What does that mean, exactly? The beta version has to pass the same test suite as the previous stable version of Jess, plus many new tests for new features. It means that the Jess 7 API is now stable -- if you write code using the new features, it's unlikely to be broken by further development. It means that all the major features have been mostly fleshed out, although there may be more work to do.
It does not mean that no more new features will be introduced, although it doesn mean that new features won't be the kind of thing that makes pervasive changes to the core of the rule engine.
Most of all, the beta designation means that we're looking towards a final release, and so we want feedback on the software. Please, if you can, download the Jess 7 beta and give us all the feedback you can. We'd really appreciate it.
When the programming bug first bites you, as a young, energetic person, nothing pleases you more than the amount of code you're writing. The more lines, the better. Tens or hundreds of thousands of lines of undisciplined, random, crazy code. It makes you smile just to think about it.
A truly unfortunate number of programming shops seem to have internalized this naive joyfulness, and people are actually evaluated on how many lines of code (LOC) they can produce. I'm not the first person to mention in print that this is just wrong. More lines of code is not better. This kind of evaluation leads to a lot of cut-and-pasting, and punishes software reuse. I'm definitely not the first to observe that the resulting code is big, ugly, and hard to maintain.
But I may be the first to describe the joy that the experienced programmer feels in deleting code. I've been working through the new per-slot activation functionality for Charlemagne, and today I noticed some indirect code duplication between how definstances are initialized, and how they are updated when multiple properties change at once. With a little bit of refactoring, I was able to delete about 40 lines of code. And it felt good, better, I think, than writing those lines must've felt in the first place. It made me smile, again.
The Eclipse Debate
I've been working on the technology behind the Jess IDE for Charlemagne, and much of it is workable, in prototype form. To produce the finished IDE, though, there are a lot of details that would need to be worked out: things like color pickers, font pickers, other preference dialogs, project management, dirty-bit tracking, etc. There are some other features that would be really nice to have, but I can't imagine coding from scratch just for this project: version control integration, for example.
Enter Eclipse, the open-source, extensible Java IDE. Eclipse is rapidly becoming the de-facto standard Java IDE. Eclipse is also a powerful and easily extended toolkit for building new IDEs. The question has come up: should the Jess IDE be freestanding, or should it be packaged as a set of Eclipse plug-ins?
There are many advantages to using Eclipse as a base for the Jess IDE. Most important among them is that the Jess IDE would gain a wealth of useful features from Eclipse for free: version control integration being only one of them. Furthermore, the total size of the Charlemagne codebase would be smaller, making direct code maintenence easier. The time to market will be less as well -- and I can spend more time working on core engine features instead of on the IDE.
There are also some disadvantages: some people might not want to download all 60MB of Eclipse. Others might wish that the Jess IDE's features could be encorporated into their own environment of choice (Emacs being the most important of these.) Finally, using Eclipse means that there will be Eclipse support questions: people setting up Eclipse just so they can use the Jess IDE will come to us to ask questions.
Right now, I think the advantages outweigh the disadvantages, and the Jess user's list seems to agree. You're welcome to weigh in on this topic -- write me at email@example.com.
Likewise, XML support means being able to convert easily from Jess scripts to an XML representation and back. To implement this, again, what it needed is an A fast, flexible parser, with excellent error reporting and a public API.
It turns out that the Jess parser is already very fast, fast enough to
parse very large files in between keystrokes running the background of
the editor. Parsing code takes no time at all; compiling rules (for
example) may indeed take a long time, but parsing is another
story. All I need to do, then is
And so all these features are evolving concurrently. Already the editor's capabilties are far beyond anything I've ever used for rule development, and there is more work to do. Work on XML translation hasn't begun yet, but when it does there will be a fast, lightweight parser to work with.
Meanwhile, the Jess engine itself has better error reporting than it ever did, including new cases where static error checking is applied, and better messages for many other cases.
Synergy may be an overused buzzword, but when it happens, it can be a big help in software development.Last modified: Tue Oct 31 11:00:04 EST 2006