Mark Reinhold provided a significant clarification of issues surrounding the surprise announcement that closures will be included in Java 7 in his new blog post Closures for Java: The Q&A. I'm featuring Mark's post in Java Today.
Mark spends some time both defending himself and stating that there is good reason why he ended up being the one to initiate a new proposal for inclusion of closures in Java 7. He says:
At heart I’m an old Lisp
hacker; more specifically, I’m a past teacher and implementor of the Scheme
dialect. Closures are completely natural to me—along with tail
recursion, continuations, and the definition of procedure call in terms
of rename plus goto. (I accept that I’m unusual in this regard.)
Having said that, in all my years at Sun I’ve done my level best to
respect and preserve the “feel of Java,” as James calls it. Java incorporates
some of the great ideas of the Lisp tradition but it is not, and never
will be, a Lisp. So I’ve always been a bit nervous at the prospect of
adding closures to Java. If we do so then we absolutely must preserve
the existing character of Java as a language for “working programmers.”
Well, for me, this builds confidence that this wasn't a sudden, off the cuff, decision by someone who really doesn't understand all the issues involved.
Mark cites the extension of the JDK 7 schedule as being among the reasons why closures returned to the Java 7 agenda. He reiterates the need "to gain good support for writing scalable
parallel programs using bulk-data APIs such as parallel
arrays."
I have lots of experience developing multithreaded code, but I haven't done a lot of this in Java (most of my multithreading work has been in C and Fortran on Solaris machines). But, knowing that Mark has expertise in the famed Lisp language, as well as Java, makes me feel more comfortable with the idea that Java's current multithreading support is not sufficient.
The protocols for parallel arrays in Java indeed remind me of the Threading Building Blocks (TBB) open source C++ libraries (I was the first community manager for that project); and, though the syntax is very different, I'm also reminded of the OpenMP API for parallel programming in C/C++ and Fortran.
I spent lots of time seemingly talking into the wind on my Intel Software Network Blog (written when I was TBB community manager) -- saying why I believe multithreaded programming will be the REQUIRED mode of programming in the future. The history and current state of computer processors dictates this, IMO.
Take a look at the history of computing: it consists of constant, rapid increases in processing power and speed (see Moore's Law). Up until a few years ago, speed increases were largely achieved by making certain elements of processor cores thinner, thus lessening the required time for signals to traverse the layer of silicon. A few years ago, we reached the point where the number of layers of silicon was in the teens or so. Engineering thinner layers became impractical. Thus, also, ended the historical realm of validity of Moore's Law.
Henceforward, the most practical way to increase the amount of work a single processor could do was to add more cores. Hence, the "Multicore challenge." Going forward, for applications to be faster, they will need to be able to effectively utilize multicore processors and multiprocessor computers. For this to happen, the applications need to be efficiently multithreaded.
I could go on, and I will in future blog posts. For now, I'll close by saying that if closures in Java will significantly enhance Java's capability with respect to developing multithreaded software applications that can efficiently take advantage of today's multicore processors (and tomorrow's 16 and 32 and 64 cores x processors systems), then I think it's an absolute necessity to add closures to Java 7. Right now is when Java needs the capability to efficiently multithread applications. In fact, Java may be a bit behind the curve, compared with C, C++, Fortran, and .NET... That's not good!
At Devoxx last month I said that it's
time to add closures to
Java. That statement, and my follow-up blog entry,
elicited reactions ranging from enthusiastic support to skeptical acceptance
to cynical indifference. It certainly motivated lots of tweets and lots
of questions. In classic Stephen
O'Grady style I'll attempt here to summarize and answer some of the key
questions I've seen, so far...
Java EE 6 is now a JCP approved specification. The Reference Implementation in GlassFish v3 is getting a final dressing and will be released soon, along with the TCK. Along with traditional Java EE applications, GlassFish v3 also allows to deploy dynamic languages & associated Web frameworks like Ruby-on-Rails, Groovy and Grails, Python and Django to be easily deployed. I'll be explaining these technologies and much more at Indic Threads 2009...
The maven project icons are dependent on the maven project type - EJB, EAR, WAR, JAR etc. This helps you to recognize the type already in the "Projects" tab.
New REST wizard: asks you whether you would like to provide your own Application subclass, generate one (default), or enhance the web.xml (the old Java EE 5 way). The REST-Jars, however, are still copied to GF v3, what is actually not needed. You can safely exclude it from the packaging. Then the WAR with EJBs + REST will be rather small (8 kB in my case)...
Finally ... SwingX-WS 1.0 have been released. And no, don't ask, I don't have any explicit release notes for that. No bells and whistles. The release is just an official version of something that has been lying in repository for quite some time. BTW, if you would like to become a committer on this project please let us know on the SwingLabs forum. You can find the files at SwingLabs download page as usually. On related note, all of the active SwingLabs sub projects - SwingX, SwingX-WS, JXLayer and PDF-Renderer are now in the central maven repository under the org.swinglabs group id. If there is any older SwingLabs sub project release you would like to see in central repo shout. Although I would think that all that is there already should be enough...
Come take a quick, guided tour of Test-Driven Development practices! The following presentation is a module from the 'Testing and Test-Driven Development for Java Developers' Course. It goes through a worked introduction to TDD theory and practices. Enjoy! ...
As I previously said, one of the advantage of using an RDF store is
that you're offered with a bunch of standard “ontologies”, that are
standard ways to do some common things (sounds nice, doesn't it?).
Those things are related to managing relationships among things. A common need that clearly emerges when you extensively use the
as(...) pattern that I've explained in my previous blog is
how to specify that two distinct object are indeed referring to the
same concept. Adding some more examples to my
previous post, I could write things such as ...
johanrask has a question about OSGi and @Resource - Is the reference static: "Hi, I have looked through the examples with declarative services etc in conjunction with @Resource annotation. I am curious if the resource annotated with @Resource is dynamic (is it tracked, will it be replaced if a new one comes..."
And ernestojpg is Using different SSL Listeners on the same domain: "Hi all, I've configured two different SSL listeners on the same Glassfish instance/domain, one of them without client authentication (port 443), and the other with client authentication (mutual certificate exchange, on port 4433)..."
In our current Spotlight, Sebastien Arbogast talks about My Devoxx Discoveries of the Year
: "Every year, the main reason why I go to Devoxx is to discover new stuff. For me it’s all about technology watch. The internet and RSS feeds are my main tech watch instrument but there is one thing that is harder to get through RSS: feelings. Conferences like Devoxx are a unique opportunity, not only to see what’s happening but also to sense how the community is feeling about it, which is at least as important to anticipate on what’s going to be important..."
Registered users can submit event listings for the java.net Events Page using our events submission form. All submissions go through an editorial review before being posted to the site.
Archives and Subscriptions: This blog is delivered weekdays as the Java Today RSS feed. Also, once this page is no longer featured as the front page of java.net it will be archived along with other past issues in the java.net Archive.
Previous Topic
