Problem
Reggie.compile(String pattern) / Reggie.compile(String pattern, ReggieOptions options) have no equivalent to java.util.regex.Pattern.compile(String, int flags) or com.google.re2j.Pattern.compile(String, int flags). ReggieOptions only carries engine-behavior toggles (CAPTURE_NAMED_ONLY, ALLOW_JDK_FALLBACK), not regex-semantics flags.
Callers that build the flags separately from the pattern string — the common Pattern.compile(str, Pattern.CASE_INSENSITIVE) idiom, rather than embedding (?i) inline — have no direct Reggie equivalent today. This came up while cross-checking Reggie against the regex-engine feature surface that dd-trace-java's IAST module actually exercises (currently on RE2J) and logs-backend's grok pipeline (currently on JDK Pattern), as a potential drop-in-replacement gap.
Proposed fix
Add Pattern.CASE_INSENSITIVE / MULTILINE / DOTALL / LITERAL-equivalent flags, either:
- as new
ReggieOption enum values consumed by RegexParser/PatternAnalyzer to prepend the equivalent inline modifier group before parsing, or
- as a dedicated
int flags parameter on a new Reggie.compile(String pattern, int flags) overload mirroring java.util.regex.Pattern's constants for easier drop-in migration.
LITERAL in particular needs care: it must escape the entire pattern into a single literal match rather than parsing it as regex syntax (mirrors Pattern.LITERAL / Pattern.quote() semantics).
Scope note
This is a minor/nice-to-have gap, not a blocker — found during a feature crosscheck, no confirmed consumer currently needs it. Filing to track separately rather than bundling into other work.
Problem
Reggie.compile(String pattern)/Reggie.compile(String pattern, ReggieOptions options)have no equivalent tojava.util.regex.Pattern.compile(String, int flags)orcom.google.re2j.Pattern.compile(String, int flags).ReggieOptionsonly carries engine-behavior toggles (CAPTURE_NAMED_ONLY,ALLOW_JDK_FALLBACK), not regex-semantics flags.Callers that build the flags separately from the pattern string — the common
Pattern.compile(str, Pattern.CASE_INSENSITIVE)idiom, rather than embedding(?i)inline — have no direct Reggie equivalent today. This came up while cross-checking Reggie against the regex-engine feature surface that dd-trace-java's IAST module actually exercises (currently on RE2J) and logs-backend's grok pipeline (currently on JDKPattern), as a potential drop-in-replacement gap.Proposed fix
Add
Pattern.CASE_INSENSITIVE/MULTILINE/DOTALL/LITERAL-equivalent flags, either:ReggieOptionenum values consumed byRegexParser/PatternAnalyzerto prepend the equivalent inline modifier group before parsing, orint flagsparameter on a newReggie.compile(String pattern, int flags)overload mirroringjava.util.regex.Pattern's constants for easier drop-in migration.LITERALin particular needs care: it must escape the entire pattern into a single literal match rather than parsing it as regex syntax (mirrorsPattern.LITERAL/Pattern.quote()semantics).Scope note
This is a minor/nice-to-have gap, not a blocker — found during a feature crosscheck, no confirmed consumer currently needs it. Filing to track separately rather than bundling into other work.