Purifying action: Report-Designer 2.0 is on the way

Three weeks! It now has been three weeks since the purification started. Three weeks of furious deleting, refactoring, screaming, crying, contemplating suicide, restructuring, analyzing and finally fixing the report-designer's codebase.

Are we finished now? Not yet. The current SVN version is now in a state where all the major parts are in place, but the overall experience is still .. experimental.

My development theme for the new report-designer is "back to the roots". Almost all external dependencies are gone now. Well, some minor dependencies are still waiting for their extermination:

• JGoodies Formlayout - a creature spawned in the depths of the seventh circle of hell - is still used in many of the old dialogs. As this layout manager is as hard to maintain as the infamous Gridbag-Layout of the core JDK, there are no advantages of using it. Whenever we now touch one of the old dialogs, we will replace this nightmare with a plain Gridbag-Layout. GridbagLayout may be ugly, but at least we don't have to ship a Jar for it or force other developers to learn yet another useless trick.


• IntelliJ IDEAs NotNull-annotations. The idea of marking parameters, fields and return-values as nullable seems to be a good idea at first. But sadly, the implementation of said idea is horrible. When using IntelliJ, violations of the annotation constraints easily remain undetected - the compiler does not warn you and so you won't see errors until you get the Exception at runtime. In addition, anyone not using IntelliJ wont have much use of these annotations anyway. Therefore, for the new code and all classes touched during the redesign: Let's kill these annotations. Now we replace them with strict coding guidelines. We start with explict checks on all public or protected methods, wherever we do pass object-references around. On a architecture level we prevent NullPointerExceptions by having a strict object-model with strict type-checks. And of course, this includes that we do not pass private collections around, as it seems all so common these days.


• DOM4J and Jaxen: These classes are used by the Pentaho-Version-Checker to parse a structurally simple XML document. One could use a combined total of 500KB of libraries or one could use down-to-earth XML-parser implementations that use JDK-1.5 functionality only. Guess what the old code does and guess with what we will end up with.

Very early in the game, we already removed the Pentaho-Platform, as using a ?? MB collection of libraries to read a single properties-file was a bit ridiculous. We removed all magical code-generation (that was done via asm-lib and reflection) as all of these uses were easily replaceable by a single well-defined interface. We removed the PullParser and all the XML-magic as XML parsing in JDK 1.5 is really well-defined (heck, it was well defined in the age of JDK 1.2, for the usecases we need here). We removed SWT as I cant stand libraries that crash the Virtual Machine just because they cannot cope with the processor architecture or operating system. I still believe in the "100% pure Java" world Sun advertised ages ago. And we removed Castor, as a OR-mappers used for parsing a non-complex XML file is a WTF on its own.

Inside the code itself, we sliced through the event handling and created a clear event-dispatching path. Although it must be fun to virtually connect every object with every other object, I do not want to spend the few remaining years of my sanity on maintaining such a beast. Almost all cases of invoking methods by reflection were removed by simply creating interfaces containing the method to be called. But that road was no fun to walk - so at the end we ripped out the old data-model and rendering and editors and ... and so the new report-designer works directly against the reporting-engine's datastructures and with components that follow a strict separation of concerns.

And now, with all magic killed, we leave the dark age and enter the age of enlightening. With a sane and maintainable architecture to start with, we will finally be able to spend less time on maintenance and more time on developing new features. After all, bug-hunting is not a fun activity, so spending less time there leaves us more time for the fun stuff.

The new report-designer data-model is a thin wrapper around the visual objects of the reporting-engine. The model itself only provides some caching of the layout, change tracking and event-notification and nothing else. There is no point in wrapping around datasources or functions, as long as we set the social rule that after these objects have been altered we always notify the model of it.

The report-designer's code now no longer contains copies of existing reporting-engine functionality. Datasources, layouting, expressions - it all comes from the one and only principal source now.

And the result of all of this: The report-designer now automatically provides access to all features of the reporting engine as soon as the reporting engine implements them. We can now guarantee that whatever the report-designer shows you in the edit view will be the same result the reporting engine will show you. Everything the reporting-engine can do, can now be done with the report-designer.

We now also started to define the first set of plugin-points for the report-designer, so that anyone can hook-in own editors, datasources and actions without dealing with all the complexity of the whole project.

Nuclear power is safe*

*except for certain black-out dates

Yesterday, once more nuclear power has been proven to be to dangerous to be handled by humans. At the site of nuclear plant of Tricastrine, about 360kg Uranium leaked into the local water system.

So far, that's nothing big, such things happen from time to time. Eventually, we get used to it. But it shows, that not only the plants itself are a can of worms, but all activities around the nuclear power production chain can have devastating long term effects.

The radioactive half-life time of Uranium-235 is 704 million years. So in only 352 million years, the radioactive pollution in that area will be down to half of the level it is today. Great, so your grand-grand-grand-(repeat 10 million times)-grand-kids will be lucky enough to live in a somewhat healthy area again.

But this incident must not be seen as a singular incident. Nuclear waste is generally disposed in rock salt and old salt mines. The salt is supposed to keep the waste dry and to prevent any contamination of the ground water. So far the theory. Newer research showed, that this disposal schema is not safe at all. Nuclear waste still generates heat as the nuclear processes never stop. Research now has shown that salt rock deforms when being exposed to constant temperatures of 100 degree celsius and more. Although the experiments were conducted in a laboratory only, the result indicates a great risk of storing large amounts of nuclear waste in such salt mines for  a couple of thousand years. As a result, the only safe way to store nuclear waste is to monitor it actively for the next ... 350 million years.

(Home work exercise:  Calculate the full costs of 1.70 MWh nuclear power under the unrealistic assumption that energy companies are paying for *all* clean-up costs for as long as the nuclear waste is dangerous to humans. 1.70 MWh equals one barrel oil.)

During the last years, nuclear power plants have been proven less safe than advertised. In 2006 at  Ringhals nuclear power plant in Sweden, a fire shut down the plant and a faulty emergency power aggregate almost lead to a melt-down. The emergency power is required to safely shut down the plant in case of black-outs. Without a safe shutdown, a melt-down is the guaranteed result.

The very same security architecture was installed in the German nuclear plants in Brunsbüttel and Krummel (link in German), which also had to be shut down after a fire and short-circuits in the emergency power system.

And just in June this year, a Europe wide nuclear alert was issued after a accident in a Slowenian nuclear plant.

Despite the fact that Germany has a rather strict monitoring of the security of nuclear power plants, the list of incidents and accidents in German nuclear power plants is still impressive.

How many Chernobyl-style disasters have to happen, before we realize that the risk and long term costs  do not justify the short-term profit of nuclear power.

Germany, Sweden and Spain agreed to stop using nuclear power within the next years.

Italy had been a nuclear free zone for the last 20-years, but due to the current power-holder Silvio Berlusconi Italy will most likely return to use nuclear power in 2013.

So the question is: What do you value higher: Short-term solutions to well-known energy problems which everyone chose to ignore for the last decades or long-term safety and a healthy environment.

Independence Day

While the former colonies celebrated their successful rebellion to evade British taxes on tea and other goods, I created my own Declaration of Independence (from old and obsolete rules that burden the pioneer spirit and now just exist for historical reasons).

As the name suggests, the "extensions-reportdesigner-parser" project is a Classic-Engine extension that allows the engine to use *.report files as produced by the current Report-Designer as ordinary report-definition files.

On the quick-win side, this immediately removes the need to convert reports into the extended-XML format during the publish process. As long term gain, this module acts as a compatibility layer as soon as we start the report-designer redesign.

There are several reasons why it is a good idea to separate the report-definition fileformat from the internal model representation:

• The report-designer's XML file references classnames and therefore makes it hard to do refactorings without affecting the names put in there. Now we can start to move classes and functionality around without having to worry how our actions may break existing reports.


• The report-designer's internal model is a incomplete (and in some cases incompatible) copy of the reporting-engine's report-model. This results in subtle bugs and diverging feature sets, which in return leads to frustration and ugly hacks.


• As the designer maintains a own copy of the reporting-engine's model, changes in the reporting engine's processing (notably new features or extensions of existing features) need a long time until they become available in the designer.


• And of course: Maintaining a own model is expensive. The time we have to spend to keep the models in sync, is time we cannot spend to make the designer better.

This module now is the living proof, that there is no need for a separate report-designer model and therefore no need to have a *.report format in the future.

With 0.8.11, we can safely map everything that is inside the report-designer's file format into the native elements of the reporting-engine. The charting in the designer is covered by the legacy-charting sub-project, the design-time properties in the *.report-files (like the horizontal and vertical rulers) are mapped into Element-attributes, and for each data-set offered by the designer, we have a sane equivalent. (And in case the dataset-specification itself was a bit insane in itself, as it happens with the XML-datasources, we now have legacy-projects for these parts as well. No matter how strange the code or behavior is, for the sake of full backward compatibility we'll keep that code alive.)

During the next two weeks, we will concentrate on making the Report-Designer 2.0 ready for a bright future. At the end, we will end up with a designer that is a natural extension of the reporting engine core. In the process to that glorious goal, we will happily remove the code that simply duplicates the engine's behavior. Add a bit of reducing information redundancy and let us reduce the magic of reflection to a minimum and we shall be in a good shape for the next years to come.