Java

Applying Java 8 Idioms to Existing Code

  • 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.

Java 8 MOOC - Session 3 Summary

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.

Java at 20

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.

The State of Java

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.

Getting Started with MongoDB and Java

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:

Sevilla Java User Group Java 8 Launch Party

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

Partay

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:

In my day...

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.

Introduction to MongoDB and Big Data

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

Spock: Data Driven Testing

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. All developers have a tendency to think of and test the happy path. Not least of all because that’s usually the path in the User Story - “As a customer I want to withdraw money and have the correct amount in my hand”.

How to get started with the new MongoDB Java Driver

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. The post also shows that Gradle is prettier than Maven.  Sorry Maven. If you are going to play with the new driver, please read all the caveats carefully.

The 3.0 Java Driver - Design Goals

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.

Spock passes the next test - Painless Stubbing

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. Today I want to look at stubbing. Stubbing Mocking is great for checking outputs - in the example in the last post, we’re checking that the process of encoding an array calls the right things on the way out, if you like - that the right stuff gets poked onto the bsonWriter.

Spock is awesome! Seriously Simplified Mocking

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. This is not going to be the case when it comes to testing, however.  At the very least, we’re going to use JUnit or TestNG (we used testng in the previous version, we’ve switched to JUnit for 3.0).

How are you using MongoDB with Java?

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?If you’re using a third party library, why did you choose that over using the Java driver directly?If you’re using the Java driver directly, what do you like about it? If you’re using the Java driver directly, are there any areas that give you pain?

It Depends

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”. It’s an answer I’ve given so many times, especially when someone asks about performance.  Well, I’ve had my comeuppance.  The entire exercise of designing the new Java driver for MongoDB has been nothing but a series of questions where the answer is “it depends”: Which Java version are our users, um, using?Do people want an asynchronous driver?How will they want to work with async?Will they want to use async and synchronous method calls from the same application?Do people typically use the Java driver directly, or do they use something that wraps it, like Morphia or Spring Data?What’s most important for users in terms of performance?

Java 8 - Introduction to Lambdas Article

This month’s Java Magazine features an article by me, Ben Evans and Martijn Verburg about the new lambdas coming in Java 8. The aim of the article is to give an overview to normal, human Java developers, who don’t need to know the theory behind what they are or how they work under the covers, but want to know how to use them when they get the shiny new version of Java next year (or even get ahead of the curve and try them now).

NightHacking Tour: The LJC

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. Expect Raspberry Pis and JavaFX.

Interview and Hacking session with Stephen Chin

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!

Java Magazine: Intro to the Disruptor Part One

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.

London Java Community Open Conference

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”. Who wants to propose a session?In many ways the London Java Community Open Conference was my favourite one so far, and not just because it’s near home and I helped to organise it.

JAX London - I learn stuff and meet people

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.

Mike and I debut our new Disruptor presentation

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?).

JavaOne: Initial Observations

So I’ve been at JavaOne for the better part of three days, it’s time to record some of my observations so far: The wireless access is rubbish.<Gross generalisation> technical people are not natural public speakers.  Makes me feel better about the presentations I’m going to be giving (see A Beginner’s Guide to Hardcore Concurrency).The sessions are less useful than getting out and chatting.  I’ve had a really excellent time, I’ve met: people from other Java User Groups; the Duchess girls; other Duke Award winners; the Azul guys; guys (well, girls) from O’Reilly books; JCP members and many random and awesome people.Everyone thinks that Large is an acceptable default t-shirt size (it’s not).

Are you an awesome developer?

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.

Disruptor 2.0 - All Change Please

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.

Dissecting the Disruptor: Demystifying Memory Barriers

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.

Dissecting the Disruptor: Why it's so fast (part two) - Magic cache line padding

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.

Dissecting the Disruptor: Why it's so fast (part one) - Locks Are Bad

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?”. These questions do go hand in hand, however, because I can’t talk about why it’s fast without saying what it does, and I can’t talk about what it is without saying why it is that way.

Dissecting the Disruptor: Wiring up the dependencies

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.

Dissecting the Disruptor: Writing to the ring buffer

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. ProducerBarriers The Disruptor code has interfaces and helper classes for the Consumers, but there's no interface for your producer, the thing that writes to the ring buffer.

Dissecting the Disruptor: How do I read from the ring buffer?

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. ConsumerBarriers and Consumers I’m going to approach this slightly backwards, because it’s probably easier to understand in the long run.  Assuming that some magic has populated it: how do you read something from the ring buffer?

Dissecting the Disruptor: What's so special about a ring buffer?

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.

Why Java developers hate .NET

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: 1.

The London Java Community elected to the JCP SE/EE Executive Committee

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.

GWT: Why VerticalPanel is Evil

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.