• xorium (unregistered)

    Adding a null object and "something" with the + operator will give the string "nullsomething". So it is a null protection. Stupid and ridiculous but it works more ore less. Assuming databaseId never is the string "null" od course. But people using such techniques are very likely to introduce value "null" (the four letter string) in their database also.

  • LionKor (unregistered)

    What xorium said seemed wrong, but indeed, that's what it does:

        public class Main {
            public static void main(String[] args) {
                    System.out.println(null + "");
            }
    }

    javac Main.java && java Main:

    null
  • (nodebb)

    Actual Java programmers use the StringUtils library from Apache Commons Lang for null safe string comparison.

  • (nodebb)

    Of course the null value is supposed to fail comparison to anything, including another example of the null value. By them pulling the [convert null to "null"] trick, now the comparison succeeds if both parameter values are the null value.

  • (nodebb)

    Of course the null value is supposed to fail comparison to anything, including another example of the null value

    Yes in SQL, but this is Java. I've never heard of any semantics like that in Java. In fact null == null has always been true.

  • (author) in reply to xorium

    Hunh. I tried basically the same program in an online compiler when writing the article, and it threw an exception, because I wasn't sure what the behavior would be. I'm wondering if there's a version/flags element that makes it behave differently? That doesn't seem very Java.

  • Lothar (unregistered) in reply to Remy Porter

    I tried basically the same program in an online compiler when writing the article, and it threw an exception

    Then that online compiler has a bug because null + "" gives you "null" since Java 1.0.

  • (nodebb) in reply to Remy Porter

    The proper way to do this (without third party libraries) would be return Objects.equals(requestedAssetId, databaseAssetId);. If both values are null it returns true, if only one of them is null it returns false, and if neither of them are null it compares their contents.

  • Rob (unregistered) in reply to LionKor

    With modern Java versions you don't need to compile, you can run "java Main.java". And from Java 25 on (coming in September) the file can also be simplified:

    void main() {
    IO.println(null + "");
}
  • Don't fix it if it ain't broke (unregistered)

    Swing and a miss, Remy and/or whoever submitted this code. There's no WTF here. Concatenating an empty string just helps with null handling. Yes, there's other ways this could've been done probably. But I'm certain this function was implemented as a bugfix for something at some point, and it helps fulfill some design requirements and/or deeply baked assumptions elsewhere in the code. It's not clean, it's not pretty, it's not best practices, but it works. I'm sure of it. And it's not atrocious, so it gets a pass from me.

    PS: no, you can't just do Objects.equals(id1, id2). That would change the outcome between a null string and the string "null". It's a dubious way to do things, but changing it would surely break something somewhere, and fully "fixing" it would require a lot of unnecessary work and introduce unnecessary risk.

  • (nodebb) in reply to Don't fix it if it ain't broke

    I think the "correct" implementation would be

    requestedAssetId != null && requestedAssetId.equals(databaseAssetId);

    This IMO is clearer than the submitted code, which, as exemplified by the fact that it was submitted and misunderstood even by an online compiler and the site owner, is a little bit obscure.

    Ironically in view of my previous comment, it implements SQL null semantics. If you want to return true if both arguments are null Objects.equals() is fine because the fact that the method returns true if one argument is null and the other is "null" is surely an unintended side effect.

    Addendum 2025-08-04 13:24: s/side effect/consequence/

  • (nodebb) in reply to LionKor

    OMFG that is another braindead Java WTF. Are you serious? Who thought coalescing null to "null" was a good idea? Mind blown, for sure.

  • (nodebb) in reply to Mr. TA

    Sadly in .net they copied the behavior to make a J# port easier.

    There has traditionally been no operator+(string, string) instead the compiler uses string.Concat directly when creating IL. But that method family treats null as ignore instead of throwing an exception.

    One of those many stupid design decision we ended up with simply because MS wanted to bring out a Java version of .net which failed in like 2 years.

Leave a comment on “Concatenated Validation”

Log In or post as a guest

Replying to comment #682990:

Log Out

« Return to Article