I'm all for this proposal. The biggest advantage I can see is not that we'll (just) be able to write closures to support, for example, using and freeing resources, but that the Java language can be extended along certain lines without waiting for the fairly long release cycle to approve and produce something new. It should also take some pressure off the compiler writers, in that some features which previously would require a language change can, in some fashion, be accomplished with closures. Neal already pointed this out, I'm just agreeing this is one great aspect of the proposal.
I expect there will be some wacky uses of this, and libraries for specialists, but I'm not really worried about language fragmentation or dialects. For one, those of us who end up using more general-purpose libraries than we write, it's to our advantage if those who write general-purpose libraries can create and extend those libraries with less code and less effort. Also, it may keep the Java tent open, welcoming more people into the community (or encouraging them to stay).
I also expect that, as with annotations, we'll see some leading-edge closure libraries coming out of the open-source world, with some being folded back as "standard" closures shipped with JDK 8 and beyond.
I am a little concerned about how the syntax will actually read once it's done. With generics, the very simple use-case (avoiding a cast to a variable) is very clear, but in practice I see people struggling with how to write generic methods and classes, and a great deal of frustration with the more complex cases; many times you have to search around to find someone who's run that gauntlet to explain what the heck is going on. I hope we can avoid that with closures. The good news is, with a free-speech javac we can have experimental versions of this sooner rather than later, and find out what it looks like in practice. That's already happening with local variable type inference, and I think it's a great thing.
As far as just starting a new Java--I think this calls for a much wider (and deeper) discussion. The number of languages that run, or at some time ran, on the JVM is humbling when you then remember that you've neither heard of, or used, the vast majority of them. My guess is that J6 and the scripting API will help, but I'm still waiting for a general-purpose solution that lets me: // in Java val = new SomeOtherLanguageObject().calculate(...);
using a bridge to instantiate and communicate with other languages is not just sub-optimal, it's a dead end for large-scale integration (or many integration points). If I can easily include multiple languages in one project, from the same IDE, I'll be more willing to explore.
Last, serious kudos to Neal for taking the heat as the public face of this closures proposal. While there were have been some good criticisms (or at least reasonable critical positions) put forward in the JL discussions, there's also a lot of people who are just plain mean.
Neal, we're with you, man. You rock. Don't stop thinking about tomorrow.
Patrick
Flat View: This topic has 19 replies
on 20 pages
[
«
|
121314151617181920
|
»
]