Difference between this to method

Question

I have to use a method to call a joiner with " " as parameter for concatenate string a and b, I have to check if either of the sides are empy (""). Both codes works, but i don't get why my reviewer want me to do it in his way. If someone could explain me the benefits of it it would be great.

My method.

public static String join(String a, String b) {
    StringJoiner sj = new StringJoiner(" ");
    if (a.endsWith("dieci") || a.endsWith("veinti")) {
        return a + b;
    }       
    if (a.equals("")) {
        return b;
    }
    if (b.contentEquals("")) {
        return a;
    }
    sj.add(a);
    sj.add(b);
    return sj.toString();
}

His method.

public static String join(String a, String b) {
    if (a.endsWith("dieci") || a.endsWith("veinti")) {
        return a + b;
    }
    return Stream.of(a, b).filter(s ->!s.isEmpty()).collect(Collectors.joining(" "));       
}

Answer 1

His is much simpler; in one line it essentially says:

Take Strings a and b, get rid of the empty ones, and join the remaining ones with spaces, returning the result.

This makes it very clear to see the intention of the code. It also prevents errors, as it would be much easier to have a typo or logic error in your spread-out code that breaks down the implementation into multiple different cases.

Admittedly, this may be harder to understand than your code to start with, as beginners likely won't understand streams. But once you understand them, it is certainly easier to read (at least in this scenario, but not always), and it makes writing such methods much easier. So, it is better to learn such Java constructs now and use them, rather than later.

His code is also much more flexible. If you had to make the method join three Strings, the only modification to his method would be to change Stream.of(a, b) to Stream.of(a, b, c) . Your method would require much more changes.

Also, using isEmpty() is clearer than .equals("") as it says what you're doing in more natural English terms. And this again prevents typos, as you could accidentally do .equals(" ") (with a space) or something.

Also, why do you use two different methods ( equals and contentEquals ) to do the same thing? That is confusing. His method doesn't do that.

Answer 2

First of all, there is always an element of opinion in this kind of thing. And probably communication and personalities too. Is it really worth your effort arguing? If your reviewer wants to rewrite your code in reviews, what's the harm ¹ ?

Now to the substance.

On the face of it, your reviewer's code is clearly both more concise and easier to understand once you are familiar with Java 8 streams. And I imagine that the assumption is that everybody working on this project should be familiar with, if not fluent in streams ² . It clearly deals with the edge cases more neatly.

I would also argue that your use of a StringJoiner to concatenate 2 strings with a space between is overkill. A simple concatenation expression is both more efficient and easier to understand than what you are doing.

   return a + " " + b;

The only other point of difference is performance:

• It is not clear to me which one will perform better. You would need to benchmark the two versions to be sure.
• If you are optimizing for CPU cycles used or garbage generated, neither versions is optimal.

(But note that you should only optimize for performance if you have concrete evidence that the performance of this method is critical to the overall application. If it isn't then optimization is most likely a waste of your time, and a few minutes / hours of your time is probably more costly that a few CPU cycles wasted in millions.)

---

Just for info, if I needed to optimize for performance I would write the method like this:

public static String join(String a, String b) {
    if (a.isEmpty()) {
        return b;
    } else if (b.isEmpty()) {
        return a;
    } else if (a.endsWith("dieci") || a.endsWith("veinti")) {
        return a + b;
    } else {
        return a + " " + b;
    }
}

I will leave the reader to figure out what I have done, and why. And what (possibly unwarranted) assumptions I have made.

---

^{1 - The harm is if he is screwing up your or his productivity ...}

^{2 - Java 8 is 4+ years old now. Plenty of time for a professional to learn to use its new features. And if you are fresh out of Uni and the didn't teach you Java 8 streams ... learn them ASAP!}