This should be removed

This isn't sanitization, but coercion from string properties to those declared in CLI options.

I love the idea behind this, but I have quite a few reservations.

I think this is potentially going to become very confusing for folks because additionalProperties is intended for users to be able to pass extra properties to templates. We just happen to also use it for generator's options to be passed to templates as well. What happens for a user who wants to pass a custom property like isSupported: "false"? We now have some properties as boolean and some as string.

It's generally up to generators themselves to determine whether or not a boolean value should be type bool in the template or type string, and this change could potentially break templates which expect string true/false in templates rather than bools. There are about 65 places where this might be affected in code, not counting built-in templates. We may also potentially be breaking some languages where booleans are cased differently (like Python), or even support them being worded differently (yes and no in YAML). In those cases, any sort of check like if ("false".equals(property)) would now fail, and we'd have to be certain our testing covers all of those permutations of options.

I'd much rather fix this specific instance of reactive: false at the source of the problem in SpringCodegen with this code:

        if (additionalProperties.containsKey(REACTIVE)) {
            if (!SPRING_BOOT.equals(library)) {
                throw new IllegalArgumentException("Currently, reactive option is only supported with Spring-boot");
            }
            convertPropertyToBooleanAndWriteBack(REACTIVE);
            this.setReactive((boolean)additionalProperties.get(REACTIVE));
        }

and figure out a way separately for generators to opt-in to automatically coercing CliOpts to their defined types in a way which is appropriate for the target languages.

I love the idea you've used, and maybe we could move it to DefaultCodegen with a coerceAdditionalProperties flag which defaults to false, but when set to true invokes this logic? I guess that would be another potential change I'd feel comfortable with if we set the spring generator to true here. But, I think that would also mean cleaning up all the convertPropertyToBooleanAndWriteBack usages in the Spring generator as well.

Ok, I think I understand the idea, so I move the check to a method in SpringCodegen and AbstractJavaCodegen. The impact on samples is due to the fact I set default values on additionalProperties so now everything is java8 by default.

The idea is that each generator provides his list of properties to check/convert to boolean so custom properties will stay has to String if needed.

Let me know if it's an acceptable solution for you.

@jimschubert I've reworked the solution when I understand that default values can be modified. I know there is a test fail on CI with java8 and maybe CliOption must be reworked to use the "defaultValue" method. But I hope you can confirm I'm on the right way before pushing further.