Matrex RC1 introduced a vertical header column in the matrix editor table, to show the row index or, if needed, to show a vector as a vertical ruler.
The SWT table does not allow to have a vertical header column as needed for Matrex, i.e. such that:
is a fixed column in the table (it remains always visible scrolling horizontally)
has cells with raised border to distinguish it from the other columns.
In version RC1 I decided to not loose so much time verifying if there was a work around, so I simply used as vertical header the first column of the table and giving it a gray color to distinguish it from the others.
In version 1.0 final I want to have a vertical header in other two tables, the matrix viewer and the presentation viewer, just to show the row index. Therefore I started to see if there is a better solution than the one implemented in version RC1.
So I tested the SWT snippet 2 which should solve the problem using as vertical header a different table with only one column, synchronized with the original one. This is a good idea, but has these problems:
the vertical header table appears with a vertical scrollbar, which lets it appear disconnected from the main table. The scrollbar can be hidden, but I'm not sure it can be done on any platform.
the cells have no raised border.
sometimes the rows in the two tables appear slightly unsynchronized. This happens because the main table shows its first row only partially.
These problems (expecially the last one) make this solution not very usable and definitely do not give a professional look to the application. Therefore by now I keep the solution used in version RC1. I'll see in the future if there will be other possibilities.
It looks like in the currently published version of matrexdb (in SourceForge) there is a logical error: the result column of the position presentation contains wrong values. I will publish a new version of matrexdb this week with (hopefully) correct values. This version will also contain a readme file with more details about the structure of the testdb project.
I published yesterday a Matrex sample project, matrexdb. You can find it under the Matrex download page in Sourceforge. I published the project zip file alone because it is big (around 2.5 Mb), since it contains an entire database and the embedded McKoi library to access it from Matrex.
The database contains the data of a fake chocolate market (oh yeah), with products, spot and closing prices and more than 4000 contracts. The database has been generated automatically by a Groovy script (also in the zip file), since it was impossible to find free data to build it. Even if fake, the data looks realistic.
The project queries the database using JDBC and contains a presentation (something like a read-only spreadsheet) showing the positions built with the contracts in the database (average prices, results). The project contains also time charts showing the spot prices and the closing prices of two products.
The projects uses the function templates:
query to query the database
sumby to build the positions by product
lookup and at to connect the contracts with their products hours.
I think it is good demonstration of the features of Matrex.
Since I have the need to find the most possible amount of bugs in Matrex to come to version 1.0, which is supposed to be stable, I tried FindBugs (http://findbugs.sourceforge.net/) with success.
FindBugs finds possible bugs in your code. Or better, as th FindBugs site says: "FindBugs looks for bugs in Java programs. It is based on the concept of bug patterns. A bug pattern is a code idiom that is often an error."
FindBugs can be used as a standalone application or as an Eclipse plugin. Since Matrex is an Eclipse project I tried both the installations. The Eclipse plugin is easier for me to use, because I don't need to configure anything, just install it and use it on my project. That's how it looks:
You can see that the potential bugs are listed in the Problems view on the bottom; Clicking on a bug line, you get a good explanation of the problem in the Bug Details view on the left.
FindBugs does not pretend to be infallible. The idea is to find areas in your code that can potentially produce problems. So it can happen that some of the potential bugs FindBugs found in your project are false positives, i.e. not bugs. When you can see that one of the bugs of FindBugs is, in all cases, a false positive, you can remove it from the list of bugs FindBugs checks, changing the configuration:
As I told, my experience of FindBugs in my project Matrex is positive. I have to tell that the current version of Matrex is beta, but it was tested several times, so I would not expect to find too many errors. Findbugs found around 200 possible bugs, which is a considerable number, but not too high to check them one by one. These are the bugs it found:
EI2: public method exposed internal rapresentation: FindBugs found this bug several times in the code of Matrix. One of the examples is in the Matrix class. The Matrix class is a light wrapper around a double array, that gives to it some features, among them thread synchronization. The array can be directly accessed from outside a Matrixobject using the getValues method. Another method, setValues, has to be used to change the array. But some code could potentially access the array using getValuesand change its content, causing inconsistencies. FindBugs proposes that getValuesreturns a copy of the array instead the array itself. That's generally a good solution, but cannot be applied to Matrex, which needs high performance, expecially when accessing matrices. So in this case all I could do is to add comment to the getValues method to tell how to use it. Since all the warning of this kind are not bugs in Matrex and the code cannot be changed to remove them, I remove EI2 from the list of bugs pattern in the configuration.
IS2: inconsistent synchronization: In some Matrex classes some of the methods was synchronized, some not. That is actually very dangerous and I fixed it.
MS: is not final but it should be: I forgot to declare some static constants as final. I don't find that dangerous because I know what is supposed to be constant in the Matrex code, but if more developers will work on the same code this bug could result in some problems. I fixed it.
RCN: null check of previously referenced value: I was calling a method of an object, then I was checking if the object was null (which is totally meaningless). In this case, I looked at the code and I could see that the object could not possibly be null. So, I removed the check. Nothing dangerous but confusing for someone reading the code.
SIC: should be a static inner class (was not static): There was some cases in Matrex in which a class had an inner class that was not declared static, even if it could. No danger, but better to have clean code. I fixed it.
URF: unread field: I use the java.util.logging API to trace Matrex. This requires to declare a static log variable in the class that needs to be traced. It happens that sometimes the variable is declared but never used. Again no danger, but better to have clean code. I removed the redundant declaration.
These potential bugs, expecially IS2 and RCN, are dangerous. So, I think FindBugs worked well, and I will re-examine the code of Matrex every time I will release a new version of it.
The only thing I can ask for is the possibility to exclude the checking of a potential bug category (like EI2) only for a certain set of classes: it can be that I know that these classes are correct even if FindBugs finds the bug pattern in them, but I still want to check the rest of the code for it.