Does BGGA close as java solution?

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 answer by @ danny_l / Danny Lagrouw:

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

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

I would even like to help and make an effort. Although I do not know where to start.

(above is a snippet of blogpost I wrote a topic about this)

What do others think of this idea?

Answer 1

The word "preprocessor" brings me back to C ++, and it scares me.

There is a strange dichotomy: I celebrate a diverse language garden on the JVM, but I think that the "Mama Bear" (aka Java) should not be fragmented this way. We need a solid foundation.

However, I am in favor of closing the BGGA. I also believe that language should provide its full potential. If there are people on the team who cannot handle closing (or generics or threads (!!)), then this team should check for itself with code reviews and static analysis.

Perhaps one idea would be to enable compilation to “prohibit” additional features like this, but even that seems a bit harsh.

I think the “chatter” idea is really trying to solve the problem of broken leadership in the Java space. This problem looks more political and diplomatic than technical.

Answer 2

The problem with creating these things is that you are creating a fragmented language.

The java language is the smallest part of what java, java does. Most of them are libraries and culture. The creation of closures and generics with bolts means that either they cannot be used in the main libraries, or that the main libraries will require that the bolt be included in the SDK used. This would at best create fragmentation inside the libraries (since some developers work in the kernel, and some require chatter), and in the worst case, this means that we will begin to have java distributions in the java estate, each of which contains a different set of jars and "bolts".

I would say that this is the beginning of slippery failures, I would rather stay.