Skip navigation
ANNOUNCEMENT: is currently Read only due to planned upgrade until 28-Sep-2020 9:30 AM Pacific Time. Any changes made during Read only mode will be lost and will need to be re-entered when the application is back read/write.

A majority of developers who voted in the just completed poll consider the "Plan B" decision to release Java 7 with a smaller feature set, saving the other features for Java 8, to have been a good one. A total of 531 votes were cast. The exact question and results were:

Was the decision to release Java 7 earlier by pushing some enhancements into Java 8 a good one?

  • 60% (318 votes) - Yes
  • 11% (56 votes) - Maybe
  • 11% (59 votes) - No
  • 12% (64 votes) - I don't know
  • 6% (34 votes) - Other

It's unusual for a majority of voters in a poll to select one of the options. Also rare is for the other options to claim approximately the same number of votes. The result is that the "Yes" option received about about five times as many votes as any of the other options.

While this is not a scientific poll (my usual disclaimer), the voting suggests that developers are indeed pleased to have had Java 7 starting a year ago, rather than having had to wait for a more fully-featured Java 7 that was originally planned.

In Mark Reinhold's blog It's time for ... Plan B, written in September, 2010, he posited the choices as being:

  • Plan A: put out Java 7 as it was originally planned, with a mid-2012 release date;
  • Plan B: put out a Java 7 with reduced features in mid-2011, and a Java 8 with the remaining features in late 2012.

Mark had previouslyasked for feedback on the decision, saying that Oracle was "leaning heavily" toward Plan B. After receiving many responses, Mark said:

The vo

Frans Thamura, Java Champion and leader of JUG Indonesia, has announced on the Java User Groups JUG-Leaders email list that he is working on a national Java competition for students in Indonesia (the fourth most populous nation in the world). As the London Java Community's Martijn Verburg stated in reply, this is a fantastic idea!

In recent issues of Java Magazine I've been covering the Java Olympics that are taking place in Russia and nearby countries. That competition is for university students, with the winner gaining free attendance at the Moscow JavaOne next year.

If you've seen my articles about the Java Olympics in Java Magazine, you know how intense and exciting programming competitions can be. To have a new national competition in the fourth most populous nation in the world will be excellent! Who needs "American Idol" (a popular United States singing competition) or the Kentucky Derby, Preakness, and Belmont Stakes (the most major United States horse racing sequence) when you can actually watch software engineers compete in real time!?

I told Oracle's Alexander Belokrylov, who organized the Java Olympics, that I hope to be able to attend the second Java Olympics. Now I think I'm going to have to try to attend Indonesia's first competition as well! Hey, I may strive to become a globe-trotting Java competition reporter (if someone will pay me to do that, that is). These competitions are exciting, believe me (if you've never followed one).

Anyway, I wish Frans the best of luck in organizing Indonesia's new national Java competition! Weblogs

Since my last blog post, several people have posted new blogs:


Our current poll asks Was the decision to release Java 7 earlier by pushing some enhancements into Java 8 a good one?. Voting will be open until Friday, May 25.

Java News

Here are the stories we've recently featured in our Java news section:


Our latest Spotlight is the JCP Program Management Office's The JCP Program Targets Corporate Members of a Particular Kind:

The Java Community Process (JCP) Program Management Office (PMO) has relied on mature enterprises - such as Oracle, Nokia, IBM, Motorola, and Siemens - to form the backbone of the community. In recent years, to cultivate diversity the PMO has focused more on recruiting worldwide representatives from organizations and individuals in developer, academic, and user spheres. Now...

Subscriptions and Archives: You can subscribe to this blog using the Editor's Blog Feed. You can also subscribe to the Java Today RSS feedand the blogs feed. You can find historical archives of what has appeared the front page of in the home page archive.

-- Kevin Farnham
Twitter: @kevin_farnham most recently completed poll suggests that, while the new Java Magazine is starting to find a regular readership, there is still plenty of room for more growth.

A total of 266 votes were cast in the poll, along with a single comment. The exact question and results were:

Do you read Java Magazine?

  • 15% (39 votes) - I usually read most of the articles in each issue
  • 8% (21 votes) - I often read several articles per issue
  • 18% (47 votes) - I typically browse through the magazine, reading here and there
  • 5% (12 votes) - I subscribe, but haven't actually read anything yet
  • 5% (12 votes) - I don't subscribe to Java Magazine yet, but I plan to
  • 3% (9 votes) - I'm not interested in Java Magazine
  • 28% (74 votes) - What's Java Magazine?
  • 20% (52 votes) - Other

To be clear, this is not a scientific poll, merely a voluntary survey. Still, we can say that, among the people who chose to vote, about 40% are currently Java Magazine readers. Another 10% (those who subscribe but haven't read anything yet, and those who plan to subscribe) may become readers soon.

This leaves about half of the voters expressing that they are not Java Magazine readers. Only 3% saying they are not interested in Java Magazine, so almost half of the voters are not readers for another reason. 28% don't know what Java Magazine is. For these people, I recommend trying out Java Magazine, which is free!

It's interesting that the second most selected choice was "Other" (20%). One would assume that these voters are not current Java Magazine readers, but that they might be interested in reading Java Magazine (otherwise, wouldn't they have selected the "I'm not interested" option?). user grelf posted a comment that may provide a hint as to why so many people selected Other:

It is too hard to read. If I enlarge the text, navigation becomes a nightmare. It would be much better as a set of HTML pages.

I have seen complaints similar to this elsewhere...

Here's how your Java Magazine subscription currently works: when you get your email telling you a new issue of Java Magazine is available, it includes a link that you open in a web browser. But you don't have to view the issue in a browser. Once you're there, there is a button that lets you print the issue, and also a "Download" button that lets you save the issue as a PDF.

Printing the entire issue uses quite a lot of printer ink, since Java Magazine is a full-color production. I find downloading the PDF and viewing the magazine in my PDF viewer to be my most convenient method for enjoying the magazine.

Anyway, it would be interesting for the Java Magazine team, I'm sure, if they heard the format-related complaints people have. Please feel free to comment below about this, if you'd like, and I'll gladly relay the comments to Java Magazine [disclosure: I currently write news items for the Java Nation section of Java Magazine, and I'm planning to write full-scale technical articles in the future].

As for Java Magazine's actual content, I've not heard any complaints about that. It's high quality technology writing, in my opinion (again, note the above disclosure).

New poll: the decision to split Java 7 into Java 7 and Java 8

On 20 September 2010, Mark Reinhold announced: It's time for ... Plan B. This was the plan that would reduce what would be in Java 7, splitting out some of the previously planned features into a new Java 8. At the time, Mark noted: "The vo

A couple weeks ago I figured out (more or less) what's wrong with Java threads. It's not that there's anything so wrong with Java threads per se -- it's just that they were designed to meet a need that is different from what developers face today: a world full of multicore processors powering everything from PCs to tablets to phones.

Now I'm working on converting a Java threads app that I developed a while back to utilize Java 7's new Fork/Join Framework. As the example illustrates, you can actually implement Fork/Join concurrency in a relatively small number of lines.

The fundamental component in the ForkBlur example is theForkBlur class. Here's the key code that does the computation:

public class ForkBlur extends RecursiveAction { private int[] mSource; private int mStart; private int mLength; private int[] mDestination; private int mBlurWidth = 15; // Processing window size, should be odd. public ForkBlur(int[] src, int start, int length, int[] dst) { mSource = src; mStart = start; mLength = length; mDestination = dst; } // Average pixels from source, write results into destination. protected void computeDirectly() { int sidePixels = (mBlurWidth - 1) / 2; for (int index = mStart; index < mStart + mLength; index++) { // Calculate average. float rt = 0, gt = 0, bt = 0; for (int mi = -sidePixels; mi <= sidePixels; mi++) { int mindex = Math.min(Math.max(mi + index, 0), mSource.length - 1); int pixel = mSource[mindex]; rt += (float)((pixel & 0x00ff0000) >> 16) / mBlurWidth; gt += (float)((pixel & 0x0000ff00) >> 8) / mBlurWidth; bt += (float)((pixel & 0x000000ff) >> 0) / mBlurWidth; } // Re-assemble destination pixel. int dpixel = (0xff000000 ) | (((int)rt) << 16) | (((int)gt) << 8) | (((int)bt) << 0); mDestination[index] = dpixel; } } protected static int sThreshold = 10000; protected void compute() { if (mLength < sThreshold) { computeDirectly(); return; } int split = mLength / 2; invokeAll(new ForkBlur(mSource, mStart, split, mDestination), new ForkBlur(mSource, mStart + split, mLength - split, mDestination)); } 

RecursiveAction is an abstract class that extendsForkJoinTask. Looking at the documentation forForkJoinTask, you can see once again that standard Java threads are considered inadequate for the true parallel computational processing that modern multicore processors invite:

A ForkJoinTask is a thread-like entity that is much lighter weight than a normal thread. Huge numbers of tasks and subtasks may be hosted by a small number of actual threads in a ForkJoinPool...

In the code snippet, the computeDirectly() method is what performs the actual computations (in this case, a simplified method of blurring an image). You'll note that the input data is in the mSource array, the output is written to the mDestination array, and variablesmStart and mLength define the locations within the array where the processing will occur. So, ifmStart is set to 0 and mLength is set to the length of the array (i.e., the number of pixels in the image), you could call computeDirectly() and simply execute the blurring without parallel processing.

But, that's not what we want to do on our fancy N-core machine, right? We don't have time for that! Or, rather, our user doesn't... and we don't want them to switch to our competitor's app that takes full advantage of multicore processors, do we?

So, now let's look at the compute() method. This is indeed rather tiny:

  protected void compute() { if (mLength < sThreshold) { computeDirectly(); return; } int split = mLength / 2; invokeAll(new ForkBlur(mSource, mStart, split, mDestination), new ForkBlur(mSource, mStart + split, mLength - split, mDestination)); } 

This says: if the current amount of the array to be processed is less than a threshold, call computeDirectly(); otherwise, divide the length to be processed in half, and utilize Java 5's invokeAll to execute the listed collection of tasks.

And what are the tasks we're going to execute ifmLength was still larger than sThreshold? Two new ForkBlur() instantiations, one to process the first half of the array locations, the second to process the second half of the array locations. In other words, the work task is split into two tasks, each of half the size.

At this point you may be wondering: what about thissThreshold? How does that get selected? Do I just pull a value out of my hat? Call java.util.Random()?

This actually is one of my own primary questions regarding the Fork/Join Framework. If I have an N-core computer, I can divide a task into N equally-size pieces, launch N Java threads, and fully utilize my processor cores. So, if I'm utilizing the Fork/Join framework to do the same work, do I set a threshold value that accomplishes approximately the same thing? Or is that not the most efficient approach?

And, isn't it unreasonable to assume that a threshold value that optimizes performance on a particular device will also optimize performance on other devices that have different numbers of processing cores, different amounts of memory, etc. It doesn't seem like this threshold is going to be a "one-size-fits-all" proposition, to me...

This is definitely something I'll be researching as my experimentation continues. Weblogs

Since my last blog post, several people have posted new blogs:


Our current poll asks Do you read Java Magazine?. Voting will be open until Friday, May 11.

Java News

Here are the stories we've recently featured in our Java news section:

Brian Goetz recently provided new details on the status of JSR 335 in his OpenJDK document State of the Lambda: Libraries Edition. Project Lambda is a fundamentally important enhancement to Java 8. And, based on the response of developers in our recent poll asking how Lambda Expressions in Java 8 will affect their programming, the Java community is excited by the prospect of being able to implement closures in their applications.

A total of 437 votes were cast, along with a single comment. The exact question and results were:

To what extent do you expect Lambda Expressions (closures) in Java 8 to affect your programming?

  • 34% (148 votes) - They'll have a huge effect
  • 20% (88 votes) - They'll make some difference
  • 16% (68 votes) - No immediate effect (who knows when I'll finally be using Java 8?)
  • 9% (38 votes) - No effect, since closures aren't pertinent to the programming I do
  • 15% (64 votes) - I don't know
  • 7% (31 votes) - Other

These results (which, we recognize, are non-scientific) suggest that a great many Java developers consider the addition of Lambda Expressions to Java a very significant milestone.

Indeed, Java developers have been waiting for the inclusion of closures in Java for a very long time. Most of the long delay between Java 6 and Java 7 was filled with anticipation/hope that closures would be included in Java 7. However, as the years passed, and the uncertainty increased, the decision was ultimately made to split off some aspects of what was originally to be included in Java 7 into the next major release (i.e., Java 8), in order to facilitate getting key functionality out to the community sooner. Ithink most Java developers would agree this was a good decision (hmm.. this gives me an idea for a future poll!)...

But, getting back to this poll's results: a third of voters say Lambda Expressions will have a huge effect on their programming once Java 8 arrives; and more than half of the voters say closures will make at least some difference in their programming. We can assume that some of the 16% who selected "No immediate effect" will probably find Lambda Expressions useful once their platform reaches Java 8 (though that may be a long time from now).

rdohna wonders if there might be a bit too much enthusiasm for closures in Java, commenting:

They will be used even in cases where it only makes things more complicated than required.

Undoubtedly, that will happen in some cases. All the more reason to have experienced architects carefully communicating the design to the more junior developers...

In any case, it's been a long wait for closures / Lambda Expressions in Java. The wait isn't over yet, but it will be over soon; and developers are eagerly anticipating their arrival.

Current poll: Java Magazine

Our current poll asks Do you read Java Magazine?. Voting will be open until Friday, May 11. Weblogs

Since my last blog post, Rex Young posted a new blog:

Java News

Here are the stories we've recently featured in our Java news section:

Filter Blog

By date: