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.

<img src="; alt="Woohoo lambdas!" title="Woohoo lambdas!">

The aim of this session was to talk about Lesson 3, but also to wrap up the course as a whole: to talk about what we liked and what we would have improved (about both the course itself and our user group events).

As in the previous two posts, let’s outline our discussion areas:

findAny() vs findFirst(): Why do we need both of these methods, and when would you use them?

Well, findFirst() is the deterministic version, which will return you the first element in the Stream (according to encounter order - see the section on Ordering in the documentation). So, regardless of whether you run the operation in parallel or serial, if you’re looking for “A” and use findFirst with this list:

["B", "Z", "C", "A", "L", "K", "A", "H"] 

you’ll get the element at index 3 - the first “A” in the list.

But findAny() is non-deterministic, so will return you any element that matches your criteria - it could return the element at index 3, or the one at position 6. Realistically, if the stream is on an ordered collection like a list, when you run findAny on a sequential stream, I expect it will return the same result as findFirst. The real use-case for findAny is when you’re running this on a parallel stream. Let’s take the above list, and assume that when you run this on a parallel stream it’s processed by two separate threads:

["B", "Z", "C", "A",    // processed by thread 1   "L", "K", "A", "H"]     // processed by thread 2 

It’s possible that thread 2 finds its “A” (the one at position 6) before thread 1 finds the one at position 3, so this will be value that’s returned. By configuring the Stream to return any one of the values that matches the criteria, you can potentially execute the operation faster when running in parallel.

If findAny is (potentially) faster in parallel and (probably) returns the same value as findFirst when running in serial, why not use that all the time? Well, there are times when you really do want the first item. If you have a list of DVDs ordered by year the film was released, and you want to find the original “King Kong” (for example), you’ll want findFirst to find the one released in 1933, not the one that was released in 1976 or the one from 2005.

Plus, findFirst is not always going to be slower than findAny, even in parallel. Going back to our list:

["B", "Z", "C", "A", "L", "K", "A", "H"] 

Trying to findFirst or findAny for “H” could be the same performance for both methods.

Collectors: Maybe it’s just me who doesn’t really see the big picture for collectors. I’m perfectly content with the built in collectors like:




It’s easy to see what they do, and work out when you need to use them.

I’m also very happy to have discovered joining:


a super-useful way to create Comma Separated Values (CSVs) that I use in my Java 8 demo.

Where things get a bit murky for me is where we start chaining up collectors:


(it should be obvious from my lack of clear example that I’m not 100% certain under which circumstances these are useful).

As a group, we think the chained collectors are kinda ugly - not because we’re against chaining (we like Streams), but maybe because it’s another chain inside a param to a chain.

We think this is an area where some good, solid examples and a bit of daily use will make it much clearer to developers. We hope.

Related to this, the course didn’t go into creating your own collectors at all. My personal (under-informed) opinion is that I guess most developers should be able to use either the out-of-the-box collectors (toList etc) or use the collector chaining to build what they need. If you need a custom collector, perhaps you haven’t considered everything that’s already available to you. But as a group, we decided we would have liked to see this topic anyway so that we could get a deeper understanding of what collectors are and how they work.

Exercises for lesson 3: Well. What can we say? I really hope there are people reading this who haven’t finished the course yet, because the Sevilla Java User group would like to say to you: don’t despair, the lesson 3 exercises are substantially harder than those for lessons 1 and 2. Honestly, the whole group considered it less of a learning curve and more of a massive cliff to climb.

I have no idea what I am doing

I mean, it was great to have something so challenging to end on, but it probably would have been less ego-destroying if we could have got up to that level gradually instead of having it sprung on us.

The good thing about Part 2 of the lesson 3 exercises was that we had three very different answers to discuss in the group. None of us were super happy with any of them, but we could see definite pros and cons of each approach, and that’s something you really want to learn in a course like this.

It was also really great to have a rough performance test to run on your own computer, so that you could really see the impact of your choices on the performance of the stream.

For more info
I’m going to add a shameless plug to a friend’s book here. I’ve been reading a lot about Java 8 for this course, for my Java 8 demo, and to generally get up to speed. My favourite book for getting to grips with lambdas and streams is Java 8 Lambdas: Pragmatic Functional Programming by Richard Warburton. This book also contains more info about collectors too, so maybe some of our questions around how to use these in more complex situation are answered in here.

In Summary
We really enjoyed the MOOC, and the sessions to get together to discuss it. We particularly liked that the meetups were a safe place to ask questions and discuss alternative solutions, and that we weren’t expected to be genius-level experts in order to participate fully.

If/when Oracle re-runs the MOOC, if you didn’t get a chance to take part this time I highly recommend signing up. And if you can find (or run) a local meetup to discuss it, it makes the experience much more fun.

Java 8 MOOC – Session 2 Summary

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 second week’s lesson was about Streams - how you can use the new stream API to transform data. There was also a whole section on Optional, which initially seemed like rather a lot, but it turns out that Optional can do rather more than I originally thought.

In the meetup session, we talked about:
Optional: we were pretty comfortable, I think, with using Optional to prevent a NullPointerException. What we weren’t so clear on were the examples of filter() and map() - if you were getting your Optional values from a stream, why wouldn’t you do the map and the filter on the stream first? For example, why do this:     .findFirst()     .map(String::trim)     .filter(s -> s.length() > 0)     .ifPresent(System.out::println); 

when you could map and filter in the stream to get the first non-empty value? That certainly seems like an interesting question in relation to streams.

I can see Optional being more useful when other APIs fully support Java 8 and return Optional values, then you can perform additional operations on return values.

That terminal operation’s not actually terminal??: We ran into this a couple of times in our examples in the session, one example is the code above (let’s copy it down here so we can look at it more closely):     .findFirst()     .map(String::trim)     .filter(s1 -> s1.length() > 0)     .ifPresent(System.out::println); 

Isn’t findFirst() a terminal operation? How can you carry on doing more operations on that?

The answer is, of course, that the return type of the terminal operation can also lead to further operations. The above is actually:

Optional<String> result =                               .findFirst();       .filter(s1 -> s1.length() > 0)       .ifPresent(System.out::println); 

Our terminal operation returns an optional, which allows you to do further operations. Another example of this confusion:     .map(String::toLowerCase)     .collect(toList())     .forEach(System.out::println); 

Here, collect() is a terminal operation, but it returns a list, which also allows forEach():

List<String> results =                            .map(String::toLowerCase)                            .collect(toList()); results.forEach(System.out::println); 

So be aware that just because it’s called a terminal operation, doesn’t mean you can’t perform other operations on the returned value.

Parallel/sequential/parallel: there had been a question in the previous week about why you could write code like this:     .parallel()     .map(String::trim)     .sequential()     .filter(s1 -> s1.length() > 0)     .parallel()     .forEach(System.out::println); 

and whether that would let you dictate which sections of the stream were parallel and which were to be processed in serial. Lesson two set the lesson straight, declaring “the last operator wins” - meaning all of the above code will be run as a parallel stream. I can’t find any documentation for this, I’ll edit this post if I locate it.

Unordered: “Why would you ever want your stream to be unordered?” - the answer is that unordered() doesn’t turn your sorted collection into one with no order, it just says that when this code is executed, the order of elements doesn’t matter. This might make processing faster on a parallel stream, but as a group we figured it would probably be pointless on a sequential stream.

Efficiency optimisations and order of stream operations: We had a long conversation about the order in which you perform operations in a stream. The MOOC (in fact, most documentation around Streams) tells us that a) streams are lazy, and not evaluated until a terminal operator is encountered and b) this enables optimisation of the operations in the stream. That lead to a discussion about the following code:     .map(String::toLowerCase)     .filter(s -> s.length() % 2 == 1)     .collect(toList()); 

The filter operation should result in less items to process in the stream. Given that the map() operation doesn’t change anything that filter() relies on, will this code be optimised somehow under the covers so that the filter is actually executed first? Or are optimisations still going to respect the order of operations on a stream?

Our case is actually a very specific case, because a) the map() returns the same type as the params passed in (i.e. it doesn’t map a String to an int) and b) the map() doesn’t change the characteristic the filter() is looking at (i.e. length). But generally speaking, you can’t expect these conditions to be true - in fact I bet in a large number of cases they are not true. So pipeline operations are performed in the order in which they are written, meaning that our map and filter will not be re-ordered into a more efficient order.

A good rule of thumb seems to be to do filtering as early in the stream as possible - that way you can potentially cut down the number of items you process in each step of the stream. Therefore our code would probably be better as:     .filter(s -> s.length() % 2 == 1)     .map(String::toLowerCase)     .collect(toList()); 

**Flat Map**: what...? [flatMap()]( is one of those methods that makes total sense once you get the hang of it, and you don't understand why it was so confusing. But the first time you encounter it, it's confusing - how is flatMap() different to map()?

Well, flatMap is used to squish (for example) a stream of streams into just a simple stream. It’s like turning a 2-dimensional array into a single dimension so that you can iterate over all the items without needing nested for-loops. There’s an example on StackOverflow, and some more examples in answer to this question.

Comparators: We’ve probably all written comparators at some point, it’s probably one of those examples where we really did use anonymous inner classes “in the olden days” and were looking forward to replacing them with lambdas.

reader.lines()       .sorted(new Comparator<String>() {           @Override           public int compare(String o1, String o2) {               return ???;           }       })       .collect(toList()); 

Sadly, using a lambda still doesn’t answer the question “do I minus o1 from o2, or o2 from o1?":

reader.lines()       .sorted((o1, o2) -> ??? )       .collect(toList()); 

But there’s yet another new method in Java 8 here that can save us, one that is not nearly as well publicised as it should be. There’s a Comparator.comparing() that you can use to really easily define what to compare on. The JavaDoc and signature looks kinda confusing, but this is one of those places where method references suddenly make loads of sense:

reader.lines()       .sorted(comparingInt(String::length))       .collect(toList()); 

(Here we’re actually using the comparingInt method as we’re going to compare on a primitive value). Personally this is one of my favourite new features in Java 8.

Join us next week for the [last session on Java 8 - Lambdas and Streams](

SVQ JUG: 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.

Continue reading "SVQ JUG: The State of Java"

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:

This is very much aimed at Java/JVM developers who are new to MongoDB, and want to get a feel for how you use it.

These guides are for the current (2.x) driver. When we release 3.x, we’ll release updated guides as well.

Sevilla Java User Group Java 8 Launch Party

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:

Note that the last link is to a video from vJUG, the Virtual Java User Group, which is a great source of presentations from international speakers.

Nighthacking at Sevilla Java User Group

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.

This is also the first event that we’ve had videoed (apologies for the horrible focus at times on the video, I’m just learning and used to relying heavily on auto-focus).

Thanks very much to Stephen for visiting, and thank you to those who came, you’re making me re-think the idea of running events at weekends.

Also there are photos on Meetup.

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.  Sort of.  Some times I’ve been on the bleeding edge, and others… I remember using JavaScript to call back-end services with an XML payload before people were using the term AJAX, but I also remember working on an enterprise um… “classic”… JSP application only “recently” - in fact that was probably the last job where I did anything that looked like web development.
So this blog post is going to chart the progress of web development through my own experience.  Of course, this doesn’t by any means cover the whole spectrum, but I think my experience has been not unusual for a Java programming working through the noughties.
Over the course of my career I moved further away from the UI, because certainly early on the money and status was in “back end”, whatever that means, and not “front end”.  Which is ridiculous, really, especially as back then you couldn’t really follow best practices and clean code and test first and all that awesome stuff when doing front end development because none of the browsers played by the rules and frankly if you got it working at all you were a bloody genius.  And that’s not even considering the fact that as a “front end” developer you should be thinking about actual real human beings who use your product, and actual real human beings are messy things and understanding them is not (we’re told) traditionally a domain that we developers are naturally proficient in.
Anyway, I digress.  This was supposed to be a history lesson.  Or a nostalgia trip.  Or possibly Ranty Trish waving her walking stick in the air and shouting “You kids don’t know how good you’ve got it these days”.  If nothing else, I hope that it makes other “back end” developers like myself appreciate how much things have moved on.
Let’s go back to the olden days, before I’d even graduated: picture a time before smart phones - before phones were even common (I was horribly mocked at university for being poncy enough to have a mobile), before we knew if all this work we were doing to combat the millennium bug was going to stop the end of the world.  I was doing my first summer internship at Ford, and a contractor from Logica (who don’t seem to exist any more??) told me that if I was messing around with web pages and HTML (my friends and I had geocities-and-equivalent sites) I should look at this JavaScript thing to make my pages “dynamic”.  I didn’t have to just use GIFs to bring my page to life, I could move stuff around on the page.  I think I wrote a “you are in a crowded room”-type adventure game, because my background was BASIC and that’s what you do.
Actually I haven’t even mentioned that we were creating these websites to stay in touch with each other.  We’d discovered guest books, and used them to write comments and share stories since we’d all moved out of our home town to go to different universities.  Man, why didn’t I invent Facebook back then?  That’s what we needed.
A year later, I was back at Ford doing my sandwich year-in-industry.  The first project I worked during this time was a web-based reporting tool that needed to dynamically display hierarchical data.  We chose JavaScript trees to render this data - my year of messing around with my website paid off, and I was able to use my “cutting edge” Javascript skills in a real production environment.  Yay?  The back end was CGI - I think I was writing in Perl, but don’t tell anyone that.  I was learning Java at university, but this was a new language and I don’t think Ford was using it yet.
The next project was a very ambitious one - be the first car manufacturer to sell new cars on the web.  Ford was well ahead of their time - the millennium bug had not killed us all, but people were barely buying books online, never mind spending tens of thousands of pounds on a car they’d never driven.  But it wasn’t just ahead of its time from a business point of view, technically it was very advanced too - we used lots of “DHTML” (as we were now calling it), a new-fangled technology called ASP, and we were writing modular, reusable COMponents.  We used XSLT to parse the XML from the COM objects, and the ASP figured out whether you were Netscape or Internet Explorer (Firefox wasn’t even a gleam in the inventor’s eye, and forget Chrome, I think we using Alta Vista (whaaaat? AltaVista got bought by Yahoo??) not some new-fangled search engine beginning with G) so it could use the right XSLT to turn the XML into HTML that was readable by the browser you were using.  My job was to get the DHTML pages rendering and animating correctly in both IE4 and Netscape 4.  That was a lot of fun for me, but also very challenging.  And imagine my shock when a few months later I tested the site from the university UNIX machines to find that Netscape rendered it completely differently under UNIX.  I learnt a lesson about how important it was to test on different platforms.
We had some smart Microsoft people helping us out with this project, and, because it was 2000 and the dot com crash hadn’t happened just yet, we also had a lot of young, overpaid, overconfident contractors who believed anything was possible.  I learnt a lot during this time, not just about the technology, but also about different approaches to shaping your IT career.  And about how much you could earn before you were 25.  I was definitely going to be a programmer when I left university the next year.
Yeah, so… I graduated in 2001.  If you were around then, you’ll remember that getting a job was a bit more difficult than I had anticipated, especially as these young, overpaid contractors were now desperately grabbing anything they could find.  But that’s a story for another day.
I didn’t go back to Ford straight away, I’d “been there and done that”.  I worked on the website for Common Purpose.  On the first day, they sat me down with a book on JSP and Servlets, and that was my reading material for the next few weeks.  If I’d been fresh out of university where we’d been doing Applets, and where I’d written a Swing app on the side for my Dad’s school, this would have been a big mindset change for me.  But having worked on the ASPs it wasn’t such a big shift.  I did, however, like how JSPs and servlets made the separation between the view and all-of-the-other-logic-stuff a bit clearer - back in ASP-land we’d settled on a convention of dealing with the form data from the previous page in the first part of the ASP, and rendering the new page in the second part.  To this day I still don’t know what we should have been doing instead.  But in JSP-land it only took me… I dunno, about 6 months I think, to get the website up and running.  The most difficult section was registrations.  And yes, I was a graduate, and yes, I was new, but that was a good turnaround for a web application “in those days”.
In my spare time I used what I’d learnt on the blews website.  I even had a section where people could log in and comment on photos - we had whole conversations on this website.  It was a way for me and my friends to stay in touch.  If I’d cracked the photo-uploading instead of it being a manual process for me, I would have invented Facebook.  If only I’d known….
The work dried up and there was nothing else for a graduate in the early noughties, so I went back to Ford.  My first role back I picked the same technologies we’d been using before - XML, XSLT, only this time we were using JSPs instead of ASP.  Our project had a very tight budget and we’d worked out that using open source Java technologies and running the application on one of the many UNIX machines lying around the place was a lot cheaper than the Microsoft solution.  I think we were the first team in Ford Europe to pick Java at a time when the recommended approach was Microsoft.  We delivered on time and under budget, and Java was the way forward for the department from then on.  But on this project I met a guy who would impact my career probably more than he even realises, a guy I’d work with again later.  He told me that in Java we no longer used Vector by default, but ArrayList (whaaat? What’s an ArrayList? I had no idea what the differences were between Java 1.1, which we’d learnt at university, and Java 1.2, which was now standard).  And questioned my choice of XML/XSL.  Although I’d been learning new technologies and growing, he was the one who made it clear to me that I needed to keep myself ahead of the curve with the technologies I was using, or planned to use, if I wanted to stay relevant and make my life easier.
On the next project I worked with a genius guy who was definitely keeping ahead of the curve - he was using JavaScript to send small XML payloads to the server (which was coded in Java), and rendering the response in place on the page instead of reloading the whole thing.  Mind.  Blown.  I didn’t even hear the term Ajax until a year or more later.  We were fortunate in that this was once again an internal application, so we controlled the browser.  This was back in the days when you wanted your users to be on IE5, as this was the only browser that supported this functionality.
The next few projects/jobs I worked on were all more pedestrian variations on the JSP theme - first I learnt Struts, which at least made us realise there was a model, a view, and a controller.  Then at Touch Clarity I learnt about Spring MVC, which actually put the validation errors next to the boxes which cause the error - by default, without you having to mess around.  Spring was a revelation too, a framework that really tried not to get in your way.  It was also frustrating because you needed to understand its lifecycle, but it did so much heavy lifting for you, it sped up standard CRUD-app web development enormously.
A couple of years passed, during which time I was still working on a web application (for an investment bank) but I can’t for the life of me remember what technologies we used (other than Java).  I know it was hard to test and I know the tricky stuff was “back end” not “front end”.
In the next project where I had any control of the technology, I picked Spring since I’d had such a good experience previously.  It took 4 developers a couple of months or so to develop an admin application for a trading app.  Given the previous timescales I’d worked with, this seemed pretty good.  Until a few months later and two other guys on the project produced an admin app for our bank users in a matter of weeks.  I can’t remember what they used, maybe Grails?  But it was another demonstration of how I really should have been researching the field instead of simply sticking with what I knew, especially when I knew my knowledge was a couple of years out of date.
Fast forward to LMAX, and we were using GWT, pre-2.0 - I think this probably feels natural if you’ve been a Swing or AWT developer, but I’m still not convinced it’s a sound web platform (although I know it has improved).  It was great because cross-browser was no longer an issue, but it was bad because it separates you from the underlying HTML, which means you can seriously mess up without realising.  It’s also hard to use CSS correctly when you don’t have access to all the HTML components.
So we come to more-or-less the present day, as it should be fairly obvious that during the time I’ve been working on the MongoDB Java Driver I haven’t done a lot of GUI development. I’m lucky because attending lots of conferences means I see a lot more of the current-trending technologies, but up until a couple of weeks ago I hadn’t had a chance to play with any of them.
So now I’ve been trying Angular.js, Bootstrap, and UI Bootstrap.  My goodness.  It’s a whole ‘nother world.  I’m seeing at conferences and user groups that developers are increasingly polyglot, so maybe there’s no such thing as “just” a Java developer any more, but if you are “just” a Java developer, I think it could be… interesting… to get your head around some of the techniques.  Since we don’t have closures, our callbacks are ugly and we tend not to program that way.  Async is not something that comes naturally in a Java environment, I believe, although after working that way at LMAX I’m personally sold on it.  Old-world JavaScript developers like I am/was might also find it hard to understand you can have clean, testable JavaScript code which Just Works.  It didn’t even occur to me to worry about browser compatibility, and my app not only worked on my phone as well as my laptop, but looked really phone-ish and awesome with very minimal effort.
I’m currently on a plane on the way to QCon London where I’m going to demo this Brave New World of web development (together with a nice Java back end to prove how awesome Java is to work with and, of course, a MongoDB database).  So it is not my intention in this post to explore what this new world looks like.  But I have seen the Present, and it’s a lot better than the Past.  Kids These Days don’t know how good they’ve got it - they’ve never had to struggle, to fight the browser, to hand-craft their JavaScript like we have, or had to work with raw, low-level JSPs and Servlets.
Now things are easier.  There are standards, there are libraries, there are best practices and YouTube videos showing you how to create apps in 60 minutes (back in My Day I had to borrow someone else’s browser to use the Internet, and I debated for years the value of spending my own actual money on a Javascript actual paper actual book, which I could not afford).  Now, you can get something quite pretty and functionally interesting, working in a lot less time than I realised.  But that doesn’t mean the Kids These Days have it easier - it means there is so much more potential.  Instead of beating your head against trying to get a specific version of IE to do what you want, instead of having to write separate pages for different browsers (although maybe that still goes on), you can be exploring so much further into the possible, try things that no-one else has done yet.  It opens up so many interesting possibilities for apps on all platforms.
Exciting times.

So next time someone asks me “What is the de facto front-end framework for Java?” I’m going to say HTML5, CSS and JavaScript.