Avoid duplicate "is" prefix for boolean getters

[NiklasvonM]

Boolean property names that start with the prefix "is" currently receive another "is" prefix, generating, for example, the getter isIsValid for the property name "isValid".

This merge request aims to avoid these duplicate prefixes.

[ctrimble]

Hello. I think this needs a feature flag, since it could change output for others. The flag should be clear about what the feature is and it should be disabled by default. We will also need tests showing the old behavior without the feature and the new behavior with the feature active. I am happy to support getting this into the 1.3.0 release.

[NiklasvonM]

Thank you for your comment and support!

Implementing the feature flag and integration tests, I noticed that this new feature may lead to duplicate method names. For example, both properties in the following schema would generate the isValid getter:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "isValid": {
      "type": "boolean"
    },
    "valid": {
      "type": "boolean"
    }
  }
}

Do you have any preferences how to deal with this? I see three options:

• Fall back to the current behaviour if the new one would create conflicting method names.
• Add suffixes similar to MakeUniqueClassName.makeUnique().
• Throw an IllegalArgumentException.

[joelittlejohn]

@NiklasvonM Thanks for sharing this code for others, but I don't think we will merge this PR.

The way that java properties and their accessor methods are named in Java follows strict rules. All Java libraries use these rules to interpret values correctly and it's a very powerful convention. If you have a property called isValid, then the accessor for this is isIsValid. isValid is an accessor for the a property called valid. See also setIsValid. You probably don't have control over this, hence the PR, but a better option would be calling your property 'valid'.

Adding another config option to produce accessors in a way that breaks these standard accessor rules is just not something we want to maintain. As a general rule, this plugin can't support all possible ways of generating Java, as there are so many different preferences and styles out there, so generally I won't merge PRs of this kind.