Monday, November 30, 2009

Darwin - Evolutionary Computation in Java

Send me your difficult computational requirements, your NP-complete problems, your befuddled designs.  Really!

In recent years, one of the projects on which I've spent a good deal of time is the Darwin java framework for evolutionary computation (http://sourceforge.net/projects/darwin/).  It's designed to make it relatively easy for a developer to set up, execute and refine a genetic algorithm or program.  I need examples.  But I also need (paying) contracts.  I need to use it to do solve some real-world problems.  I'm also looking for (volunteer) developers...  and for people to comment on it and maybe offer constructive criticism.

Darwin is a framework which models the basics of genetic algorithms using a set of interfaces, (extensible) abstract classes and default concrete implementations.  Objects with a long lifecycle (the beans) are configured using XML files (provides dependency injection).  Other short-lived objects are created as needed using factory classes.  Darwin runs a simple genetic simulation out of the box

toString

Ever thought how nice it would be if the method toString(), defined in Java's Object class, was more intelligent?  By default it shows the name of the class, followed by "@", followed by the hash code of the class (presented in hex).  Wouldn't it be nice if it would actually show some of its property values, relationships with other objects, etc. without you having to do all that coding

Well, now you can use my latest project at SourceForge: toString (http://sourceforge.net/projects/tostring0/).  By default, if your object extends the abstract class AToString (which in turn extends Object), toString() will return all of the exposed bean properties of the object (the getters, in other words).  If you want to add or omit fields or methods, then you use the @ToString annotation.  You never need to actually write anything yourself to override the toString() method (although of course you still can do so).  If you can't (or don't want to) extend AToString, then you can have your objects implement the interface IToString, which adds another more complex toString(...) signature which is used by the toString utitilities.  If you don't want to have anything to do with the abstract class or interface, you can still invoke the class methods in ToStringUtils.

Tuesday, November 10, 2009

Java logging

Want to know my nomination for the worst-documented part of Java? It's the so-called JDK 1.4 logger. It's clear that it was a last minute hack that Sun really couldn't be bothered to document properly. And I speak as someone who's intimately familiar with it, having extended the Handler classes, etc. But it's next to impossible for somebody just starting out to figure out how to configure it!

And my nomination for the next worst? Log4J. That's because the author wants to make money from selling the book (not unreasonable). And while I'm about it let's mention good old Apache Jakarta Commons Logging (JCL). Why do otherwise (presumably) intelligent people just go completely ga-ga when it comes to explaining how these things work?

All-in-all, I've probably misspent more hours figuring out why logging wasn't doing what I expected than Hibernate, even! But, using Hibernate is extremely complex (because it models something very complex) and getting it wrong is just part of being a developer. But logging? It should (and could) be the simplest thing in the world!

At this point, it would be great if I could link to a really good blog page that explains how to use JCL with JDK14 logging. But there isn't one. Maybe I'll write one myself soon. For now, I just want to rant!