Looking ahead to what functionality is available in Java 9, and IntelliJ IDEA’s support (current and future) for it.
How is Java 9 going to change the way developers work?
Content and resources for the Code Review Matters and Manners talk, including links to additional information and
- 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
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. 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”.
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. 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.
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. 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.
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).
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?
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?
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).
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.
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”. 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.
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.
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?).
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).
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.
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?”. 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.
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.
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.
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?
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 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.
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.