I just lOvE new toys, and Java 8 has a bunch of them. This time around I want to talk about one of my favourites – concurrent adders. This is a new set of classes for managing counters written and read by multiple threads. The new API promises significant performance gains, while still keeping things simple and straightforward.

As people have been managing concurrent counters since the dawn of multi-core architectures, let’s take a look and see what are some of the options Java offered up until now, and how they perform compared to this new API.

Dirty counters – this approach means you’re writing / reading from a regular object or static field across multiple threads. Unfortunately, this doesn’t work for two reasons. The first is that in Java, an A += B operation isn’t Atomic. If you open up the output bytecode, you’ll see at least four instructions – one for loading the field value from the heap into the thread stack, a second for loading the delta, a third to add them and the fourth to set the result into the field.

If more than one thread is doing this at the same time for the same memory location, you run a high chance of missing out on a write operation, as one thread can override the value of another (AKA “read-modify-write”). There’s also another nasty angle to this which has to do with the volatility of the value. More on that below.

Continue Reading…

15 Must Read Java 8 Tutorials

By Tal Weiss —  April 9, 2014 — 4 Comments

Blog_Green Board


Java 8 was released last month and is just chock-full of new features and behind-the-scenes optimizations. The internet has been doing quite a good job covering all these new additions – both the good and the bad. I thought it’d be good to do a round-up of what we think are some of the best tutorials out there, to help you get you quickly up-to-speed on what’s new and what you need to know.

Java 8 New Features List

Let’s start with the basics – the official OpenJDK list of new features in the Java 8 core library, JVM and the JDK. This is a must read.

The OpenJDK 8 new features list

Lambda Expressions

Hailed as the biggest change to the language in the last decade, Java 8’s Lambda expressions finally deliver core elements of functional programming that have been made popular with languages such as Scala and Clojure right to your doorstep.

This is really one of those cases where I suggest going with the official documentation and tutorials first -

The official Java Lambda expressions tutorial

An extensive Lambda expressions tutorial with examples

Continue Reading…


I’m a great multi-tasker. Even as I’m writing this post, I can still find room to feel awkward about a remark I made yesterday at a party that had everyone looking at me strange. Well, the good news is I’m not alone – Java 8 is also pretty good at multi-tasking. Let’s see how.

One of the key new features introduced in Java 8 is parallel array operations. This includes things like the ability to sort, filter and group items using Lambda expressions that automatically leverage multi-core architectures. The promise here is to get an immediate performance boost with minimal effort from our end as Java developers. Pretty cool.

So the question becomes – how fast is this thing, and when should I use it? Well, the quick answer is sadly – it depends. Wanna know on what? read on.

Continue Reading…


This post may not make me any new friends. Oh well, I was never really popular at school anyway. But let’s get to the point. Java 8’s biggest feature in terms of the language is undoubtedly Lambda expressions. It’s been a flagship feature for functional languages such as Scala and Clojure for a few years, and now Java has finally joined in.

The second biggest feature (depending of course on who you ask) is Nashorn – the new JVM JavaScript engine that’s supposed to bring Java up to par with other JS engines such as V8 and its node.js container.

But these new features have a dark side to them.

I’ll explain. The Java platform is built out of two main components. The JRE, which JIT compiles and executes bytecode, and the JDK which contains dev tools and the javac source compiler. These two components are fairly (but not fully) decoupled, which is what enables folks to write their own JVM languages, with Scala rising to prominence in the last few years. And therein lies some of the problem.

Continue Reading…

Duke_8 copy

Java 8 is packed full of some really exciting features at both the JVM and language level. While some of the features initially envisioned for this release got scoped out or pushed out to release 9, there are literally dozens of new features. Many of the new additions are under-the-hood improvements either at the compiler, JVM or help-system level. As such, while we may benefit from them, there’s nothing we need to actively do (other than install Java 8 of course) to enjoy them.

Having said that, let’s look at 5 features that we feel are an absolute must for you to know about:

1. Lambda expressions

Even if we really didn’t want to go mainstream here, there’s little doubt that from a developer’s perspective, the most dominant feature of Java 8 is the new support for Lambda expressions. This addition to the language brings Java to the forefront of functional programming, right there with other functional JVM-based languages such as Scala and Clojure.

We’ve previously looked into how Java implemented Lambda expressions, and how it compared to the approach taken by Scala. From Java’s perspective this is by far one of the biggest additions to the language in the past decade.

Continue Reading…


Lately we’ve seen a variety of new tools that help you make sense of your logs. Open-source projects such as Scribe and LogStash, on-premise tools like Splunk, and hosted services such as SumoLogic and PaperTrail. These all help you reduce mass amounts of log data into something more meaningful.

But there’s one thing none of them can help you with. They’re all dependent on the data you actually put into the log. The task of getting that quality and quantity of the data right falls on to you. So when the chips are down and you need to debug your code with partial or missing log data, you may want to cancel that dinner reservation.

To reduce the chances of that happening I wanted to share 5 things you should be constantly mindful of when logging in production:

Continue Reading…


In a recent post I took a look at how Java 8 and Scala implemented Lambda expressions. As we know Java 8 is not only introducing improvements to the javac compiler, It’s also introducing a new one altogether – Nashorn.

This new engine is meant to replace Java’s existing JavaScript interpreter Rhino. This is supposed to bring the JVM to the forefront when it comes to executing JavaScript at speed, right there with V8s of the world (hopefully we’ll finally get past that car to carpet thing :)) So, I thought it would be a good time to bring Nashorn to the mix as well by taking a look under the hood, and see how it compiles Lambda expressions (especially compared to Java and Scala).

The lambda expression we’ll be looking at is similar to the one we tested with Java and Scala.

Here’s the code -

ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("nashorn");

String js;

js = "var map = \n";
js += "var names = [\"john\", \"jerry\", \"bob\"]\n";
js += "var a =, function(name) { return name.length() })\n";
js += "print(a)";


Seems innocent enough you’d think. But just wait and see…

Getting to the bytecode

Our first challenge is to get to the actual bytecode which the JVM sees. Unlike Java and Scala whose compilers are persistent (i.e. generate .class / jar files to disk), Nashorn compiles everything in memory and passes the bytecode to the JVM directly. Luckily enough we’ve got Java agents to come to our rescue. I wrote a simple Java agent to capture and persist the resulting bytecode. From there on out it’s a simple javap to print the code.

If you remember, I was pretty happy to see how the new Java 8 compiler uses the invokeDynamic instruction introduced in Java 7 to link to the Lambda function code. Well, with Nashorn they really went to the races with it. Everything now is completely based on it. Take a look below.

Continue Reading…




How to phrase a question in Stack Overflow in order to get better answers

Stack Overflow offers a great interface for accessing all of its data and running any possible query in the questions/answers database. We started using this database to better understand the most common questions about debugging (what we’re trying to solve at Takipi). While learning about debugging through thousands of questions, we also noted an additional bonus: we started better understanding what drives the Stack Overflow community.

This article is the result of researching over 10,000 Stack Overflow questions. It summarizes how you need to phrase and write your question in order to get better and faster answers. When we started running our scripts on the queries’ answers we weren’t sure we’d arrive at strong conclusions. After looking into a few hundred questions, though, we already started recognizing certain distinct patterns that we were seeing over and over again across different programming languages and topics.

You can find a detailed explanation of how we performed the test at the end of the article, but let’s get to the best part first — the results. The main criteria we set for a ‘good’ question were getting high quality answers (from users with high reputation + votes), getting an answer relatively quickly and the number of votes and views.

Keep it short

Probably the strongest pattern we saw across all the different queries and scripts we ran was this: the shorter the question, the more likely you are to get a quick and useful answer. The average length of a ‘good’ question was around 1200 characters (~3-4 short paragraphs), while the average length of a standard question was 1800 characters. The strongest effect of the length was on the view count and votes, where the average length of the top questions was around 50% of that of standard questions.

There’s no such thing as too short, either — really short questions (around 200-300 characters) received the best results.

Continue Reading…


One of the fascinating things about our data structures is that even though we’re so familiar with them, it’s still hard for us to tell exactly how many items something as basic as a HashMap can hold in a 1GB of memory. We may learn this at school, from senior developers, or the hard way when our servers collapse due to poor choice of data structures.

So I decided to do just that. I took ~20 of the most popular Java, Scala, Guava and Trove collections and tested to see how many random ints each of them can hold in a JVM with 1GB of memory (via -Xmx). For each data structure, we appended ints until we received an OutOfMemoryError, which ended the test. We ran each test 5 times on JDK 7 to ensure consistency. For such a fundamental test I found some of  the results to be quite surprising.

* I assume we’re all on the same page in that this isn’t a competition. Different collections have different semantics. I also didn’t include times, as the focus isn’t on micro-benchmarking performance, but on giving us a sense of how much the collections we use everyday can actually hold.

The Results

Continue Reading…


Lambda expressions have taken the programming world by storm in the last few years. Most modern languages have adopted them as a fundamental part of functional programming. JVM based languages such as Scala, Groovy and Clojure have integrated them as key part of the language. And now, Java 8 is (finally) joining in on the fun.

What’s interesting about Lambda expressions is that from the JVM’s perspective they’re completely invisible. It has no notion of what an anonymous function or a Lambda expression is. It only knows bytecode which is a strict OO specification. It’s up to the makers of the language and its compiler to work within these constraints to create newer, more advanced language elements.

We first encountered this when we were working on adding Scala support to Takipi and had to dive deep into the Scala compiler. With Java 8 right around the corner, I thought it would be interesting to see how the Scala and Java compilers implement Lambda expressions. The results were pretty surprising.

To get things going I took a simple Lambda expression that converts a list of Strings to a list of their lengths.

In Java -

List names = Arrays.asList("1", "2", "3");
Stream lengths = -> name.length());

In Scala -

val names = List("1", "2", "3")
val lengths = => name.length)

Don’t be tricked its simplicity – behind the scenes some complex stuff is going on.

Let’s start with Scala

Continue Reading…