Thought Spearmints

JOpt Simple 3.0-rc2 released

JOpt Simple is my Java library for parsing command-line options. For 3.0-rc2, I've overhauled the example page quite a bit, so that hopefully the capabilities of the library and the option syntax it supports are clearer. I welcome all constructive feedback.

JOpt Simple 3.0-rc1 released

JOpt Simple is my Java library for parsing command-line options.  Release 3.0 will abandon support for pre-Java-5 JDKs, in favor of the new more typesafe ways of retrieving arguments of command line options. I will continue to support the 2.x line of development as needed. Give JOpt Simple's new look a test drive, and let me know what can be improved.

I'm pleased to see increasing adoption of JOpt Simple, most notably in Gradle. If you're using JOpt Simple in your project, do let me know.

JOpt Simple 3.0-beta1 released

JOpt Simple is my Java library for parsing command-line options.  Release 3.0 will abandon support for pre-Java-5 JDKs, in favor of the new more typesafe ways of retrieving arguments of command line options. I will continue to support the 2.x line of development as needed. Give JOpt Simple's new look a test drive, and let me know what can be improved.

Profiteroles, huh?

I'm not this Paul Holser. Impressive feats, though, I guess...or somethin'...(trail off)

"Real-world" programming

It's all real-world programming.

JOpt Simple 2.4.1 released

JOptSimple is my Java library for parsing command line options. Release 2.4.1 fixes a bug with the new help screen generation changes. Thanks to Hans Dockter for reporting it. As usual, download instructions are available at the project's website.

JOpt Simple 2.4 released

JOpt Simple is my Java library for parsing command-line options.  Release 2.4 sports some bug fixes, internal reorganization, some new features such as option synonymy and a cleaned-up help printing facility.  JOpt Simple seems to be generating more interest over time -- I'm glad it's helping programmers out with an uncomplicated API and more-than-adequate feature set.

Writing an Ant task for Jumble mutation tester

Jumble is a pretty neat tool for doing mutation testing on your Java code, to see how effective your JUnit tests are at catching small changes to the test subjects. It works by mutating bytecode rather than source (a la Jester), and so is much faster to execute. However, I was sad to see that there is no accompanying Ant task or Maven plugin. Running Jumble in either of these tools could certainly be accomplished by simply cooking up a Java VM invocation with the appropriate command line arguments...but I think it'd be useful to have tasks/plugins that, among other things, fail the build if a class's Jumble score dips below a defined threshold. Many code coverage tools (e.g. Cobertura) have such provisions in their Ant/Maven tasks/plugins.

So, I'm undertaking to write an Ant task for Jumble. Initially it will invoke the tool via its CLI and scrape the output for scores, but ultimately I'd like to integrate the task more tightly with Jumble's API. Hopefully that API lends itself well to being hooked into.

Let jQuery rock your world

Recently at work we found ourselves needing to act on groups of table cells in an HTML page which shared a common class attribute value. After a couple of minutes of hemming and hawing about what a whipping the by-hand JavaScript DOM code would be to write, I heard faint echoes of how great jQuery was at eliminating that whipping.  Sure enough, in another couple of minutes, after downloading the library and perusing the docs a bit, we got done the task we wanted to: turn spans within cells attributed a particular way into anchors.

If you do any JavaScript programming, you owe yourself a swim through jQuery. Perhaps your world will be rocked like mine has the past few weeks.

Jaggregate with BGGA closures

The latest snapshots of Jaggregate seem to work well with BGGA closures converted to functors and predicates. I had to extract one-method interfaces from the abstract *Function and *Predicate classes (the interfaces are "*Functor" and "*Condition") -- they basically correspond to the single abstract evaluate() and matches() methods -- and to change method signatures to accept the interface types rather than the abstract class types. This was to allow closure conversion to occur -- if the parameters remained of types corresponding to abstract classes, the conversions would be rejected.

The one tweak needed was that initially, the BGGA prototype (dated Apr 27 2008) was rejecting calls such as:

    Interval.fromTo(1, 4).forEachDo(System.out#println(int));

where the closure (here, a method reference) passed as a UnaryFunctor had return type void, and the signature of forEachDo() was:

    void forEachDo(UnaryFunctor<? super Integer, ?>);

If I changed the signature to:

    <R> void forEachDo(UnaryFunctor<? super Integer, ? extends R>);

things were fine, but I wasn't sure why the change would be necessary.

I mailed Neal Gafter about this, and seemingly within hours he'd fixed the issue and released a new cut of the prototype (dated May 11 2008). Many thanks to Neal for the quick turnaround and for fighting through my silly questions. :)