JSON schema with enum member with a name starting with a capital letter, causes a generation of a code that doesn't compile

[yurama]

When trying to run jsonschema2pojo on a json schema that has an enum property with a name starting with a capital letter, the generated code doesn't compile.
The compilation error is: non-static variable 'x' cannot be referenced from a static context.

That error occurs because the generated code has a private field with the same name as the enum, that is later accessed by that name from a static code block.

According to RFC 4627 - there is no requirement for member names to start with lower case letters.

For example, for the JSON schema:

{
    "type": "object",
    "properties": {
        "ExampleObj": {
            "type": "object",
            "properties": {
                "TimeFormat": {
                    "enum": [ "12h", "24h" ],
                    "description": "The referred time display format, either 12 or 24 hour clock."
                }
            }
        }       
    }
}

That error occurs because the generated code has a private field with the name TimeFormat:

    @JsonProperty("TimeFormat")
    private ExampleObj.TimeFormat TimeFormat;

and an enum with the same name, that tries to access that field from within a static code block (note the ExampleObj.TimeFormat.values() within the foreach loop):

    @Generated("com.googlecode.jsonschema2pojo")
    public static enum TimeFormat {

        _12_H("12h"),
        _24_H("24h");
        private final String value;
        private static Map constants = new HashMap();

        static {
            for (ExampleObj.TimeFormat c: ExampleObj.TimeFormat.values()) {
                constants.put(c.value, c);
            }
        }
.
.
.

[khitrenovich]

I suggest to append 'Enum' suffix to enum type names. This change should be turned on by configuration switch (off by default), since the generated code will not be backward compatible. I will try to implement this change and check if this goes well.

[yurama]

Another option is not to use the fully qualified enum name when calling the static method values.
For the previous example, it would create the line:

for (ExampleObj.TimeFormat c: values()) {

instead of the line:

for (ExampleObj.TimeFormat c: ExampleObj.TimeFormat.values()) {

[joelittlejohn]

I think this is actually a bug in the naming of the field. Your field should be named timeFormat not TimeFormat. I'm surprised by this but I think there has been a regression here.

So the resulting field should be:

@JsonProperty("TimeFormat")
private ExampleObj.TimeFormat timeFormat;

[khitrenovich]

@joelittlejohn Do you think always lowercasing the first letter of the field name will do the job?

[joelittlejohn]

@khitrenovich yes, I think so. Can you think an scenario in which this might cause problems? I actually think this is a recent bug, I can't quite believe it has always been present but of course I may be wrong.

In simple terms, Java field names should always start with a lower-case letter and Java type names should always start with an upper-case letter. A conflict between the two should be impossible.

[khitrenovich]

@joelittlejohn I fully agree about Java naming convention :)

Yet, I'm not fully confident that there are no marshaling/unmarshalling
packages that rely on field names via reflection (even more, I cannot say
if this is a valid flow or not). However, it is your decision as a
maintainer whether jsonschema2pojo will support such packages if they
exist.

[joelittlejohn]

@khitrenovich yes, I take your point, but I don't see this as too much of a problem. If a JSON binding library can't cope with Java field names being different to JSON names then it simply can't use these types. It's unreasonable to require that the naming is the same, I think. For example, what if your JSON property was called time-format? Clearly a name that cannot be accurately represented as a Java field.

Most data binding libraries allow some kind of annotation (or similar) to indicate the JSON name for a Java field or bean property. jsonschema2pojo generally takes the view that when we need to support a new binding library, we'll do so explicitly by adding a new config option. There's just too much sophistication in the types to expect additional binding libraries to work with no extra effort.

If people really do have simple JSON data that looks a lot like a set of Java beans, they will probably be able to generate types that are a good match. However if your data doesn't map well to Java conventions, then you'll need to choose a binding library that can at the very least map from one name to another.

[khitrenovich]

@joelittlejohn I've implemented a fix in the name normalization code that seems to solve the issue. Please take a look on the changes (c262bb7 - the later commit above).

[joelittlejohn]

Fixed by PR from @khitrenovich.

[khitrenovich]

@joelittlejohn Do you plan to release 0.4.0 soon? If not, any chance to get this fix as 0.3.8 or something?