Replace Locale constructor by Locale builder (#658 / #662)

[Bukama]

Proposed commit message:

Replace Locale constructor by Locale builder (#658 / #662)

The Locale constructor gets deprecated in newer Java version.
Therefore we replace it by the Locale builder.

closed: #658
PR: #662

linked issue: #658

[Bukama]

Made a new branch/PR with clean base
Difference from last

• Remove PioneerUtils from Democode
• Added PioneerUtils to extension class
• Added test with invalid BCP 47 variant

[Michael1993]

Please fix the build 😇

[Bukama]

Adding merge-ready for full build

[Michael1993]

I think the documentation might need an update to reflect these changes.

[Bukama]

I think the documentation might need an update to reflect these changes.

What do you miss? The examples in DefaultLocaleTimezoneExtensionDemo.java are updated and in the other parts of the documentation I don't see the need for an update.

[beatngu13]

@Bukama Michael is right, I have overlooked this, too. For example:

junit-pioneer/src/main/java/org/junitpioneer/jupiter/DefaultLocale.java

Lines 25 to 33 in 8e9bfe3

	* <p>The {@link java.util.Locale} to set as the default locale can be
	* configured in several ways:</p>
	*
	* <ul>
	* <li>using a {@link java.util.Locale#forLanguageTag(String) language tag}</li>
	* <li>using a {@link java.util.Locale#Locale(String) language}</li>
	* <li>using a {@link java.util.Locale#Locale(String, String) language and a county}</li>
	* <li>using a {@link java.util.Locale#Locale(String, String, String) language, a county, and a variant}</li>
	* </ul>

Here we refer to the deprecated constructors, we no longer use under the hood. It can be seen as an implementation detail, but I believe it is important. Maybe refer to Locale.Builder?

Builder is used to build instances of Locale from values configured by the setters. Unlike the Locale constructors, the Builder checks if a value configured by a setter satisfies the syntax requirements defined by the Locale class. A Locale object created by a Builder is well-formed and can be transformed to a well-formed IETF BCP 47 language tag without losing information.

---

We should also note that once this is merged, main is essentially on 2.0.0-SNAPSHOT. We can longer create a 1.x.y (hotfix) release, at least not with our current pipelines.

[Bukama]

Ah thanks for the hint, with documentation I checked the documentation subpage :D

[Bukama]

Docs updated.

We should also note that once this is merged, main is essentially on 2.0.0-SNAPSHOT. We can longer create a 1.x.y (hotfix) release, at least not with our current pipelines.

This is not a thing of this PR. The changes in this PR are totally fine with the 1.x versions as it's still Java 8. The fact that the extension behaves a little bit different is no argument for a major change. In my eyes it's more a bugfix, as invalid variants are not allowed anymore.

If the want/need a way to create a 1.x release after we have set up main for 2.x one has to create such a Github workflow. But again, this is not part of this issue/PR.

[beatngu13]

This is not a thing of this PR. The changes in this PR are totally fine with the 1.x versions as it's still Java 8. The fact that the extension behaves a little bit different is no argument for a major change. In my eyes it's more a bugfix, as invalid variants are not allowed anymore.

We went down this path with #479 (comment), which gave us #623. 😉 Not sure if we can or want to "sell" this change as a bugfix. Just as we did in our own tests, users may create Locales that are invalid IETF BCP 47 strings. This would be a breaking change for them.

If the want/need a way to create a 1.x release after we have set up main for 2.x one has to create such a Github workflow. But again, this is not part of this issue/PR.

Alternatively, we could also start integrating 2.x changes into a dedicated branch. But yeah, here is indeed the wrong place to discuss this.

[Bukama]

Well it's the same discussion in the linked issues/PR: Is a bug fix, which does not accept past inputs a breaking change and therefor a major release? For me - absolutely not. The only thing I can get in mind is that you rewrite a whole functionality because you can't fix the bug, but then I would not call that a bugfix, but a rewrite of the functionality where the bug was only the point where the stone got rolling.

So what about a mid was? We meet inbetween and call this change worth a minor release?

Nevertheless I add the block label if you decide to still think it's not mergeable before 2.0

[nipafx]

If be7295d gets merged in #651, it needs to be reverted in this PR.