February 2021 Summaries

The Java programming language has a limitation when it comes to regular expressions, specifically that matching a pattern may require stack space proportional to the length of the input, which can cause the program to crash with a StackOverflowException. To address this issue, SonarCloud has implemented rules to detect and prevent regular expression-related problems, including stack overflows. These rules include java:S5998, which warns about regular expressions that overflow the stack, and java:S6035, which suggests replacing single-character alternations with character classes to avoid similar issues. Possessive quantifiers can be used to avoid catastrophic backtracking and stack consumption, but using them incorrectly can lead to problems. The rules also provide suggestions for fixing these issues, such as enabling the DOTALL flag or removing alternations that can be replaced with character classes.

The author discusses the importance of writing high-quality regular expressions, particularly when it comes to boundary markers and complexity. They highlight the risks of using boundaries incorrectly, which can lead to patterns that don't match anything at all. The author also emphasizes the need for maintainability and simplicity in regular expressions, citing examples of complicated regexes used for matching dates and email addresses. To address this issue, SonarQube offers a rule for finding regular expressions with complexity exceeding a configurable threshold, which can help developers identify and simplify their regex patterns. By following best practices such as breaking down complex regexes into smaller parts and using meaningful variable names, developers can write more accurate and maintainable regular expressions.

^1[3|4|5|7|8][0-9]{9}$` is a mobile phone number matcher that incorrectly uses the character class `[3|4|5|7|8]`, which should be replaced with `[34578]`. The `[^/^ ^;^,]` code has an incorrect use of the negation symbol `^` before each element. In another example, the Apache Camel code `...[\\.|a-z|A-z|0-9]...` incorrectly uses uppercase and lowercase characters in a character range, causing it to match more than intended. A similar bug is found in Elasticsearch's `Pattern.compile("[a-zA-z0-9!#$%&'*+\\-.\\^_`|~]+");`, where the hyphen `-` loses its special meaning inside the character class, allowing it to match a literal `-` instead of a range of characters. In Jenkins' `USERINFO_CHARS_REGEX = "[a-zA-Z0-9%-._~!$&'()*+,;=]"`, the range `%-.;` does not correctly represent the intended set of characters, causing it to only match the character `-`. Additionally, the variable name `safetextRegex` contains an incorrect character class that matches more than intended. The Apache Hadoop code `Pattern.compile("acl[0-31]")` is supposed to match a specific range of acl numbers but incorrectly uses a single digit instead of two. Finally, the Apache Geode code `...[aA-zZ0-9-_.]...` contains an incorrect character class that matches more than intended due to the use of uppercase and lowercase characters in a single range. The Alibaba's Tangram source code incorrectly uses alternation operators outside of a character class, causing it to lose its meaning as quantifiers.

The Server Side Public License (SSPL) was submitted to the Open Source Initiative (OSI), but its adoption by Elastic led to criticism, particularly from those who argued that the license's for-profit origin should be a factor in its evaluation. However, this perspective is flawed, as it prioritizes the company behind the license over the license itself. The OSI should focus on the living nature of licenses and consider factors outside the text, such as dual-licensing plans, developer evangelism, iteration and improvement, lawyer education, pre-OSI public discussion and iteration, adoption from non-author projects, and evaluating other governance components. These considerations would help assess the potential future stewardship of a strong copyleft license and eliminate bad-faith arguments on all sides. The OSI's evaluation process should be more nuanced, taking into account the broader context in which a license is submitted, rather than solely relying on the text itself.