A collection of Stack Overflow questions that you shouldn’t miss out on:
It’s no secret; we all use Stack Overflow. It holds the answers to life, the universe and pretty much everything code related. The platform provides a place for developers, engineers and others to find answers to an issue that they’re facing, or at least set them on the right track towards a solution.
One of the most popular categories on Stack Overflow is Java, with almost 1.5 million questions asked in total, and hundreds that are added every day. It holds some pretty interesting answers to questions you’ve stumbled upon in your day-to-day tasks, as well as answers to questions you had no idea you should ask.
We can always learn something new, and that’s exactly what we decided to search for: Interesting answers to questions we didn’t know we had. Let’s check it out.
— OverOps (@overopshq) July 3, 2018
Stack Overflow is a place to find answers, but it’s also an excellent place for more questions and riddles. Kevin Cruijssen, a Software developer from the Netherlands posted asked the following question:
To prove it, he created the following code:
Running this in Java 8, we get the following output:
However, in Java 10, we get this:
Before you read on, can you try to guess what happened here? What is the mysterious Java property that led to the different output between versions?
Prepare to be underwhelmed: it’s a bug in javac, that started at JDK 9. According to the official bug report, when “+=” is applied to String operands it can cause some side effects, as we can see in the code above.
Jorn Vernee took this answer one step forward and looked at the corresponding bytecode for this line:
array[i++%size] += i + ” “;
This is the output:
On the bright side, this issue has been fixed and will deploy in JDK 11, along with some other nice features.
The Importance of NullPointerException
How much time do you spend going over logs, trying to find exceptions and handle them? We already know the answer – too long. And indeed, Stack Overflow provides a place where we can consult and search for the right answers to relevant questions, and in most cases, someone has already encountered the very same issue in the past.
One of the more common exceptions developers encounter is NullPointerException. In fact, it’s the most common exception in Java production environments. One question that caught our eye was someone trying to find the root cause of the issue, by asking “What is a NullPointerException, and how do I fix it?.”
The most voted up answer broke it down to steps, so it’ll be easier to understand what happens in the process. It starts by declaring a pointer to an object, by declaring a reference variable.
The first line is the pointer, and since we didn’t state what to point it to, Java sets it to null. It’s only on the second line where we create an object type Integer and the pointer variable num is assigned this object.
NullPointerException occurs on the first line, after we declare a variable but didn’t create an object. If we will attempt to dereference num before we create the object, we’ll get a NullPointerException. In the most trivial cases, the compiler will catch the problem and let you know that “num may not have been initialized” but sometimes you write code that does not directly create the object.
How can you solve it? One of the more talked-about methods on Stack Overflow is by adding null checks throughout the code. However, you’ll end up with too many lines of code that looks like this:
And again, Stack Overflow comes to the rescue to help us make this code more efficient. Checking for null within the code makes sense in the case of null not being a valid response in terms of the contract, or… when it’s not a valid response.
The first advice is pretty simple: don’t use null as a response. However, if null is a valid response, we have to check for it. It’s easier when we’re using methods that return collections; we can return empty collections (or arrays) instead of nulls.
If we’re not using collections, we can use the Null Object pattern. In this pattern, we use an object which implements the expected interface, whose method body is empty. To put it in code, compare this:
If it’s the second case we’ve mentioned, null not being a valid response, we can use assert statements. So it’ll look like this:
There are other ways in which you can handle NullPointerExceptions and explanations of why it’s so important – check it out.
Local Variable Type Inference in Java 10
One of the most talked-about changes in Java 10 was the introduction of Local Variable Type Inference, adding some syntactic sugar to Java – simplifying it and improving the developer experience.
Java 10 allows us to declare variables without having to specify the associated type. So:
Will be replaced with this new, simplified syntax:
This change leads to an interesting question; What is the difference between var in Kotlin and in Java? As Alexey Romanov explained, their meaning is very different.
In Kotlin, var means “this is a mutable variable”, and can be used both when type is inferred and when it’s explicit. On the other hand, the meaning of var in Java is “this is a variable with inferred type”, and can be used both for mutable and final variables.
The bottom line is that var in Java can only be used for local variables; while var in Kotlin is used for properties as well.
Stack Overflow is more than just a question and answer site. It’s a community, where people help each other out, have lively discussions and just come to enjoy themselves.
If you need help with a piece of code or have a fun riddle that you can’t solve, it’s the perfect place to go. These questions make up just a small part of what you can find there, and if you’ve seen questions that you think deserve a spotlight, we want to know! Post your favorite answers or unanswered questions in the comments below.