Wednesday 2 May 2007

Cautious welcome on closure JSR - too soon for consensus

Neal Gafter announced a draft closures JSR a few days ago. I'd like to give the JSR a cautious welcome, but also wish to emphasise that the 'consensus' term could be misleading.

At present, there are three key proposals in the 'closure' space - BGGA from Neal Gafter et al, CICE from Josh Bloch et al, and FCM from Stefan and myself. Conceptually, these proposals meet differing visions of how far Java should be changed, and what is an acceptable change.

  Simpler                                           More complex
   No change    Better inner     Method-based     Full-featured
                  classes          closures         closures
   No change       CICE              FCM              BGGA

In deciding to support this JSR, a number of factors came into play for me:

  • I want to see closures in Java 7 - unfortunately it may already be too late for that
  • I'm not a language designer, and don't have the knowledge to run a JSR myself on this topic
  • The text of the draft JSR is clearly phrased as a derivation of the BGGA proposal
  • There has been positive feedback on Java forums about each of the three proposals - the Java community does not have a settled opinion yet
  • Many Java developers feel uncomfortable with any change in this area
  • Groovy, a Java derived language, uses an approach similar to FCM
  • This is the only JSR proposal currently available to support
  • Private emails

In the end, taking all of these factors into account, I took the judgement that this JSR was currently the only game in town and it would be better for me to participate rather than stand outside. And that is why I give it a cautious welcome.

Unfortunately, the extensive list of pre-selected Expert Group members (not including FCM) and Expert Group questionnaire came as rather a surprise, especially given the 'consensus' tag.

On the point of consensus, some commentators have assumed that this means a compromise proposal has been created, or agreement reached. This isn't the case.

Looking forward, my preference would be for Sun to finally play their hand on this topic. As a neutral player, they are well placed to encourage all parties to take a step back for a minute and put the focus firmly on what is best for Java going forward. Let the Sun shine :-)


  1. I think it would be a nice idea if everyone, include the current expert group members, who might be interested in joining the expert group completed the expert group questionnaire and all the responses were made public. Then an expert group could be chosen that represents a cross section of views and backgrounds and one which has representatives of all the different proposals on it. If you want consensus then you need to be inclusive.

    It does seem from the proposed JSR that at present the idea is to endorse the BGGA proposal rather than find a consensus. Even if that is not the case, as you correctly point out, that is the impression given by the proposed JSR.

    I also find it worrying that Joshua Bloch (who was one of the CICE proposers) isn't on the expert group. This may be because he has already done such great work on expert groups in the past that he wants a rest - and anyone would understand if that was his opinion. However if he thought the JSR had problems and that was why he wasn't on the group then I think that a rethink is called for. Unfortunately Joshua Bloch hasn't let his reasons be known.

  2. Rest assured that if a JSR for closures in Java is submitted to the JCP PMO (Project Management Office), and is approved the JCP EC (Executive Committee), I will offer my services on the Expert group. A blog post is not a JSR proposal; to the best of my knowledge, no JSR proposal for closures has been submitted yet.

    As Stephen noted, there is a broad spectrum of alternatives for closures in Java, and the JSR draft in question effectively constrains the expert group to BGGA or a close relative. There is a debate raging through the Java community, and this draft effectively cuts short that debate. It would leave large parts of the community feeling disenfranchised. Calling it a consensus proposal does not make it so.

    BGGA is sufficiently complex that it would benefit from implementation and experimentation before the Java community commits to adopting it. This precedent was established by generics, which was tested for several years in the Pizza language before a JSR was submitted.

    I could support a less restrictive JSR for closures at this time: such a JSR would not preclude experimentation, nor would it force the expert group to choose BGGA if another alternative turned out to be a better fit.


  3. Calum MacLean2 May 2007 at 19:36

    Hi Stephen
    I've read through your proposal, as well as most of the other proposals. While I haven't done a detailed comparison, I think there are good parts in all the proposals.
    (In particular, I think that you and your co-author have done some great work on your proposal.)
    So I'd definitely support there being representatives of all of the proposals on a JSR, and the JSR being open enough to allow for solutions at either end of your "simple <-> complex" spectrum.

  4. @Joshua,

    Thanks for letting your reasons be known, it is encouraging that you are interested in becoming part of an expert group. Also I think that the strategy you suggest of making limited changes at this time and experimenting further with the more radical suggestions is a good one.

    Ideally the 'consensus' proposal would allow a staged introduction starting with minor changes and building to something more complex once the effect of each stage can be assessed.


Please be aware that by commenting you provide consent to associate your selected profile with your comment. Long comments or those with excessive links may be deleted by Blogger (not me!). All spam will be deleted.