Skip navigation

Lambda Expressions (JSR 335) are perhaps the most significant innovation in Java 8. Many consider Lambdas (or 'closures') a game-changing technology for the Java language. Our most recently completed poll asked the community for its take on the significance of Lambda Expressions as they pertain to company decisions on how quickly to migrate to and adopt Java 8.

A total of 490 votes were cast in the poll. The exact question and results were:

How quickly will Java software vendors migrate to Java 8, given the presence of Lambda Expressions?

  • 16% (76 votes) - ASAP; some companies will even jump past Java 6 and/or Java 7 to get to Java 8
  • 6% (29 votes) - Very quickly, since Lambdas provide enormous competitive advantages
  • 13% (66 votes) - They'll migrate sooner than normal
  • 44% (217 votes) - It will probably be a typical Java version migration scenario
  • 17% (84 votes) - Not many companies can benefit from Lambdas, so the migration will be slower than normal
  • 4% (18 votes) - Other

Grouping the first three options, we see that 35% of the voters believe companies will migrate to Java 8 sooner than is typical after a major release; meanwhile, 44% predict a typical migration scenario; while 17% predict slower than normal adoption because few companies can benefit from Lambda Expressions.

Among the voters who expect sooner than normal migration, the overall expectation is that migration will be much quicker than is typical; indeed, almost 2/3 of those who expect sooner than normal adoption expect it to happen either 'ASAP' or 'very quickly.'

Another way of looking at these (not scientific) results is to note that fully 79% of the voters think Java 8 will be adopted as soon as, or sooner than, has been the case with typical Java major releases in the past. If this actually happens, we'll certainly have to consider Java 8 to be a very successful release!

New poll:

Our current poll asks Does your company utilize Continuous Integration (CI) in its software development projects?. Voting will be open until Friday, August 9.

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.

-- Kevin Farnham (@kevin_farnham) 2013 (Open Source CONvention) is underway in Portland, Oregon. Even if you can't be there, you can still participate by watching the keynote sessions, which will be live-streamedon Wednesday, Thursday, and Friday. While all the keynotes are likely to be quite good (I found them to be so when I was at OSCON some years ago), several keynotes in particular stand out for me (all times are US Pacific time):

The subtitle of the "Turing's Curse" keynote is: "Looking back on 30 years of programming: there's nothing new since 1983. Examples and implications." Curious, right? But I have to admit, this type of thought is something I've sometimes vaguely felt myself... I wonder what John Graham-Cumming's take on it will be.

While there's no separate "OSCON Java" mini-conference this year, there is a pretty complete Java and JVM track, which includes 14 sessions covering Java EE 7, non-Java JVM languages, Spring, functional programming, Behavior Driven Design (BDD), performance, WebSocket and Server-Sent Events, ... You get the idea, there are plenty of interesting sessions for Java/JVM developers to attend.

Then there are the Birds of a Feather (BOFs) sessions, which include additional topics of interest to the Java community.

I'd have enjoyed attending OSCON in person this year (I had the opportunity, but software project deadlines/crises intervened). Still, I'm glad to have the opportunity to watch the keynotes. And perhaps some attendees will post interesting blogs about some of the sessions, that we can feature on the home page!

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.

-- Kevin Farnham (@kevin_farnham)

The results of the last-completed poll suggest that the developer community is not yet entirely convinced that 'the Cloud' is as revolutionary a development as some think. Still, a plurality of voters considered the Cloud to be significant.

A total of 177 votes were cast in the poll, which ran for two weeks. The exact question and results were:

Does 'the Cloud' change anything?

  • 20% (36 votes) - It changes everything: ultimately, it will eliminate most corporate data centers
  • 25% (45 votes) - It's a pretty significant development
  • 18% (32 votes) - It's too early to tell
  • 18% (31 votes) - It's not as important a development as many people think
  • 15% (27 votes) - No, it's just buzz
  • 3% (6 votes) - Other

Grouping the first two options, and also options 4 and 5, yields 45% of the voters considering the Cloud to be significant or world-changing, 33% considering the Cloud to be not that important or just buzz, with 18% believing it's too early to tell.

This, I think, attests to the fact that the Cloud has not to this date had much of a direct effect on most developers. Not that many are working on Cloud applications. Java EE 7 moves toward Cloud support, but the strategy there is also to wait until Cloud platforms are more stable and better defined.

I think also there's a bit of a misconception on what constitutes the Cloud; or, perhaps, there's a multiplicity of definitions. For example, is Google Docs a cloud application? I'd say yes, myself. Rather than coping with 18 different versions of office software on desktops/laptops/tablets running 7 different operating systems (and coping with all the "this doesn't render correctly on my system" issues), all the users connect to Google Docs, and create, share, and edit documents generated and stored on a single hardware/software/application architecture.

Looked at from the point of view of this simple case, I'd say the Cloud is already changing the way at least some of us work.

New poll: Migration to Java 8

Our new poll asks How quickly will Java software vendors migrate to Java 8, given the presence of Lambda Expressions?. Voting will be open until Friday, July 26.

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.

-- Kevin Farnham (@kevin_farnham)

This past week one of our aging quad-core PCs (running Debian 6) ceased sending out video signals. Since the computer is fairly old, and since at any given moment several of our computers are idle, I decided to shuffle the computers that have working video, and possibly use the old quad as a headless machine.

The computer that partially failed was for both work and fun -- online video games were part of the fun. In recent months, we'd noticed that games with active graphics seemed not to work as well. Without really investigating, I attributed this to either changes in the Flash player, or changes in the game software.

Anyway, that machine could no longer be used for anything that required a monitor, so I switched its boot disk with the one in our other quad-core and booted it up. That was also running Ubuntu 6, and though the hardware was somewhat different, the machine booted and put the correct images up on the monitor.

So, let the gaming begin, right? Well -- the performance was terrible, much worse than on the old quad-core. The game was almost unplayable. Yes, it could have been drivers, etc. But this was already taking too much time -- the game had to be played!

So, as an experiment, we tried the game on our fairly new, but quite low end, Windows machine. No quad-core, just a basic HP desktop running Windows 7. Lo and behold, the game worked great, better than it had in a very long time!

How could this be? The game runs best on the lowest-end computer? Could it be, perhaps, that the game somehow tuned for Windows? That was possible, but surely not certain...

It was a sufficiently interesting problem that I started investigating the processors on the three machines. Here's what I found (note: I write this while on travel, so the numbers aren't exact):

  • Quad-Core 1 (the one with the now-broken video capability) has 4 cores with a processing speed in the 2.3 GHz range;
  • Quad-Core 2 (the replacement where the game performed terribly) has 4 cores operating at a significantly lower range;
  • the Windows 7 machine identified itself as having a single processor running at a speed of about 3.1 GHz

There's the answer, right? Or, at least part of it. The game using a single processor, so it will perform best on the machine that has the fastest processor.

So, what's this have to do with Lambda Expressions? Everything. Consider this same game, written in JavaFX, utilizing Java 8 Lambda threads for its computational routines. Assuming equal graphics speed, and no limitations on how many processors the game has access to, which computer will the multithread version of the game perform best on? Surely the quad-core with the highest processor speed (i.e., the most powerful computer in the house) -- which is as it should be (more powerful computer equals better performance).

Software developers were "saved" for decades by ever-increasing processor speeds, which made developing ever-more-complex software using the same old single-thread techniques not a problem. But once the limits to how thin silicon could be sliced began to be approached, the procession of doubling of processor speeds every few years was no longer possible.

Enter the multicore processor: the processor's overall power and processing capacity continues to increase, but the processing is divided among multiple processing cores.

But that's a problem for developers: the same old single-thread development practices don't take advantage of the multiple cores. And, those of us who have spent years working on multithreaded / parallelized software know how difficult it is to manage threads, make computation functions thread-safe, etc. Then there's the problem of debugging threading issues!

But it's a multicore world now. How in the world are we going to retrain millions of software engineers about how to write thread-safe software?

This is the brilliance of Lambda Expressions: they make that retraining unnecessary, by providing Java developers with a set of syntactical tools that indicate to the compiler that thisset of code should run in parallel. Then, the JVM itself takes care of the parallelization.

Can't get much better than that, can you?

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.

-- Kevin Farnham (@kevin_farnham)

Filter Blog

By date: