Enum generation ignores existingJavaType

[jhhdk]

When running jsonSchema2Pojo it seems it generates enums regardless of whether I specified to use existingJavaType, that seems a bit odd.
If I wanted to generatePojo's that used an enum i wrote myself, it feels like i should be able to.

[unkish]

Would it be possible to provide some sample schema(s) ?

[jhhdk]

Hi there Here is a sample schema and an example of what I am trying to achieve. Kind regards Jan H. Hansen

…

On Wed, Dec 2, 2020 at 3:32 PM unkish ***@***.***> wrote: Would it be possible to provide some sample schema(s) ? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1182 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARPLQZNRN6R4QPOPUKZMT3SSZFXRANCNFSM4UKMZ7KQ> .

[unkish]

I'm sorry but I don't see any schemas attached 😕

[jhhdk]

First attachment to previous mail was a schema. I am guessing you wanted it attached to issue. I'll do that tomorrow. Sorry for inconvenience.

…

On Wed, Dec 2, 2020, 19:44 unkish ***@***.***> wrote: I'm sorry but I don't see any schemas attached 😕 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1182 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARPLQ7XC7EAB67QBEA4IOTSS2DKVANCNFSM4UKMZ7KQ> .

[jhhdk]

test.zip
Here are the aforementioned files.

[unkish]

If I wanted to generatePojo's that used an enum i wrote myself, it feels like i should be able to.

If enum would be omitted from property definition:

    "properties": {
        "bar": {
            "existingJavaType": "com.examples.types.NonGeneratedBar",
            "type": "string",
            "enum": [
                "BAZ",
                "BAR"
            ]
        }
    }

then generated POJO would be referencing given type eg.:

    "properties": {
        "bar": {
            "existingJavaType": "com.examples.types.NonGeneratedBar"
        }
    }

Considering that the referenced existing java type could be:

1. non enum type, in which case enum definition would be misleading
2. enum but with diferent set of constants or equivalent set of constants with different ordinal values, in which case enum definition would be misleading
3. enum that either could have been generated via same definition in separate file or non-generated having same values, in which case it would be data duplication.

At this point I fail to understand what is the use-case for having both existingJavaType and enum defined in such a way?

[jhhdk]

Let me clarify then. Consider: enum Country { DK("DK", "Denmark", "da-DK", "Danish", "kr."), .... Country(String countryCode, String name, String locale, String language, String currency) { .... } } Enums are classes that can have any number of properties and methods. If I want my enum to have methods that I define, I want to be able to tell jsonschema2Pojo to just let me handle those enums. I still want to use json validation for that enum and i still want other classes to be generated. I am fine with implementing the contract with jsonschema2Pojo by hand. Kind regards Jan H. Hansen

…

On Thu, Dec 3, 2020 at 8:12 PM unkish ***@***.***> wrote: If I wanted to generatePojo's that used an enum i wrote myself, it feels like i should be able to. If enum would be omitted from property definition: "properties": { "bar": { "existingJavaType": "com.examples.types.NonGeneratedBar", "type": "string", "enum": [ "BAZ", "BAR" ] } } then generated POJO would be referencing given type eg.: "properties": { "bar": { "existingJavaType": "com.examples.types.NonGeneratedBar" } } Considering that the referenced existing java type could be: 1. non enum type, in which case enum definition would be misleading 2. enum but with diferent set of constants or equivalent set of constants with different ordinal values, in which case enum definition would be misleading 3. enum that either could have been generated via same definition in separate file or non-generated having same values, in which case it would be data duplication. At this point I fail to understand what is the use-case for having both existingJavaType and enum defined in such a way? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1182 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARPLQYCRH6NJZGQI6AVSWDSS7PJDANCNFSM4UKMZ7KQ> .

[unkish]

Hi

Enums are classes that can have any number of properties and methods.

I do believe that this is only partially correct. Enums are special types which may have any number of properties and methods.

If I want my enum to have methods that I define, I want to be able to tell jsonschema2Pojo to just let me handle those enums

This could be achieved by using existingJavaType (note that it's not accompanied by enum definition) eg:

    "properties": {
        "bar": {
            "existingJavaType": "com.examples.types.NonGeneratedEnum"
        }
    }

I still want to use json validation for that enum and i still want other classes to be generated.

I'm sorry but I don't understand what kind of JSON validation for enum is expected to happen (the only one I could think of is defined by required)

[joelittlejohn]

I think the point here is that you still want to include the enum rule in your schema, because when the schema is used for validation you want the enum values defined and applied. It's good for documentation too, of course.

It should be pretty simple to ignore enum when existingJavaType is defined.

[jhhdk]

Exactly. That is what i expected to happen.

…

On Mon, Dec 7, 2020 at 1:13 PM Joe Littlejohn ***@***.***> wrote: I think the point here is that you still want to include the enum rule in your schema, because when the schema is used for validation you want the enum values defined and applied. It's good for documentation too, of course. It should be pretty simple to ignore enum when existingJavaType is defined. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1182 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AARPLQ72QQYE46UMRK4OWATSTTBHTANCNFSM4UKMZ7KQ> .

[unkish]

Until PR it should be possible to workaround by supplying custom RuleFactory with either getSchemaRule or getEnumRule being overridden such that in case when there are both enum and existingJavaType present latter would take precedence.
Eg. custom EnumRule with:

    @Override
    public JType apply(String nodeName, JsonNode node, JsonNode parent, JClassContainer container, Schema schema) {
        if (node.has("existingJavaType")) {
            return ruleFactory.getTypeRule().apply(nodeName, node, parent, container.getPackage(), schema);
        }
        return super.apply(nodeName, node, parent, container, schema);
    }