Provide some indication to the user that the Java version has been or will be downgraded

[wilkinsona]

There are a few scenarios when the Java version is silently downgraded. For example, when Kotlin is selected as the language, Java 8 will always be used. Another example in the future will be when Java 13 is offered. Gradle won't support Java 13 until 6.0 so a downgrade may be necessary in the interim.

The silent downgrade has caused some confusion in the past and continues to do so. See spring-io/initializr#739, for example. We should consider making the downgrade clearer to the user. One solution was originally being tracked in spring-io/initializr#773 until it was repurposed.

There are two mains approaches that have been thought of thus far:

1. Update the UI to prevent combinations that would result in a downgrade
2. Add a note in the HELP.md file that explains what has happened and why

We may even need a hybrid of the two as the first solution won't help for projects generated using a client other than the web UI.

[snicoll]

Blocked on spring-io/initializr#1005 (and having spring-io/initializr#1006 would be useful).

[snicoll]

@wilkinsona I've added a basic note but I can't say for sure what the reason was for the downgrade at the moment as the two things are completely separate. This makes me question if we shouldn't structure things a little bit differently. If the thing that does the action could also add a note, we would have full context when adding it. There might be other side effects though.

[wilkinsona]

Thanks.

If the thing that does the action could also add a note, we would have full context when adding it.

I like the sound of that.

[snicoll]

We discussed this some more. The problem with making that step more smart is that it would require ProjectDescriptionCustomizer to know about HelpDocument. Not only this is a totally separate concept (and should probably remain that way) but customizers are invoked before the ProjectGenerationContext is refreshed.

What we need is a signal that a property of the description was changed and why it was changed. If we had such (independent) information, A HelpDocumentCustomizer could then inject that and generate the appropriate warnings. This would certainly revisit the current diff arrangement we have at the moment.