Reverse String in one line

M. Savic — Wed, 28 Apr 2021 11:46:57 +0000

Yesterday, while scrolling Twitter I stumbled upon this one:

30 seconds of code

@30secondsofcode

reverseString: Reverses a string. #JavaScript 30secondsofcode.org/js/s/reverse-s…

12:30 PM - 27 Apr 2021

At first, I was amazed how much JavaScript has changed since the last time I tried it. Spread operator and useful methods directly on array objects are something that I am missing in Java.
Naturally being a Java dev, as I was looking at JS code I tried to transpile it to Java code. Initial code would look something like this:

public String reverse(String in){
    String[] split = in.split("");
    Collections.reverse(Arrays.asList(split));
    return String.join("", split);
}

This works but this is more than one line. To produce oneliner I started looking at Java Stream API and its methods. While I was aware that all intermediate operations are out of the question for such a task, I started looking at available Collectors.
My search came back empty and I had to resort to implementing custom Collector:

public String reverse(String in){
    return Arrays.stream(in.split("")).collect(new Collector<String, List<String>, String>() {
        final List<String> helper = new LinkedList<>();
        @Override
        public Supplier<List<String>> supplier() {
            return () -> helper;
        }

        @Override
        public BiConsumer<List<String>, String> accumulator() {
            return (strings, s) -> strings.add(0, s);
        }

        @Override
        public BinaryOperator<List<String>> combiner() {
            return null;
        }

        @Override
        public Function<List<String>, String> finisher() {
            return strings -> String.join("", strings);
        }

        @Override
        public Set<Characteristics> characteristics() {
            return new HashSet<>();
        }
    });
}

There it is! Technically it's a oneliner. Our supplier method is a simple list, when we add a new item to the list we always do it at the beginning of the list as in the accumulator method. The finisher combines a list into a resulting String. We don't implement combiner because parallel streams are not ordered and we cannot lose the initial string order.
Of course, this is overkill and I did it just for fun, but I got to admit how powerful the Collector API is.
Do you have another way of writing this method? Write it in the comments! Thanks for reading!

Ugliest piece of code you have to write every day

M. Savic — Thu, 18 Mar 2021 21:40:19 +0000

Introduction

We all write code that we are not proud of. Sometimes we are in a rush, sometimes we say we will definitely come back later and deal with all edge cases, usually we tell ourselves different kinds of lies to cover for our own laziness or lack of enthusiasm.

In this article, we will cover one of my worst enemies when it comes to writing clean code. Of course, I am talking about NullPointerException and null checking as usual practice in Java.

Let us take a step back and understand what is null and where do NullPointerException comes from. In the begging, null was created as a keyword for special use case to define a state when something is missing and is yet to be created.
Variables in Java are separated into primitive and reference types. Null and primitive types have nothing in common because primitives are stored in stack memory.

Quick refresher! Java uses two kinds of memory. Stack and heap. In stack memory Java stores primitives and addresses of reference types.

Reference types are where nulls have their usage and where are all NPE's are created.
If we have a list of Strings as our reference type:

List<String> dummyList = List.of("first","second");

dummyList is saved on the stack and it contains the address where is our list located on heap memory.
If we don’t initialize our list i.e. List dummyList; there is no actual memory location to store on stack and Java will default to null. When we try to work with dummyList we will be greeted with NPE and a stack trace.

Checking for null

To avoid NPE before working with reference types we have to check if our object is initialized. There are lots of ways to deal with this and each is uglier than the previous one if you ask me. Without further ado, let us begin.
The good old If keyword and != operator

public void methodOne(String param) {
    if (param != null)
    doSomethingWithString(param);
}

This is the most common way of handling nulls in methods, we write it all the time, it gets the job done. Problems arise when there are multiple parameters and there are multiple checks and different paths for different combinations of null (or not null).

Java 7 introduced Objects utility class that helps us deal with null safety.

public void methodTwo(String param) {
    if (Objects.nonNull(param)) 
    doSomethingWithString(param);
}

Not much is changed here we just moved our if check to a different class.

If you worked with Spring Boot then you probably know that there is annotation for everything. This one comes from JetBrains, creator of IDEA, and is a complement to IDEs static code analysis tools.

public void methodThree(@NotNull String param){
    doSomethingWithString(param);
}

My personal 'favorite' is of course using assert keyword. Assert is added to Java as a check for something that must not happen, when assert check fails its stop the world situation (if -ea flag is used on JVM start). It's rarely used but it's still present in the language.

public void methodTwo(String param) {
    assert param != null;
    doSomethingWithString(param);
}

If the assert fails AssertionError is thrown and JVM is stopped (again if -ea flag is used). My personal opinion is that running applications should never be stoped like this and there are much more graceful ways of shutting down if necessary.

Working with Optional

We saw how we can check if object is null, more checks mean uglier code, it's getting hard to follow, and it's error-prone. What if we never have to check by adjusting how we write code.
Java 8 brought us many changes, including Optional class among others. This enabled us to transform some of our classes to never return null if something is not present or missing.
For an example we could transform our repository class from:

public Person findById(Long id);

Into

public Optional<Person> findById(Long id);

In the first method, we will have to return null if there is no Person with a given id in our repository but if we use Optional we can return Optional.empty(). Returning Optional allows us to use methods such as map, filter, orElseGet, etc. to transform our object or provide new values without doing null check or risking NPE.

One could argue that similar action can be done for collections, but there is other option.

USING PATTERNS

As null checking is common problem in Java world, best practice for mitigating this issue is formed and its name is Null Object pattern.
Sole purpose of this pattern is to reduce null checks in our code using Object Oriented principles. Here we are depending on inheritance and decoupling implementation details from interfaces. To explain the Null Object pattern lets imagine following class structure:

In our Service class we have a method that creates a side effect of sending a notification. At the time of writing this class, we only know that we will send emails but there should be room for more types of messages, so we create NotificationSender interface and two implementations email and nullSender. If we need to send an email we will, obviously, use EmailNotificationSender implementation but for any other case, we will use NullSender implementation. This way our Service class never checks if NotificationSender implementation for our case exists since there is a fallback option that does not produce anything.

Let us return to our Person repository example and introduce filter method as follows:

public List<Person> filterByName(String name);

Client calls this method expecting all Person objects that have given name, this can be 0 or more objects. Returning empty list instead of null will be according to Null Object pattern.
Using Null Object pattern we tell client what is default behaviour and don’t expect it to handle it by itself (Tell-Don’t-Ask principle).

In the end, null is not your worst enemy and there are situations when you need it, these are a couple of ways that I try to avoid using it.

If you got this far, thanks for reading! You are awesome and happy coding!