Java: Empty MotD fix for JSON #204

ldilley · 2023-11-04T14:51:21Z

Proposed Changes

Adjust MotD strip code to conform to project style.
Fix empty MotD displaying a pair of double quotes when using SLP 1.7 (JSON) (related to Possible runtime error when MotD is empty/null #203).
Increment version from 3.0.5 to 3.0.6.

AppVeyorBot · 2023-11-04T14:51:55Z

✅ Build minestat 1.0.0.378 completed (commit 9080fd204e by @ldilley)

mindsolve

Thank you for the PR, though I do think there is a small problem: The JSON protocol doesn't work at all anymore in the Java variant ;)

First of all, when the "description" field is missing from the server response, the line with setMotd(jobj.get("description") [...]
raises an exception every time, causing the autodetection to fallback to some other protocol.

Secondly, with your change to that same line from .toString() to .getAsString() there are two problems:
1.: The "MOTD" field in the MineStat class is the raw representation of the motd, so either a JSON string, or a string with legacy formatting. The .toString is there explicitly, because it returns the json string for a (maybe nested) Gson object - exactly what we want for the MOTD field.
The double quotes would be perfectly fine and expected, as they form a valid JSON string for "empty string". So both options would be alright: either returning a empty string, or returning doublequotes (JSON representation for empty string).
2.: If the MOTD is not empty, the description field is (very often) an object/array, not a primitive string. So the getAsString call fails with an UnuspportedOperationException, since it is only meant to convert a json primitive string to a Java string.

Best regards,
MindSolve

ldilley · 2023-11-05T16:41:27Z

The JSON protocol doesn't work at all anymore in the Java variant ;)

Hm. It's working below (with and without the MotD set) using SLP 1.7 (JSON) on a 1.8 server. It does not fall back to an earlier SLP version in this case. The protocol does fall back when using more recent versions of Paper (1.19/1.20 for example) however.

First of all, when the "description" field is missing from the server response, the line with setMotd(jobj.get("description") [...] raises an exception every time, causing the autodetection to fallback to some other protocol.

In the case of "vanilla" 1.8 working above, the description field is still present -- it just lacks a text subcomponent (difference below).

{"description":"","players":{"max":20,"online":0},"version":{"name":"1.8","protocol":47}}

{"enforcesSecureChat":false,"description":{"text":""},"players":{"max":20,"online":0},"version":{"name":"Paper 1.19.3","protocol":761}}

Secondly, with your change to that same line from .toString() to .getAsString() there are two problems: 1.: The "MOTD" field in the MineStat class is the raw representation of the motd, so either a JSON string, or a string with legacy formatting. The .toString is there explicitly, because it returns the json string for a (maybe nested) Gson object - exactly what we want for the MOTD field. The double quotes would be perfectly fine and expected, as they form a valid JSON string for "empty string". So both options would be alright: either returning a empty string, or returning doublequotes (JSON representation for empty string). 2.: If the MOTD is not empty, the description field is (very often) an object/array, not a primitive string. So the getAsString call fails with an UnuspportedOperationException, since it is only meant to convert a json primitive string to a Java string.

The intent was to make the Java output functionally equivalent to the PHP and Ruby implementations. The "" appeared in both the non-stripped and stripped MotD fields previously (shown below). In my mind (for at least the stripped field), this should be treated as a plain string. And, in this context, the set of double quotes would be extraneous considering the implication that this field contains a string. It causes confusion/does not seem very intuitive when motd.equals(""), motd.equals("\"\""), or motd.isEmpty() all yield false.

Message of the day: ""
Message of the day without formatting: ""

Given the above information, how would you like to proceed? Do we want to revert to the previous behavior, scrub the double quotes from both fields, or attempt to build a string from text/extra field contents and omit the leading and trailing double quotes in the stripped MotD only?