rspec/rules/S1449/java/rule.adoc

== Why is this an issue?

Failure to specify a locale when calling the methods ``++toLowerCase()++``, ``++toUpperCase()++`` or ``++format()++`` on ``++String++`` objects means the system default encoding will be used, possibly creating problems with international characters or number representations. For instance with the Turkish language, when converting the small letter 'i' to upper case, the result is capital letter 'I' with a dot over it.


Case conversion without a locale may work fine in its "home" environment, but break in ways that are extremely difficult to diagnose for customers who use different encodings. Such bugs can be nearly, if not completely, impossible to reproduce when it's time to fix them. For locale-sensitive strings, the correct locale should always be used, but ``++Locale.ROOT++`` can be used for case-insensitive ones.


=== Noncompliant code example

[source,java]
----
myString.toLowerCase()
----


=== Compliant solution

[source,java]
----
myString.toLowerCase(Locale.TR)
----


== Resources

* https://wiki.sei.cmu.edu/confluence/x/4zdGBQ[CERT, STR02-J.] - Specify an appropriate locale when comparing locale-dependent data

ifdef::env-github,rspecator-view[]

'''
== Implementation Specification
(visible only on this page)

=== Message

Define the locale to be used in this String operation.


'''
== Comments And Links
(visible only on this page)

include::../comments-and-links.adoc[]

endif::env-github,rspecator-view[]
migrate rule descriptions to new education format 2023-05-03 11:06:20 +02:00			`== Why is this an issue?`

Clean rule at root In some cases, the `rule.adoc` at root of a rule is never included anywhere and thus is dead code. It's a maintenance cost by itself, but also it misses opportunities to inline code that seems used by two documents when in fact only one document is actually rendered. And this missed opportunity, in turn, stops us from applying the correct language tag on the code samples. 2023-10-16 16:34:38 +02:00			Failure to specify a locale when calling the methods ``++toLowerCase()++``, ``++toUpperCase()++`` or ``++format()++`` on ``++String++`` objects means the system default encoding will be used, possibly creating problems with international characters or number representations. For instance with the Turkish language, when converting the small letter 'i' to upper case, the result is capital letter 'I' with a dot over it.
RULEAPI-665: Remove security standards from the irrelevant language-specific rules (#362) 2021-09-21 15:40:35 +02:00

Clean rule at root In some cases, the `rule.adoc` at root of a rule is never included anywhere and thus is dead code. It's a maintenance cost by itself, but also it misses opportunities to inline code that seems used by two documents when in fact only one document is actually rendered. And this missed opportunity, in turn, stops us from applying the correct language tag on the code samples. 2023-10-16 16:34:38 +02:00			Case conversion without a locale may work fine in its "home" environment, but break in ways that are extremely difficult to diagnose for customers who use different encodings. Such bugs can be nearly, if not completely, impossible to reproduce when it's time to fix them. For locale-sensitive strings, the correct locale should always be used, but ``++Locale.ROOT++`` can be used for case-insensitive ones.


			`=== Noncompliant code example`

			`[source,java]`
			`----`
			`myString.toLowerCase()`
			`----`


			`=== Compliant solution`

			`[source,java]`
			`----`
			`myString.toLowerCase(Locale.TR)`
			`----`

RULEAPI-665: Remove security standards from the irrelevant language-specific rules (#362) 2021-09-21 15:40:35 +02:00
migrate rule descriptions to new education format 2023-05-03 11:06:20 +02:00			`== Resources`
RULEAPI-665: Remove security standards from the irrelevant language-specific rules (#362) 2021-09-21 15:40:35 +02:00
			`* https://wiki.sei.cmu.edu/confluence/x/4zdGBQ[CERT, STR02-J.] - Specify an appropriate locale when comparing locale-dependent data`
Export comments and rspec-to-rspec links from jira 2021-06-02 20:44:38 +02:00
Fix the comment display: rule-id, timestamp, GH visibility, link direction 2021-06-03 09:05:38 +02:00			`ifdef::env-github,rspecator-view[]`
RULEAPI-666: Migrate the "List of parameters", "Highlighting" and "Message" fields from jira RSPEC (#346) 2021-09-20 15:38:42 +02:00
			`'''`
			`== Implementation Specification`
			`(visible only on this page)`

Inline adoc when include has no additional value (#1940) Inline adoc files when they are included exactly once. Also fix language tags because this inlining gives us better information on what language the code is written in. 2023-05-25 14:18:12 +02:00			`=== Message`

			`Define the locale to be used in this String operation.`

RULEAPI-666: Migrate the "List of parameters", "Highlighting" and "Message" fields from jira RSPEC (#346) 2021-09-20 15:38:42 +02:00
RULEAPI-576: add a horizontal rule between rule description and comments 2021-06-08 15:52:13 +02:00			`'''`
Export comments and rspec-to-rspec links from jira 2021-06-02 20:44:38 +02:00			`== Comments And Links`
			`(visible only on this page)`

			`include::../comments-and-links.adoc[]`
Make sure that includes are always surrounded by empty lines (#2270) When an include is not surrounded by empty lines, its content is inlined on the same line as the adjacent content. That can lead to broken tags and other display issues. This PR fixes all such includes and introduces a validation step that forbids introducing the same problem again. 2023-06-22 10:38:01 +02:00
Fix the comment display: rule-id, timestamp, GH visibility, link direction 2021-06-03 09:05:38 +02:00			`endif::env-github,rspecator-view[]`