My general experiences with software are the reverse. Coding for easy of use makes hacking it much easier. The two should reinforce each other. For example, if the GUI of ECJ would be packaged in a seperate 'project' which would be dependent on ECJ itself, it would be easier to download and compile ECJ, because it would not have the useless dependencies on the extra libraries. The same would be the case for all the 'app' examples. They should also be split off in a second example project. This is the way I always structure my projects, I try to refactor things out so that the core has the least amount of dependencies as possible. This improves hackability because its easier to concentrate on one part of the program (and it compiles much faster as well).
The same argument holds for using Java 1.5 generics.
But on a side note, I don't think forking ECJ is a good idea. I would prefer a Sourceforge version, where user contributions get merged in every so often and where a open discussion about the project can be held (like now on the mailing list).
All new additions to ECJ should be weighted and judged on these issues:
- coding practices (cleaner code is easier to hack and extend)
On a second side note. When dealing with research programmes, it should never be a big deal if people use the latest and greatest version of something, in our case Java. It is not business critical software which should 'prove' itself first, it's research code. Which can be buggy by itself and probably is a lot more buggy than Java
1.5. The first versions of 1.4 where so much more unstable than the first version of 1.5. I can't say much about 1.0-1.3 because I didn't program that much with Java in those times. The use of generics and arrays are a good thing for extending a program because they enforce type safety, so I say take the plunge and slowly incorporate Generics to ECJ.
On 10/27/05, Peter Day <[log in to unmask]> wrote:
I second that Krysztof's opinion.... I have been using ECJ to test / devlop new
EC methods and have found it highly extensible and hackable - generally ease of
use comes at the cost of versatility (which is imperitive to research).
However I would be interested in a public packages repository in which people
could deposit new & recently published evolutionary methods with descriptions
and examples (such as alternate structures, parent selection strategies
just my 2c,