Spaces in field name causes Exception

[solsticesurfer]

When parsing a json file that has spaces in the field names, the following is thrown: java.lang.IllegalArgumentException: Path not present:. It's then followed by the URL-encoded version of the property name (e.g. "My%20Property"). Unfortunately, I don't have control over the source and design of the payload.

I've scoured through the documentation, issues, and source but haven't found a solution. I thought this might be covered under propertyWordDelimiters but that doesn't seem to be the case.

Ideally, I would like to either remove the space in a property name or replace it with another valid character.

Is this possible or is there a better approach to dealing with this scenario?

[sdegroot]

I have a similar issue with properties that have a question mark in them :) This is since 1.1.2, where it worked at 1.1.1

[joelittlejohn]

There are some characters that need to be escaped because they can the way that JSON Pointer is resolved. The next release (1.2.2) will fix question marks. For the change that was needed, see #1522.

@solsticesurfer What version of jsonschema2pojo are you using? Spaces in the property name should work. If you can provide a minimal snippet of JSON Schema that fails, that would be good.

[unkish]

@joelittlejohn spaces in property names work for JSON Schema but fail with regular json, ie. generating pojo's from following json fails:

{
   "a b": "text"
}

whilst everything is OK with json schema:

{
  "type" : "object",
  "properties" : {
    "a b" : {
      "type" : "string"
    }
  }
}

[solsticesurfer]

@joelittlejohn Appreciate the help and thank you. This is using version 1.2.1 via Gradle. This JSON sample below is enough to reproduce the behavior.

As @unkish pointed out, the conversion fails when calling Json2Pojo.convertJsonToJavaClass() due to the field having a space. Removing the last line in the sample results in the target class being created as expected.

Unfortunately, the schema is not known before processing and is not constant, so using json schema is not an option.

I do see that the field with the underscores is successfully interpreted and that the result has the underscores removed. If we had the ability to specify a substitution rule to use in a case like this, it would resolve the problem.

{
    "fieldA": 123,
    "fieldB": 456,
    "My_Custom_Field": "abcdef",    
    "My Other Field": "abcdef"
}