javaType with generics does not apply correct imports when "type": "object" is omitted

[yveszoundi]

It seems that jsonschema2pojo cannot generate complex classes (Maven plugin) with a mix of Map(generics), Collections(generics).

Issue

I have a moderately complex schema, not that complex though with Collections(generics), Maps(generics), reference to definitions. The schema itself is roughly 200 lines.

The code generation fails when attempting to perform java imports of a property defined as
"aProperty": { "javaType": "java.util.Map<String, Integer>" }. I just get a compilation error.
The maven plugin (stable or git master), generates code with an import ofjava.util.Map<String, Integer> in this case. I'd even be happy if the javaType was take as is, nevermind typing fully qualified class names.

If I check against http://www.jsonschema2pojo.org/ with my full "real" example, code generation seems to work as expected. I'm not referencing any external classes at this time.
The problem is like specific to the Maven plugin, but I could be wrong...

Workaround

It consists into not using generics for collections or maps specified within javaType, just plain "java.util.Map".

Example:

Below is a simple example of what I'm trying to achieve with simplifications.
The real code has about 35 properties, 5 references to definitions, 4 enums, 10 collection types via javatype, 6 hashmaps(generics).

{
    "id": "http://some.site.somewhere/entry-schema#",
    "$schema": "http://json-schema.org/draft-04/schema#",
    "description": "schema for whatever",
    "type": "object",
    "additionalProperties": false,
"definitions": {
        "aDef": {
            "type": "object",
            "additionalProperties": false,
            "properties": {
                "aDefProp": {
                    "javaType": "java.lang.Integer"
                }
            }
        },
  "bDef": {
            "type": "object",
            "additionalProperties": false,
            "properties": {
                "bDefProp": {
                    "javaType": "java.lang.Integer"
                }
            }
        }
    },
    "properties": {
        "aMapAppearsFewTimesWithDifferentNames": {
            "javaType": "java.util.HashMap<String, Integer>"
        },
          "aListAppearsCoupleOfTimesWithDifferentNames": {
            "javaType": "java.util.ArrayList<String>"
        },
        "anotherElementAppearsFewTimesWithDifferentNames": {
            "$ref": "#/definitions/aDef"
        },
      "anotherElementAppearsFewTimesWithDifferentNames": {
            "$ref": "#/definitions/bDef"
        },
"mainlyCoupleofStringsProperties": {
            "type":"string"
        }
    }
}

[joelittlejohn]

@yveszoundi Which version are you using? I could be wrong but I think this is an old bug.

[yveszoundi]

I've tried both 0.4.23 and git HEAD (as of couple days ago).
Not much useful information was produced with the -X maven flag.

The old issue #151 seems related. I think that a good test is a combination of lists and maps with generics as well as couple of random things.

I'll try out couple of other versions, starting from 0.4.17 when I have time.

[ctrimble]

@yveszoundi Have you tried using the fully qualified names of the generic types? For example, java.util.HashMap<java.lang.String, java.lang.Integer>. I could easily see the generator creating imports like import String;, instead of import java.lang.String;, if fully qualified names are not used.

[ctrimble]

One other thought, I usually get this kind of functionality using additionalProperties. It generates an extra type for the field, but gives you type safety, without using javaType. For example:

"aMapAppearsFewTimesWithDifferentNames": {
  "type": "object",
  "additionalProperties": {
    "type": "integer"
  }
}

would produce an additional type for the field and its additionalProperties would be of type java.util.Map<java.lang.String, java.lang.Integer>.

[yveszoundi]

@ctrimble, I did try pretty much what I could (without coding), and that includes most of the things that could cross your mind (Fully qualified names, etc.). The goal was to recommend a contract first approach with jsonschema2pojo (existing and changing REST API).

I didn't have much time to analyze and fix the issue(not really useful Maven Mojo stacktraces).
Making compromises (no generics) was not an option, as well as spending more than 2 hours.

[joelittlejohn]

Will look into this one. It's a regression and I'm surprised by it because we have integration tests that cover this case. Those tests are producing correct, compilable code so there's obviously an edge case here.

[joelittlejohn]

So, it looks like this happens when you specify this:

        "aMapAppearsFewTimesWithDifferentNames": {
            "javaType": "java.util.HashMap<String, Integer>"
        }

instead of this:

        "aMapAppearsFewTimesWithDifferentNames": {
            "type": "object",
            "javaType": "java.util.HashMap<String, Integer>"
        }

In the case of wanting a Java list, you can simply specify:

        "aMapAppearsFewTimesWithDifferentNames": {
            "type": "array",
            "items": {
                "type": "string"
            }
        }

[laxmikanth-demo]

seems this feature broken in 1.0.1 seems instead of javaType need to use existingJavaType . Include Sample below "type": "object", "existingJavaType":"java.util.HashMap<String, String>"

[joelittlejohn]

@laxmikanth-demo in 1.0.0 javaType became existingJavaType