Fork me on GitHub
Marc O'Morain11:12:44

@andy.fingerhut I’ve been bitten in the past by the unexpected behaviour of Boolean/valueOf and Clojure branching logic – I wonder if it impacts on equality, too.

Marc O'Morain11:12:00

In my specific case, it turns out that grpc-java creates default values for unspecified message fields using the string constructor, which results in unspecified boolean fields being created with (Boolean/valueOf "false"), which is truthy in some situations in Clojure.


curious if you have an example of where this happens


I remember discussions about this, happening 5-6 years ago but I've since forgotten how the issue manifests


One way you can run into this is via Java serialization. A concrete example is when using Spark and you end up looking at a deserialized Boolean.


Clojure requires that you use the Boolean cached values


Otherwise a Boolean constructed any other way is treated as true, including a boxed false


but doesn't Boolean/valueOf always return the cached value?


IIRC the only issue was with using e.g. (Boolean. "false")


correct, that’s what I’m talking about


maybe Marc really meant Boolean/parseBoolean? dunno


At least some of the issues about boolean constructors are described on the if page here:


In a Clojure 1.10 REPL at least I see (= false (Boolean. false)) return true, which looks reasonable. It is using the (Boolean. false) in an if or cond condition that will bite you.

Marc O'Morain22:12:22

> maybe Marc really meant Boolean/parseBoolean? dunno Yeah, I can’t remember the exact call used to construct the Boolean – I was debugging through trying to find out what was going on, which lead me to the note about if that Andy linked to.


I haven't tried it myself, but as it says on that page, even Java documentation anti-recommends the use of (Boolean. false) values, so if Google's protobuf implementation in Java returns data structures containing such values, it sounds like an enhancement request might be in order.