New versions of Java are coming out every 6 months now. What has changed, should we upgrade, and if so, how?

(Updated 3 Dec, 2020)

Video and resources for the Update on IntelliJ IDEA talk from FOSDEM 2020.

Abstract

With releases of Java coming thick and fast every six months, it’s a full time job staying on top of the features. If your IDE can help you here, it’s one less thing to worry about. IntelliJ IDEA Community has three releases every year, each one improves the support for modern versions of Java, but that’s not the only thing on offer.

Join this session to see what’s new in IntelliJ IDEA Community (the free one!). This is not limited to just supporting new language features, which some of us might not get to use for ages, but better support for things developers do every day, and improved performance and stability, because an all-singing, all-dancing IDE is all well and good, but if it’s not usable those features mean nothing.

We should invest more time in the skill of reading code.

It’s exhausting staying up to date with the evolution of Java and the myriad other JVM languages. Is it worth it? What do modern languages give us?

How is Java 9 going to change the way developers work?

Looking ahead to what functionality is available in Java 9, and IntelliJ IDEA’s support (current and future) for it.

Content and resources for the Code Review Matters and Manners talk, including links to additional information and supporting material.

• Understand how to improve performance with your Java code using Java 8 language features.
• Learn hands on techniques to discover and implement common Java 8 refactorings.
• Understand when you should and should not apply key refactorings in Java 8.

Last night was the final get-together to discuss the Java 8 MOOC. Any event hosted in August in a city that is regularly over 40°C is going to face challenges, so it was great that we had attendees from earlier sessions plus new people too.

As I mentioned last week, the Sevilla Java User Group is working towards completing the Java 8 MOOC on lambdas and streams. We’re running three sessions to share knowledge between people who are doing the course.

The Sevilla Java User Group is working together towards completing the Java 8 MOOC on lambdas and streams. As part of this, we’re running three sessions during the course so we can, as a group, ask questions about the lectures, get help with the homework, and (if we’re feeling very smart!) help people who may be struggling (or might not have watched the videos).

I was asked three simple questions about my thoughts on Java turning 20, and ended up writing a guest post for Voxxed. No wonder I can’t seem to find the time to write these days.

Resources for my “Is Groovy Better Than Java for Testing?” talk.

I think living in a beautiful city in a fantastic climate has its advantages. Not just the obvious ones, but we find people unusually keen to come and visit us on the pretence of presenting at the Sevilla Java User Group (and please, DO come and present at our JUG, we love visitors).

This week we were really lucky, we had Georges Saab and Aurelio Garcia-Ribeyro giving us an update on where Java is now and where it looks like it’s going in the future.

Setup required for the AngularJS/HTML5/Groovy/Java/MongoDB tutorial for QCon London 2015. Sign up with code SPEAKGEE100 for £100 off the price!

This year I’ve been giving an evolving live demonstration of coding a Fully Buzz Word Compliant, mobile-friendly web application. The aim of the demo is to show, via a real-world application rather than snippets or a toy example, where these popular technologies sit in your architecture, and how they interact with each other.

We’ve been missing an introduction to using MongoDB from Java for a little while now - there’s plenty of information in the documentation, but we were lacking a step-by-step guide to getting started as a Java developer.

I sought to rectify this with a couple of blog posts for the MongoDB official blog: the first, an introduction to using MongoDB from Java, including a non-comprehensive list of some of the libraries you can use; the second, an introductory guide to simple CRUD operations using the Java driver:

Last night at the Sevilla JUG we officially celebrated the launch of Java 8 - yay!

Don’t be fooled by the picture, people had more fun than it looks. Honest.

For anyone who missed the session, or who was there and wants access to the materials, here they are:

Last Saturday Mr Stephen Chin came to Sevilla on his crazy European tour to show us Lego and Robots. This was our largest turnout yet for a Java User Group event in Sevilla, which surprised me as it was on a weekend, and the weekend before the spectacle that is Semana Santa in Sevilla.

Web development has changed a lot. I was aware that there have been many changes in the last few years, and I’ve seen maturity come to web platforms in the form of standardisation and common reusable libraries and frameworks - and I don’t mean reusable in the way we used to “reuse” stuff by nicking it off other people’s websites when we saw something cool. I used to be a web developer.

I wrote an article for the latest edition of Java Magazine which is an introduction to MongoDB for Java developers, and a nod to why it’s good in the “Big Data” space. Look inside >MongoDB and Big Data

In the last two articles on Spock I’ve covered mocking and stubbing. And I was pretty sold on Spock just based on that. But for a database driver, there’s a killer feature: Data Driven Testing.

Information related to the currently-ongoing effort to redesign the Java driver for MongoDB.

The second in my short series of blogs about the new Java driver is now available for your perusal. In it, there’s some guidance on how to get started using the new driver, whether you want to use the new (unfinished) API, the existing “classic” API, or a blend of both.

I feel slightly like a traitor to my own blog, as I’ve written a blog post for Somewhere Else. I’ve written about the design goals for the 3.0 MongoDB Java Driver in the official MongoDB blog (seems sensible, right?). I’m not sure how I feel about cross-posting the entire contents, so I’m just linking you to them instead. Anyone who’s been to my Backwards Compatibility presentation this year might notice something familiar about the content.

In the last post I talked about our need for some improved testing tools, our choice of Spock as something to spike, and how mocking looks in Spock.

As that blog got rather long, I saved the next installment for a separate post.

We’re constantly fighting a battle when developing the new MongoDB Java driver between using tools that will do heavy lifting for us and minimising the dependencies a user has to download in order to use our driver. Ideally, we want the number of dependencies to be zero.

So, like one of my presentations, I have a question for you. Actually, I have more than one question for you. I’m not going to bother with survey monkey or whatever, I want to share the answers so please, answers in the comments: Are you using the Java driver for MongoDB in your application?Are you using the Java driver directly, or are you using a third party library like Morphia, Spring Data, the Scala driver, your own abstraction layer, etc?

Don’t you hate it when you ask a perfectly good question, and someone comes back with the answer “it depends”?

It’s so frustrating to think that in a world of ones and zeros, people can’t give absolute answers and you can’t rely on “best practice”.

On the same day Stephen Chin came to see me at the 10gen offices, we also ran a NightHacking session in the evening with the London Java Community. Not many people turned up (maybe I need to work on my signage to the office?) but it was a great session. In fact, having less people meant we could all be involved.

On Monday, Stephen Chin from Oracle visited me at the 10gen offices as part of his NightHacking tour. In the video we talk about my sessions at JavaOne and the Agile presentation I’m giving at Devoxx, and I do some very basic hacking using the MongoDB Java driver, attempting to showcase gradle at the same time. It was a fun experience, even if it’s scary being live-streamed and recorded!

This month’s Java Magazine features an article by yours truly, which is yet another intro to the Disruptor. It’s basically a summary of the stuff I’ve written in this blog, updated for version 2.7 - so the names of the classes should be up to date and the responsibilities follow the simplified pattern we use now. If you were looking for an more recent version of my introduction blog posts, this article gives a reasonable overview.

Saturday was, hopefully, my last conference of the year. My lucky readers should start to see some posts which are not simply me gushing about another opportunity to hang out with awesome people and learn about interesting “stuff”.

A couple of weeks ago, I was at JAX London along with a number of the London Java Community regulars (Martijn/Ben/John/Sandro/Simon/Zoe I’m looking at you….)

My purpose for attending was largely to present the Hardcore Concurrency for Beginners talk that Mike and I debuted at an LJC event a few weeks back. Almost as important was catching up with the aforementioned LJCers and meeting with as many people as would talk to me. After the disappointment of the sessions at Java One, sitting in a room being talked at was quite low down on my list of priorities. Sometimes it’s nice to be wrong.

Last Tuesday Mike and I unveiled our brand shiny new presentation: Understanding the Disruptor, a Beginner’s Guide to Hardcore Concurrency. This was a preview of the talk we’ll be doing at JAX London on the 2nd November. A video of the session is available, as are the slides. I promise not to say “so” anywhere near as many times when I repeat my performance at JAX (is there anything more painful than watching yourself on video?

Here’s a photo of me representing LMAX as I pick up the Duke Award we won for the Disruptor (Thanks to Martijn for taking the photo)

So I’ve been at JavaOne for the better part of three days, it’s time to record some of my observations so far:

We are hiring! If you think we’re doing something interesting, or if you think you can help us do our thing even better, come join us. Your boss will be the dude who wrote Continuous Delivery, you’ll get a chance to experience what Danny calls meta-Agile (or Agile Agile), and you’ll really start to care about Domain-Driven Design. Ideally we’re after Java people, but at the heart of it we want people who are dead passionate about development.

Martin recently announced version 2.0 of the Disruptor - basically there have been so many changes since we first open-sourced it that it’s time to mark that officially. His post goes over all the changes, the aim of this article is to attempt to translate my previous blog posts into new-world-speak, since it’s going to take a long time to re-write each of them all over again. Now I see the disadvantage of hand-drawing everything.

My recent slow-down in posting is because I’ve been trying to write a post explaining memory barriers and their applicability in the Disruptor. The problem is, no matter how much I read and no matter how many times I ask the ever-patient Martin and Mike questions trying to clarify some point, I just don’t intuitively grasp the subject. I guess I don’t have the deep background knowledge required to fully understand.

So, rather than make an idiot of myself trying to explain something I don’t really get, I’m going to try and cover, at an abstract / massive-simplification level, what I do understand in the area. Martin has written a post going into memory barriers in some detail, so hopefully I can get away with skimming the subject.

We mention the phrase Mechanical Sympathy quite a lot, in fact it’s even Martin’s blog title. It’s about understanding how the underlying hardware operates and programming in a way that works with that, not against it.

We get a number of comments and questions about the mysterious cache line padding in the RingBuffer, and I referred to it in the last post. Since this lends itself to pretty pictures, it’s the next thing I thought I would tackle.

Martin Fowler has written a really good article describing not only the Disruptor, but also how it fits into the architecture at LMAX. This gives some of the context that has been missing so far, but the most frequently asked question is still “What is the Disruptor?”.

I’m working up to answering that. I’m currently on question number two: “Why is it so fast?”.

So now I’ve covered the ring buffer itself, reading from it and writing to it.

Logically the next thing to do is to wire everything up together.

I talked about multiple producers - they have the producer barrier to keep them in order and under control. I’ve talked about consumers in a simple situation. Multiple consumers can get a little more involved. We’ve done some clever stuff to allow the consumers to be dependent on each other and the ring buffer. Like a lot of applications, we have a pipeline of things that need to happen before we can actually get on with the business logic - for example, we need to make sure the messages have been journalled to disk before we can do anything.

The Disruptor paper and the performance tests cover some basic configurations that you might want. I’m going to go over the most interesting one, mostly because I needed the practice with the graphics tablet.

This is the missing piece in the end-to-end view of the Disruptor. Brace yourselves, it’s quite long. But I decided to keep it in a single blog so you could have the context in one place.

The important areas are: not wrapping the ring; informing the consumers; batching for producers; and how multiple producers work.

The next in the series of understanding the Disruptor pattern developed at LMAX.

After the last post we all understand ring buffers and how awesome they are. Unfortunately for you, I have not said anything about how to actually populate them or read from them when you’re using the Disruptor.

Recently we open sourced the LMAX Disruptor, the key to what makes our exchange so fast. Why did we open source it? Well, we’ve realised that conventional wisdom around high performance programming is… a bit wrong. We’ve come up with a better, faster way to share data between threads, and it would be selfish not to share it with the world. Plus it makes us look dead clever.

On the site you can download a technical article explaining what the Disruptor is and why it’s so clever and fast. I even get a writing credit on it, which is gratifying when all I really did is insert commas and re-phrase sentences I didn’t understand.

However, I find the whole thing a bit much to digest all at once, so I’m going to explain it in smaller pieces, as suits my NADD audience.

First up - the ring buffer. Initially I was under the impression the Disruptor was just the ring buffer. But I’ve come to realise that while this data structure is at the heart of the pattern, the clever bit about the Disruptor is controlling access to it.

I have been struggling with .NET. Actually, I have been fighting pitched battles with it.

All I want to do is take our existing Java client example code and write an equivalent in C#. Easy, right?

Trisha’s Guide to Converting Java to C#

Turns out writing the actual C# is relatively straightforward. Putting to one side the question of writing optimal code (these are very basic samples after all), to get the examples to compile and run was a simple process:

As an associate member of the London Java Community (LJC), I’m very pleased with the news that we won an Open seat on the Java SE/EE executive committee. The results show that we got an astonishing 47.5% of the vote - if an MP got voted in with that percentage the newspapers would probably be using the word “landslide”. It’s quite exciting to be one of the two user groups involved.

At LMAX we adopted Google Web Toolkit pretty early on. One of the motivations for using it was so we only had to worry about recruiting Java guys, and then we could all work on every part of the application including the web UI. Sure, you can learn a bunch of different skills if you want to, but it reduced context-switching and kept the skill set we were hiring for to a nice short list.