@wing328 really not sure why it is failing. The error indicates that the samples are not updated, but they are 🤔

Edit: nevermind, the /bin structure is unlike the /resources structure, so had so also re-run "spring*" 🤦

Hello @Chrimle, I am not a maintainer, but this change looks sensible to me. I really like that you changed it everywhere even though it might theoretically not cause an issue everywhere, since I expect others can be expected to follow the style going forward when submitting a PR.

As is, I am afraid that someone might unknowingly reintroduce this bug with good intentions. Maybe at least a unit test with api spec testing for the absence of import java.util.Locale and presence of the FQN would make sense? But I understand testing it everywhere would be pretty excessive. But anything is better than nothing in my opinion.

@Picazsoo Correction; Initially ALL imports were replaced by inline:ing. However, on second thought, it was deemed a bit risky, since it would affect non-pojo classes. Hence, it was reverted, and only the mustache-files modified in #21871 , were partially reverted (removing the imports) and the usage of Locales are now fully qualified.

This means, classes pre-7.16.0 that were importing Locale have NOT been modified. Only the mustache files, and the resulting generated pojos, modified in 7.16.0.

Edit: Should the PR title be reworded to better reflect this? Suggestions welcomed

@Chrimle - I kind of understand the intention with limiting the scope of the changes. But where do you see risk with inlining everywhere? I don't think the issues in non-pojo classes would be any different than in POJOs. FQN seems overall much more safe anywhere in generated code as it can nicely coexist with any other instance of user-provided custom Locale schema

@Picazsoo My philosophy was:

• Minimal changes.
• Allow use of custom Locale-classes again.
• Only inline/FQN when absolutely necessary.

This way, the original PR is kept as-was as much as possible, with the only modification being to address NEW issues with custom Locale-classes. My understanding is that the original PR did not cause issues in non-pojo classes. But I could be wrong.

But overall, I would be indifferent to the idea. Would like know if the Tech committee leans towards one or the other.

Ping 🔔
@bbdouglas @sreeshas @jfiala @lukoyanov @cbornet @jeff9finger @karismann @Zomzog @lwlee2608 @martin-mfg

I would expect the same issues in the generated API classes (controllers/interfaces/delegates) when e.g. using a custom user-defined schema called Locale as a request or response body.