Skip to main content

JavaOne Call for Papers Ends Monday; Please Don't Wait Until the Last Moment!

Posted by editor on April 6, 2012 at 11:16 PM PDT

It seems not that long ago that the JavaOne 2012 Call for Papers began. Yet, here we are, in the CfP's final weekend! All proposals for JavaOne 2012 sessions must be submitted by 11:59 PM Pacific Daylight Time (US) on Monday. Now, I'm not going to try to compute the equivalent local time for everyone around the world. In my experience, you don't try to submit something like this at the very last minute. What if your internet connection goes down, or a glitch occurs somewhere else? Getting your submission in well before early morning GMT on Tuesday is my advice.

Now, if only I can follow my own advice!

I'm proposing my first ever JavaOne session. We'll see what happens. My proposed session is related to the emergence of multicore desktop computers, tablets/pads, and mobile phones. I plan to go over the history of increases in processing speed, which reached a kind of limit some years ago. Once rapid increases in processing speed in a single processor core were no longer attainable, chip manufacturers started making multicore chips. So, the total processing power per chip continued to increase. But now, instead of the power increasing due to increased processing speed in a single core, the increased power came from multiple cores residing on a single chip.

This, of course, has major implications for applications. If your app is not multithreaded, it will use only one of the processor's cores. So, if someone has a quad-core device, your app will be using only one of those cores if it's not multithreaded. That's fine in some cases, for example for apps that have lots of interaction with the user. It's not fine if your app is computationally intensive. If your competitor develops an app that uses all available processors, their app will have blazing speed compared to yours. Not cool...

So, my proposed session will talk about this history, then get into the problems of multithreaded programming, from a generic, language-neutral viewpoint (remember, I was developing multithreaded apps in C and Fortran on SunOS systems in 1993). Problems like memory overwrites, deadlocks, threads that never complete... the world goes crazy once you get into parallel programming. So, what is "threadsafe" code anyway?

Next, my plan is to talk about the history of parallel processing in the JVM through today. Java has had threads for a very long time. It doesn't seem to me that many developers have actually used them. What was the need? For high-end data center processing, Java EE met the need. In the old single core processor world, what's the difference between a multiprocessor computer (like the 8-processor Sun machines I worked on in the mid 1990s) and a server farm?

But here's the problem: today, many people can pick up and hold in their hand what in the past was a mini data center, a mini server farm -- because, in their hand they can hold 2 or 4 or even 8 processor cores. Now, we're not going to use Java EE to make that fancy, powerful phone or tablet fully utilize all of its processing cores, are we? Well.. my friend Adam Bien might argue "why not?" since Java EE 6 provides such lightweight components.

He's right, Java EE could do the trick. But, the software that we want to utilize all the cores wasn't originally developed using Java EE. A great many of us are not inventing new apps; rather, we're trying to port existing apps into this new multicore world. Surely, we can't take the time to rewrite all that code such that it will efficiently run in a hand-held data center, can we? Does any company have a budget for that? Hence, the need for a path to convert desktop apps designed for operation on single-core processors into apps that can efficiently utilize the multicore processors that reside inside modern desktop computers, tablets, and mobile phones.

So, what about Java threads? I recently did some basic experimentation and found that, in a purely mathematical computational scenario, basic Java threads do a pretty good job of fully utilizing my CentOS Linux quad-core processor. But, basic Java threads don't work well in all scenarios. Hence, the decision to introduce the Fork/Join Framework in Java 7.

Converting existing apps developed for the single-core world is still an enormous amount of work, whether you convert the apps to use Java threads, the Fork/Join Framework, or even Java EE 6. This is what's behind the incredibly ambitious Project Lambda, which will introduce closures in Java 8. The parallelization will be implemented in the underlying Java libraries themselves, removing the need for desktop developers to deal with the damnable headaches associated with parallel programming (those memory overwrites, deadlocks, infinitely wandering threads, etc., that I mentioned above). The desktop app developer will simply have to invoke the underlying parallelism where doing so will increase performance. The complexities of thread management, etc., will all take place "under the hood."

If you can't wait for Java 8, and you're developing a new desktop app (whether your "desktop" is a PC, tablet, or fancy phone), there are multiple non-Java parallel programming options for the JVM that are available right now, in languages like Clojure and Scala.

I'll talk about all of this at JavaOne 2012, if my proposed session is accepted.

So, what do you think? Is this a session you might want to attend if you were at JavaOne 2012? Any suggestions on additional items I should include in my proposal? I have until Monday night to finalize it... Weblogs

Since my last blog post, Rex Young posted two new blogs:


Our current poll asks How often do you attend Java conferences?. Voting will be open until Friday, April 20.

Java News

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


Our latest Spotlight is Jonathan Giles's Interview with Jim Weaver and Stephen Chin:

Hi all. I

JavaOne2012.png9.6 KB
Related Topics >>