STT_TOSTRING_STORED_IN_FIELD trips on result of String concatenation about fb-contrib

[ThrawnCA]

Also, the detector should not object to storing the String value of java.util.UUID.

[mebigfatguy]

If these are false positives, i'll live with them. I realize that examples are often quite fabricated in nature, but really the first one seems suspect to me. Likely, you'd want that 18n'ed so that would be wrong on that count, but even so, I'd rather the appending be done at the very last second possible (in getMessage). If I can push people to converting objects to strings at the fringes of their application, say in json serializers, jpa converters, etc, etc, i'd be happy fella.

As for the UUID, splitting hairs i suppose, but i'd rather people store the field as a UUID.

[ThrawnCA]

The actual case for the first scenario was setting a status message in an object that would become a Freemarker template's data model. Doing the String formatting at the point of rendering isn't really feasible, since the status message is a generic field (included at the top of all pages) that can contain whatever message the application specifies, and Freemarker isn't really designed for this kind of arbitrary string interpolation (as a template language, it expects the structure to be known in advance).

Performance is not a concern in this context, so if String.format will make the problem go away, it's probably a suitable workaround.

As for UUID, we use it to generate random IDs within Hibernate domain objects (not the actual @Id field). We don't care about them as UUIDs after creation, so it's not really worth having a type converter, and toString looks like the official method for obtaining the value.

[ThrawnCA]

Bump.

Can this be ignored for java.util.UUID, since toString appears to be the canonical way of retrieving the value (https://docs.oracle.com/javase/7/docs/api/java/util/UUID.html)?

[ThrawnCA]

Bump.

What about the possibility of ignoring this rule when the field is annotated as a JPA column?

[mebigfatguy]

wouldn't you normally have @converter s on them?

[ThrawnCA]

We could use a Converter, but as previously mentioned, often we really don't care about the value after creation - we just use java.util.UUID as a way of generating the ID - so constantly converting between String and UUID would be wasted effort for us. I think that if a field is a JPA column, then that is a reasonable excuse to store a String in it.