Thought Spearmints

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. :)

Props for JOptSimple

Yay!

JavaOne 2008, Day 4

"The Layperson's Guide to Building a Better User Experience" -- in short, you are a user experience designer; take interaction design, user experience, and user personae seriously; and read up.

"Semantic Web for the Working Ontologist" -- Interesting discussion from the chief scientist of TopQuadrant.  Interesting mention of D2RQ, a library to expose relational stores as stores of RDF triples; though to hear Dean Allemang tell it, there isn't much of a community forming around D2RQ.

Neat presentation from two Jython commiters about the challenges involved in compiling Jython code down to JVM bytecode.

Two Selenium cognoscenti, Dan Fabulich and Patrick Lightbody, gave a decent account of Selenium for web testing.  Apparently the XPath support library that Selenium uses has been tuned quite a bit and should be faster in the new 1.0 beta.  Still holding out hope that it can handle non-trivial (and even some trivial) XPath expressions on IE.

JavaOne 2008, Day 3

"Using FindBugs in Anger", with the great Bill Pugh -- nice summary of a great tool.  I liked the slide listing some common (but incorrect) wisdom about bugs and static analysis: programmers are smart, and smart programmers don't make dumb mistakes.  We all make dumb mistakes.  I really like FindBugs, and use it on my open-source projects.  Interesting to learn that there is commercial support for it via Fortify Software.  Pugh described how large organizations such as Google use FindBugs on large code bases, strategies for prioritizing resolutions to issues FindBugs detects, tracking issues historically over time and adding issues to bug databases, etc.

This is the second time this conference I've seen or heard "Q & A" and QA (as in quality assurance) confused.  Hm.

"Writing Your Own JSR-Compliant Scripting Language" was a good overview of the new Java 6 API for launching scripts that can interact with the calling Java program.

"Pimp My Build" offered some very Ant-specific hints for maintaining build scripts -- it all pretty much boiled down to refactoring out common bits and treating your build scripting with the same refactoring and coding care you would afford your production code.

"The Future of Guice" from "Crazy Bob" Lee and a couple of other Googlers -- "Types are the currency of Java" -- nice mantra, and it clearly informs the decisions the Guice crew made regarding how to indicated injections, etc.  Came with a promo code for an ebook version of the aPress title on Guice.  Bonus!

JavaOne 2008, Day 2

On Day One, I picked Josh Bloch's brain for a bit about whether the BGGA closures proposal was redeemable if the gnarlier bits might be removed, leaving it basically with function types.  It was cool to mingle with the Java "rock stars", if only for a moment.

I enjoyed Neal Gafter's Day Two talk "Closures Cookbook" immensely.  He gave a very clear exposition of the BGGA proposal and the use cases propelling it.

Right out of the gate, he started with a disclaimer: Google is open to multiple parallel investigations of closures but is not currently prepared to commit to any particular proposal.

The cool bit is that closure literals can be used as instances of one-method interface types whose method parms and return type are compatible with those of the closure:

    Runnable r = { => doWhatever(); }
    r.run();

    Callable<String> cs = { => "result"; }

    Comparator<String> reverse = { String s1, String s2 => s2.compareTo(s1); }

    ItemSelectable is = ...;
    is.addItemListener( { ItemEvent ev => doSomething(ev, is); } );

Apparently there are technical reasons why this couldn't be done for abstract classes with one abstract method, didn't quite get the picture...

Also considered were aggregrate operations,  near and dear to my heart:

double highestGPA = Double.MIN_VALUE;
for (Student s: students) {
  if ( s.graduationYear == THIS_YEAR ) {
     int gpa = s.getGPA();
     if ( highestGPA < gpa )
       highestGPA = gpa;
  }
}

double highestGPA =
    students.filter( { Student s => s.graduationYear == THIS_YEAR } )
            .map( { Student s => s.getGPA(); } )
            .max();

I just love how the second reads -- nothing like method names to make intent clearer.

An extended example involving an API for timing units of code:

interface Block<R, throws X> {
    R execute() throws X;
}

public <R, throws X> R time(String opName, Block<R, X> block) throws X {
  long startTime = System.nanoTime();
  boolean success = true;
  try {
    return block.execute();
  }
  catch (final Throwable ex) {
    success = false;
    throw ex;
  }
  finally {
    recordTiming(opName, System.nanoTime() - startTime, success);
  }
}

int f() {
  time( "opName", { => someStatements } );
  time( "opName", { => return computeResult; } )
}

Yowza.  Nice how it genericizes over whatever exceptions the block may raise (including none), and whatever the block might return (including nothing).  Note the use of "safe re-throw" by marking a catch parameter final (proposed for JDK7).

Alex Buckley and Stanley Ho gave a nice summary of the first-class language and tooling support for modularity in Java (JSR 277).  Seems a JAM module would be able to leverage OSGi bundles and repositories?  Nice.

The Java Persistence API 2.0 talk was packed.  Ridiculously packed.  Fire marshal, anyone?  People continued to stream in well into the presentation.  One guy ended up accidentally kicking separating my MacBook power supply from the pluggable portion of it.  Not so much as a "sorry, my bad" -- never looked back.  I understand there's a certain amount of Asperger-style intense focus at a geeky conference, but come on.  Sorry if I seemed a bit peevish, but several hot buttons were hit in this one: overcrowded room, disregard for personal space, cell phones ringing after several admonishments to silence them, relatively shrill speaker a bit trigger-happy on the slide flipper ... I guess my bitching about it was way more annoying to the guy in front of me, as when I uttered the line, "As a courtesy to others, please silence your cell phones", he shot back with the timeless classic, "Why don't you silence yourself, dude?"  Cue the slow clap.

Anyway, I didn't get that much out of the JPA talk.  I'm not doing much RDBMS work these days, but at least I have a sense of where to look for JPA info.

I bailed out of the talk "Unit Testing DB Operations with DBUnit" a shade early to catch a power nap -- I had no idea how exhausted I'd be after 1.5 days at the conference.  That said, I scheduled a number of sessions and BOFs -- perhaps next time I'll pace myself a bit better.  Besides, I've used DBUnit before, and it it quite nice -- not much new ground covered for me.

"Boldly Go Where the Java Programming Language Has Never Gone Before" -- Geert Bevin's talk's premise was that "You don't have to master new languages, tools, or libraries to deliver applications that go much further than what the standard Java platform provides."  He gave compelling demonstrations of Terracotta, an OSS clustering solution for the Java platform; RIFE, a component-based web framework featuring continuations; GWT; and Google Android.  Very nice stuff!

"Building RESTful Clients with JavaScript, Ruby, and JavaFX" -- not much here you couldn't get from an introductory article on REST.

Ola Bini of ThoughtWorks gave a talk about TW's use of JRuby.  As an ex-ThoughtWorker I was eager to hear about what TW's been up to in the Ruby world -- clearly, quite a lot.  I left TW just as it was beginning to pursue and land Ruby/Rails work.  Right now, 40% of its US revenue comes form Ruby/Rails work.  Surprising to learn that test suites run more slowly often in JRuby than in MRI -- less opportunity for JIT leverage, it seems.  Often they run test suites in MRI pre-commit, then with JRuby in CI build.

"Cooking Your Own Groovy Builder: A Step Forward into Domain-Specific Languages" -- nice exposition of the Builder support for languages that describe hierarchical structures such as XML documents and Swing widgetry.

JavaOne 2008: more from Day 1

Some random thoughts from Day 1 of JavaOne 2008 (belated):

Wi-Fi connections spotty at best.  Kind of disappointing they couldn't handle the traffic they could have reasonably expected.

"JRuby: What, Why, How...Do It Now!" -- Nice JRuby overview.  An admonishment not to be scared to let go of static types -- nice.  Interesting how Groovy lets you go either way, sticking with the manifest typing of Java or introducing latent types as you please. 

Demonstrated blocks for deferred invocation, and their uses in internal collection iteration and encapsulating transactional code -- important use cases for their potential inclusion (closures) in the Java core language.  I wonder if such language features are better left to the other JVM-based languages that are sporting them already, rather than over-complicating what started out as a simple language.  Josh Bloch speaks often of a "complexity budget" for a language, and that perhaps Java is overspent.

Much of Rails code is created on startup.  Interesting.  Cool that Ruby allows you to define classes and methods at runtime, and to open up classes for such additions.  Cooler still that in JRuby, core JDK classes become open (even those that are final).  Apparently the term for opening up and tweaking core classes in this way is "monkey patching" -- derogatory term in the Python world, celebrated in the Ruby world.

JRuby leverages native threading of the JVM for better performance, as opposed to the "green threading" of the MRI.  There is a jirb analogue to irb in JRuby -- nice.

"require 'java'" to use JDK classes in JRuby code.

"require 'irb/completion'" in jirb to enable auto-completion in the console.  Sweet.

Java methods can be invoked in their regularCamelCaseWay or via_lower_case_underscored_names.

Plenty of help for building Swing apps in JRuby -- Cheri::Swing, Profligacy, MonkeyBars

"More Effective Java" -- New edition of Bloch's "Effective Java" is out -- covers new ground of generics, annotations, enums, concurrency libs, etc.

Use wildcard types, bounded or otherwise, generally only as method parms, not as return types.

'PECS' -- Producer extends, Consumer produces -- mnemonic for remembering when to use ? extends X versus ? super X.  If a method is both a producer and consumer of X, no wildcards needed on the generic type.  Users should not have to think about wildcards to use your API.

Enums -- do not rely on ordinal() for business logic, if you need to use an integer distinguisher as a field for each enum, use a constructor with an integer parm.  Don't depend on which ordinal() integer is assigned to each member of the enum.  Good discussion of EnumSet and EnumMap.  Bit fields are obsolete in Java.

The power of readResolve() to enforce singularity of singleton Serializables has been oversold -- readResolve() works only if all fields of the Serializable are transient.

Enums are inextensible, but can implement interfaces and each member of the enum can supply an implementation.

Good discussion of various lazy-init techniques.

Java 5 memory model enhancements apparently make double-check locking idiom work now.

"Upcoming Java Programming Language Features" -- Alex Buckley, spec lead for JDK 7 JSR, speaks of stewarding the "moral and technical integrity" of Java.

"A good application is rich; a good language is pure." Gosling, about adding features to a language: "Just say no, until threatened with bodily harm".  Tougher to add language features due to the explosion of interaction between the features.  In an app, features relatively rarely interact, and more is considered better.  Not so with language features.  With a language, fewer, more regular features are better.

"Respect the past": new keywords shouldn't break existing code (a la 'assert', 'enum').
"Respect the future": allow room for syntax to breathe.  Syntax/semantics of a feature should not conflict with those of existing or potential features (quite a tall order!)
"Respect the model": every language reflects a model of computation.  Java's model: general-purpose, class-based, OO, concurrent, civilized relationship to APIs, aligned with JVM.  When evolving a language with features, have those features enable more regular and abstract programs.

Principles that recognize the Java model:

• Encourage high-level practices -- do the right thing
  • A program's meaning is hidden by accidental complexity (Fred Brooks)
• Covet clarity -- do the thing right
  • A program is read far more often than written/modified
  • Language abstractions are the primary enabler of clear code
• Prefer static typing -- stay safe
  • Proves absence of some bugs at compile time
  • Most Java keywords are about static typing
• Isolate the language from the APIs -- stay abstract
  • A language is more widespread than its APIs
  • APIs come and go, language remains
  • Language compromised by linkage to a deprecated API.
  • JLS used to define java.lang.

Under consideration:

• Disjunctive exception types in catch statements (yay!)
• Safe re-throw of exceptions in catch blocks when exception var is marked final
• First-class modularity support in the language and tooling
• JSR-308 using annotations to effectively introduce pluggable type systems into language -- for enforcing things like @NonNull, @Readonly, @Immutable, etc.

Not of interest:

• User-defined operator overloading
• Multi-methods
• Macros
• Dynamic typing (latent typing)

"GUI Testing Made Easy" was a nice introduction to the FEST library by former ThoughtWorker Alex Ruiz.

"Practical Applications of Static Bytecode Analysis and Transformation for the Java Platform" -- great demonstrations of tools that use libraries like ASM for tweaking bytecode in interesting ways:

• Cobertura for instrumenting bytecode to be executed by tests, and measuring coverage of that code when tests are executed against it
• Google Singleton Detector
• Google Testability Explorer

"Tips and Tricks for Using Language Features in API Design" -- lots of material to cover in a very short time.  I felt the speaker just ripped right through some topics that to me were non-obvious.  Slow down!  Interesting to learn a potential good use for wildcarded generic return types: return of an internal collection without having to copy it (callers won't be able to add/modify).

Be wary of interface covariant returns -- great for concrete impl classes, but in branching interface hierarchy, watch out.

If you're going to add an exception type, maybe make it carry more info other than just a new name?  Cause?  How to recover?  Also, in libraries, do take care to add serialVersionUIDs to your exception classes -- Exceptions are Serializable.

JavaOne 2008 -- Day 1 preview

I'm at JavaOne this year, my first trip to the big dance.  Based on the rock-concert lines forming for the first General Session, I'd say the conference is doing pretty damn well.

Flight into SFO from DFW last night was without incident.  It was remarkably easy to get to my hotel downtown, about six blocks away from the Moscone Center -- hopped the AirTrain to the BART Station, quickly purchased a ticket to the Powell station, hopped on, and twenty minutes or so I was five blocks away from my hotel.  Great success!

I'm registered for the following Day 1 technical sessions/BOFs:

• "JRuby: Why, What, How...Do It Now", featuring the great Charles Nutter
• "More Effective Java" from Mr. Effective Java himself, Joshua Bloch
• "Upcoming Java Programming Language Changes", featuring Neal Gafter, he of all things Java-compiler-related
• "Practical Applications of Static Java Technology-Based Bytecode Analysis and Transformation"
• "Tips and Tricks for Using Language Features in API Design and Implementation" -- perhaps some good thoughts there about fluent interfaces
• "Migrating to Maven 2 Demystified".  I am in the midst of doing this for my Java open source projects, so perhaps I can pick up some tips.
• "GUI Testing Made Easy", with Alex Ruiz and Yvonne Price of FEST.  Alex and I met each other briefly while both at ThoughtWorks -- it'll be good to see what he's been up to.

More updates as the talks warrant.

Generic Java functors: When you don't care to return a value

My colleague Rod presented me with the following (paraphrased):

    public interface Executable<T> {
        T execute();
    }

The question arose: What if an implementor doesn't have a meaningful value to return?

    public class MyExecutable implements Executable<____> {
        // ...
    }

You could fill in the blank with Object and return null or this, perhaps. However, we agreed that this doesn't communicate as well to its clients the fact that there really isn't a return value and it shouldn't even be used. You can't use primitive void since it really isn't a type, and is a primitive anyhow (forbidden as a generic type parameter). What to do?

How about java.lang.Void?

    public class MyExecutable implements Executable<Void> {
        public Void execute() {
            // do stuff
            return null;
        }
    }

We felt that this clearly communicated that there's no useful return value for the functor. In fact, since java.lang.Void is uninstantiable, the only value the functor could return is null. Nifty, eh? Ever think you'd use java.lang.Void?

Jaggregate internally uses a number of generic functors that really don't need to return anything. I changed them to return java.lang.Void instead of Object, and I'm happy with the results.