C# for Java Developers, Part I

If all the planets align correctly, and World War III doesn’t break out, I might be dabbling in C# within the next 12 months. But I’m a hard core Java developer. How do I effectively learn C# while at the same time staying sane? Here’s my quick and dirty C# for Java Developers guide.

C# (pronounced see sharp) first appeared in the year 2000, 5 years after Java. It’s currently at version 7, which was released in March this year. The language is similar to Java in many ways, but it’s also very different. Both Java and C# are typed statically and strongly, object orientated, use curly braces to define scope, and semi colons to indicate line endings. While they have similar syntax, the C# syntax differs enough from Java that it might look a bit confusing to a long time Java developer at first sight.

The structure of this guide is as follows: Each hand picked topic consists of three sub sections. One code sample from each camp, and then some quick bullet points that cover what I consider the most important takeaway from the particular subject. All code you see is also available in the C# for Java Developers GitHub repository.

A word of warning: I’m writing this guide as I learn C# myself, so don’t except everything to be 100% accurate. Consider reading this as a way to kick start your own C# adventure.

Without further ado, let’s jump in the deep end of the pool.

Esoteric Programming Languages: Brainfuck

“B” is for Brainfuck.

In early February, Stack Overflow data scientist Julia Silge published an article titled “What Programming Languages Are Used Most on Weekends?“. The data used to deduce what’s hot and what’s not among our fellow nerds during the weekend, is what tags are used on Stack Overflow questions.

Haskell, a function programming language, saw most questions during the weekend. Now, a high number of questions on Stack Overflow doesn’t necessarily mean that a language is immensely popular. It might just mean that Haskell programmers are dumb. Oh, I kid, I kid. I’m sure Haskell programmers are quite intelligent – and I’m hoping they have a sense of humor.

Anyway. What the data from Stack Overflow do show, is that programmers are focusing on very different things during our workweek than we do during the weekend. While a workweek is filed with cringe worthy topics like SharePoint, TSQL, and (gasp!) VBA, the weekend tend to be for experimenting with new things.

Let’s have a brief look at an esoteric programming language that might be of interest for your next weekend of experimenting: Brainfuck.

java.util.Optional Addendum

So you thought I was done with the Java 8 posts now, didn’t you? I thought I was, too, but no. As pointed out by Terje in this comment, my java.util.Optional example wasn’t very good1. Let’s treat his comment as code review feedback, and see if we can crack out a better example.

Terje argues that it would be better to use an Optional to clarify that something can be null. Or perhaps nil – non-existent – is a better term for the Optional’s state; as we saw in the previous post, the point of the Optional is that it does not contain null values. Instead, the Optional object is empty and its isPresent() method will return false. Another good point that is raised in the comment is that, even though it might be tempting, it could be bad to use Optional everywhere. Use Optional when something can be null, don’t use Optional if something can’t be null.

With all that in mind, here’s another example where the use of Optional perhaps makes more sense. Imagine a service that returns a user’s full name given a user name. But what happens if there is no user with the given user name? I’ve seen many creative solutions: Throw an exception, return an “I’m afraid I can’t let you do that, Dave”-string or return null. All of these solutions have their own flaws, which we will not get into now. Instead, let’s solve this conundrum by returning an Optional.

public Optional<String> getFullName(String username) {
    if ("th".equals(username)) {
        return Optional.of("Tony Hawk");
    } else {
        return Optional.empty();

If the input to getFullName(…) is “th”, then an Optional containing the String “Tony Hawk” is returned. For any other input the method, it returns an empty Optional. Usage of the getFullName(…) method could look something like this:

System.out.println(getFullName("th").orElse("No user found"));

Here, we print full name if it’s contained in the Optional, or the string “No user found” if the returned Optional is empty.

Better? Better.

What’s New in Java 8? Part II

This is the second and final part of a two post series on some of the new features and enhancements in Java 8. In the first post, we covered lambda expressions, method references, default methods and static methods in interfaces, and looked briefly at how we could debug lambda expressions. Since I did all the necessary Java 8 introductions in the first part, let’s just get on with what you came here for: A second dip into what’s new in Java 8.

To prevent the code samples from getting wider than the page, Iโ€™ve taken the liberty to omit the “final” keyword where it would be natural to use it. Also, most of the code below wonโ€™t compile as-is, since Iโ€™ve omitted the class declarations – but all the code examples used are available in compilable and runnable versions on GitHub, so why don’t you go ahead; clone that repo and knock yourself out.


One of the biggest pitfalls in Java is the dreaded NullPointerException, or NPE for short. An NPE is an unchecked exception that will only be thrown at runtime and when the NPE bomb goes off, bad things are likely to happen. Preventing an NPE in your code really isn’t that hard, it’s just tedious and creates code that should be unnecessary.

Let’s say you use a badly documented third party API. The API contains a method that you know returns a List of Integers because it says so in the method signature and you use the method in your code like this:

List<Integer> integers = ThirdPartyAPI.getIntegers();

The problem with this code is that you don’t know what the third party implementing the API has decided to return if there are no Integer objects to return. Will the method return an empty list? Or will it return “null”? If the former is the case, you’re home free, but if the latter is the case, line #2 will cause an NPE to be thrown. It might be that you know that the method returns an empty List if there are no Integer objects to return – you could have written a unit test that somehow proves it or even reverse engineered the third party code – so you feel that the above code is safe. But what happens if the API developer for some reason decides to change the implementation so that “null” is returned instead of an empty list? Then you’ve suddenly got a major “whoopsie” in your code. It’s not your fault, per se, but I doubt that your client cares much about whose fault it is.

In our case, we’re lucky enough to have access to the source code for the third party API:

What’s New in Java 8? Part I

If you think I’m a little late to the party, you’re absolutely right. Java 8 was released in March 2014, well over a year ago, and there has been plenty of time to look at version 8’s new features. Unfortunately, I’m still crawling my way through millions of lines of Java 7 legacy code at work, and it is not until now that the client has decided to make the jump to version 8. The reason is that, as of April 2015, Oracle stopped releasing public updates for version 7, and gaping security holes will no longer be patched. Thank you, Oracle! You might think this is a sarcastic “thank you”, but it’s really not. If it wasn’t for the fact that there will be no more security updates for Java 7, the client would probably never have decided to upgrade.

Java 8 comes with a range of new features and enhancements, conveniently summarized by Oracle in an article aptly titled What’s New in JDK 8. Among the changes are some that were supposed to be in Java 7, but that, for various reasons, were postponed to Java 8. Some of the new features are changes developers have been screaming at Oracle (and Sun) to implement for years. Now that they have finally managed to get them in there, we should try to use them, shouldn’t we? This was originally intended to be a single post covering the most interesting new titbits of Java 8, but I quickly realized that it was too much to get through in one post, so I split it in to two parts.

Now, let’s have a look at a small set of the new features and enhancements in Java 8. I’ll focus on the features hat I’ll benefit most from during a typical work day. All the code examples used are available on GitHub.