BGGA closures as a bolt-on solution to java?

Question

Yesterday @headius / Charles Nutter came up with a very interesting idea on twitter:

@danny_l Gafter made the same mistake; I don't mean a forked Java any more than Groovy is a fork. I want a "mostly Java" with closures.

or the reply by @danny_l / Danny Lagrouw:

@headius or could the BGGA prototype be "bolted on" any future version of Java? That might be useful

That really is what I would like to see as well. Can't we have some sort of bytecode preprocessor to make the BGGA prototype work on any modern Java version? I mean scala, Groovy and JRuby have closures and produce valid bytecode!

I would even like to help and put effort in it. Although I don't really know where to start.

(the above is an excerpt of the blogpost I wrote about this topic)

What do others think of this idea?

Answer 1

The problem with making these things a bolt on is that you create a fragmented language.

The java language is the smallest part of what makes java, java. The libraries and the culture make up the larger part. Making closures and generics a bolt on means that either they cannot be used in the core libraries or that the core libraries would require the bolt on to be present in the SDK being used. This would at best create fragmentation within the libraries (as some developers work to the core and some require the bolt-on) and at worst would mean that we will start having 'distributions' of java in the manor of java each containing a different set of jars and 'bolt-ons'.

I would say this is the start of a slippery slop I would rather stay off of.

Answer 2

The word 'preprocessor' takes me back to C++ and it scares me.

There is a weird dichotomy: I celebrate the diverse garden of languages on the JVM, but I think that "Mama Bear" (aka Java) should not become fragmented like this. We need a solid foundation.

That said, I am in favour of BGGA closures. I also think a language should provide its full capabilities. If a team has people who can't handle closures (or generics, or threading (!!)), then that team should police itself through code reviews and static analysis.

Maybe one idea would be to have a compile-time switch to 'disallow' advanced features like this but even that seems a bit harsh.

I think the 'bolt-on' idea is really trying to address the fractured leadership in the Java space. That problem strikes as being more political and diplomatic than technical.