[Jsynthlib-devel] New refactoring branch

[<chr...@ch...>]

Hi folks,

I've committed my working copy as a new branch, as I've been making a large number of changes that I didn't want to apply to the trunk without approval. A summary is below.

1 - Deleted the incomplete code in the existing org.jsynthlib package - I wonder why this was not committed originally to a branch.
1 - Moved all remaining source code into a src subdirectory.
2 - Moved the core and synthdrivers packages to src/org/jsynthlib/.
3 - Deleted Makefiles as maintaining a parallel build system seems pointless since Ant is available on Windows, Mac OS X and other Unix platforms.
4 - Deleted the stale META-INF directory that was presumably from a commit of an expanded JAR file of the project.
5 - Rewrote the Ant build script and properties file from scratch to match current best practices.
6 - Added targets and third party JAR files for the Checkstyle and PMD code analysis tools.
7 - Made a huge number of changes to the core and synthdrivers code, see below.

The code changes I have made started with an attempt to remove a lone setter from the Device interface. It required changes to all the synth driver device classes, as the device is now a constructor argument for devices since it should be initialised once. While looking through the synth drivers I noticed a lot of either cut and paste code or else cargo cult programming. A typical example is the setPatchName methods, where a byte array was being allocated then immediately derefernced and a StringBuilder was then being initialised with a string but immediately having toString called on it as part of a return statement.

Overall, I think the code can be refactored into something clean and elegant in a top down manner. This should result in no casts if the inheritance hierarchy is cleaned up, better encapsulation and a removal of Swing code from drivers that would facilitate a move to unit testing. A lot of code duplication in the synth drivers could be removed with careful refactoring, making the job of writing new drivers much easier. Sorting out the inheritance hierarchy will be my next project, and I'll try to improve encapsulation as I go since far too many data members are public or package-private, expose modifiable Collections or pass around array references in ways that introduce fragility.

Regards,

Chris