JAX London and Big Data Con are just a few weeks away and naturally, we're very excited about what's in store for the events. It seemed like the perfect time to catch up with those keynoting at the event itself in what we're calling the "Road to JAX" series, which will cover some important topics for the worlds of Java and Big Data.

Next up is the delightful duo of the Diabolical Developer and LJC co-leader, Martijn Verburg and Java Champion and performance tuning guru Kirk Pepperdine. The two will be speaking just before JAX London Community Night with their keynote 'Java and the machine'. We caught up for 30 minutes to talk all things Java (cloud, modularity and mobile mostly), JClarity (the Java performance company they've just launched with Ben Evans) and some important community stuff. Enjoy!

------

JAX: Obviously, you're both keynoting at JAX London with 'Java and the Machine'. Without giving too much away what is it about?

MV: Basically, the physical environment that Java developers, and that Java itself is running on, has actually now changed in the last couple of years and is continuing to change. We see two major changes. One is the fact that CPUs have gone multi-core, which means the program runs very differently under that piece of hardware. Also, the fact that a lot of people are moving toward virtualised operating systems, which means a lot of people are no longer running on what we call 'bare metal'. This is a new paradigm that Java developers have to get used to and take advantage of, as well as Java the language and platform itself. We're going through this quite interesting period of change.

KP: You've put a positive spin on it, I'll put a negative one on it. Hardware is changing and a lot of that change is for the better. It is making lives more difficult for developers because they have to think about things they didn't have to think about before. However the platform running on, in terms of the virtualisation, is actually - well you know, the better they make the hardware, the more things we can think of to consume it. A lot of performance challenges when you move to a virtualised environment. In other words, it's not a straight bare metal to virtualised environment switch and everything's going to work the same. It doesn't work that way. I like to tell people that there's plenty of good reasons to move to virtualised environments - performance isn't one of them.

MV: Absolutely not.

KP: There's many cases of moving to virtualised environments is going to cut people off from some of the advances made in hardware, and make it more difficult to get at things and make their deployments prone to different types of failure. So it's not completely a panacea - although there are some obviously advantages to virtualised environments. There's a lot of people to be solved there.

JAX: Do you think developers don't embrace multicore now, will they get left behind?

MV:They will be left behind, absolutely. Dead in the water. It's adapt and survive and don't adapt and die. It's Darwinism at its best.

JAX: Simple as that?

KP: It's worse than that - they've already been left behind. We've been telling them from 2005 to start adapting. In seven years, if they haven't started adapting, you wonder what they're going to do with the new changes in hardware and the new resources available. How are they going to even consider taking advantage of those resources?

I'm not saying it's an easy slog to adapt to multicore environments. There's a lot of interesting intricate problems that require a lot of thought in order to work your way through them. Our simple pessimistic lock-on type models we've been using in the past - they simply won't scale. We actually have to be more creative.

Fortunately in Java, we have an advantage in that we have these very clever library writers helping us. A lot of developers can accidentally move to multicore.

JAX: Do you think a change of mindset is needed - is it as simple as that or is there more to it?

MV: It's not just a change of mindset but a willingness to knuckle down and practice. There's the old adage that you won't become a world expert unless you do something for 10,000 hours and we're not saying they have to go to those extremes.

KP: Sure they do!

MV: (laughs) Kirk would argue otherwise. If a number of developers have the discipline to sit down and learn even the existing libraries, which have been there since the mid 2000s, [then] it's very much a case of knuckle down and learn the stuff or be left behind.

JAX: Do you feel like Oracle are doing enough to embrace this issue?

KP: Absolutely.

MV: I have to agree. They're putting in an awful lot of effort. If you look at the work being done on Java 8. Lambdas isn't simply about reducing a nice bit of boilerplate source code for developers and not even necessarily all that much about adding the functional programming aspect to Java. What it's real power is is enabling parallelism inside a lot of the default collections, libraries, other APIs inside Java itself. All of sudden for completely free, developers are going to have collections which work really nicely on multicore machines. That takes a massive amount of engineering effort on behalf of Oracle.

KP: It even goes historically before that. When people were predicting that we're going to have trouble with what to do all these transistors, Oracle looked at this and said "Crap, our database speed is coupled to clock rates." If there's no more free ride in getting high transactions based on clock speed improving, what are we going to do, right?

They started a long time ago, even pre-2000, looking at what investments needed to be made in order to continue their dominance in the database space. I think that they've been thinking about this for a long time. Sun had been thinking about this for a long time. If you look at the post-Sun era moving into Oracle, they're continuing to think about it. It's been going on for a long time and will continue to go on. If you get a brand new piece of hardware, you come with 800, albeit limited cores on your machines that aren't utilised. Oracle's already started a project saying "How can Java take advantages of those 800 cores sitting there basically drawing triangles."

JAX: Do you think this is the biggest challenge Java faces - is this the one?

MV: In terms of Java on the server, I think it is one of the biggest ones. In terms of keeping Java the language and platform at the forefront, I guess, [at the height of] consumer awareness, Java needs to have a stronger story in mobile.

At the moment, you've got Android, kind of Java-based but we all know the conflicts over that. That's probably the only piece puzzle missing. Modularity would have helped there, so Jigsaw. It's a real shame it got delayed, I do think it was the right call to delay because it simply wasn't baked in well enough. It's certainly one of the biggest challenges Java faces but I actually think this side of it is going reasonably compared to the others.

KP: I think we're far ahead on that front and there's no doubt that something very disruptive could come along change the picture very quickly. I haven't seen what that is yet and certainly, that's not where the problems are. The biggest problems are the apparent lack of presence on mobile devices.

JAX: Is that the key hindrance for you then?

KP: I wouldn't say it's a hindrance. When I look at the future of computing, I don't see laptops or desktops there, per say, but I see server rooms and people running around with mobile devices, or even something more mobile than a mobile device. In those cases, you have to say that when it comes to the big iron as Marty has pointed out, Java is a clear obvious choice there.

But when you move into the mobile space, I would even be as bold to say, I'm not sure the VM technology as it is implemented today, as it works against the hardware today, is actually a good solution for mobile devices. I think that's going to be a struggle - how do we change the technology so that it does fit in that particular space? I think Jigsaw would have helped, but it's a very small piece of the puzzle. You have to look at how the VM works and that's what I think Google did when they looked at Dalvik and they said how can we make this better for a mobile platform. They come up with their solution - is it the best one? I don't know, it's certainly better than the alternatives at the moment.