Softpedia

Just got an email to the effect that my toString package has today been adopted by Softpedia and that there have already been 40 downloads (!?). Not sure how significant Softpedia really is, but it's nice to know somebody likes it.

Meanwhile, I've been making some improvements to the Darwin package, including some performance improvements, better control of mating, and updates to the evolution mechanism itself.

OK, back to work!

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.

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!

Hillyard's third law of programming

If you're trying to find a bug in your program and you just can't see it, ask a colleague for help. It's unlikely that the colleague will find the problem for you, but it's very likely that you will, as the process of explaining what you're trying to do invariably exposes the design flaw that your brain has hitherto been suppressing.

Hillyard's second law of programming

If you are looking for a bug in your program and you know that there is at least one "to-do" item that's related to the part of the code you think is responsible, fix the damn to-do. At least half of the time, it will solve your problem.

JSR-299 and Weld

Went to hear Gavin King (creator of Hibernate) last week at NEJUG. He was describing JSR-299 and the JBoss reference implementation (called Weld). OMG. Such fantastic stuff. I can rewrite Darwin to use it and get rid of all of those XML files – everything is done by annotations. Furthermore, there is a notion of life-cycle, as well as scope, for beans. Beautiful! And much more.

Here are Gavin's notes (hopefully, I'm not infringing any copyrights by posting this link).

Hillyard's first law of programming

If you're looking for a bug and you can't find the bug where you're looking, then you're looking in the wrong place! [Corollary to Holmes' law: when you've eliminated the impossible, whatever remains, however improbable, must be the truth]

Introduction

This blog is about software, generally speaking it will be Java-related. Sometimes there will be rants, other times reminders about the proper way to do things. Sometimes I might contribute something witty or useful.