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 :-)
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.
ReplyDeleteIt 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.
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.
ReplyDeleteAs 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.
Josh
Hi Stephen
ReplyDeleteI'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.
@Joshua,
ReplyDeleteThanks 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.