ppkarwasz commented on code in PR #3789:
URL: https://github.com/apache/logging-log4j2/pull/3789#discussion_r2194345347
##########
log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/DatePatternConverter.java:
##########
@@ -109,84 +109,11 @@ private static String readPattern(@Nullable final
String[] options) {
* @since 2.25.0
*/
static String decodeNamedPattern(final String pattern) {
-
- // If legacy formatters are enabled, we need to produce output aimed
for `FixedDateFormat` and `FastDateFormat`.
- // Otherwise, we need to produce output aimed for `DateTimeFormatter`.
- // In conclusion, we need to check if legacy formatters enabled and
apply following transformations.
- //
- // | Microseconds | Nanoseconds |
Time-zone
- //
------------------------------+--------------+-------------+-----------
- // Legacy formatter directive | nnnnnn | nnnnnnnnn | X, XX,
XXX
- // `DateTimeFormatter` directive | SSSSSS | SSSSSSSSS | x, xx,
xxx
- //
- // Enabling legacy formatters mean that user requests the pattern to
be formatted using deprecated
- // `FixedDateFormat` and `FastDateFormat`.
- // These two have, let's not say _bogus_, but an _interesting_ way of
handling certain pattern directives:
- //
- // - They say they adhere to `SimpleDateFormat` specification, but use
`n` directive.
- // `n` is neither defined by `SimpleDateFormat`, nor
`SimpleDateFormat` supports sub-millisecond precisions.
- // `n` is probably manually introduced by Log4j to support
sub-millisecond precisions.
- //
- // - `n` denotes nano-of-second for `DateTimeFormatter`.
- // In Java 17, `n` and `N` (nano-of-day) always output nanosecond
precision.
- // This is independent of how many times they occur consequently.
- // Yet legacy formatters use repeated `n` to denote sub-milliseconds
precision of certain length.
- // This doesn't work for `DateTimeFormatter`, which needs
- //
- // - `SSSSSS` for 6-digit microsecond precision
- // - `SSSSSSSSS` for 9-digit nanosecond precision
- //
- // - Legacy formatters use `X`, `XX,` and `XXX` to choose between
`+00`, `+0000`, or `+00:00`.
- // This is the correct behaviour for `SimpleDateFormat`.
- // Though `X` in `DateTimeFormatter` produces `Z` for zero-offset.
- // To avoid the `Z` output, one needs to use `x` with
`DateTimeFormatter`.
- final boolean compat =
InstantPatternFormatter.LEGACY_FORMATTERS_ENABLED;
-
- switch (pattern) {
- case "ABSOLUTE":
- return "HH:mm:ss,SSS";
- case "ABSOLUTE_MICROS":
- return "HH:mm:ss," + (compat ? "nnnnnn" : "SSSSSS");
- case "ABSOLUTE_NANOS":
- return "HH:mm:ss," + (compat ? "nnnnnnnnn" : "SSSSSSSSS");
- case "ABSOLUTE_PERIOD":
- return "HH:mm:ss.SSS";
- case "COMPACT":
- return "yyyyMMddHHmmssSSS";
- case "DATE":
- return "dd MMM yyyy HH:mm:ss,SSS";
- case "DATE_PERIOD":
- return "dd MMM yyyy HH:mm:ss.SSS";
- case "DEFAULT":
- return "yyyy-MM-dd HH:mm:ss,SSS";
- case "DEFAULT_MICROS":
- return "yyyy-MM-dd HH:mm:ss," + (compat ? "nnnnnn" : "SSSSSS");
- case "DEFAULT_NANOS":
- return "yyyy-MM-dd HH:mm:ss," + (compat ? "nnnnnnnnn" :
"SSSSSSSSS");
- case "DEFAULT_PERIOD":
- return "yyyy-MM-dd HH:mm:ss.SSS";
- case "ISO8601_BASIC":
- return "yyyyMMdd'T'HHmmss,SSS";
- case "ISO8601_BASIC_PERIOD":
- return "yyyyMMdd'T'HHmmss.SSS";
- case "ISO8601":
- return "yyyy-MM-dd'T'HH:mm:ss,SSS";
- case "ISO8601_OFFSET_DATE_TIME_HH":
- return "yyyy-MM-dd'T'HH:mm:ss,SSS" + (compat ? "X" : "x");
- case "ISO8601_OFFSET_DATE_TIME_HHMM":
- return "yyyy-MM-dd'T'HH:mm:ss,SSS" + (compat ? "XX" : "xx");
- case "ISO8601_OFFSET_DATE_TIME_HHCMM":
- return "yyyy-MM-dd'T'HH:mm:ss,SSS" + (compat ? "XXX" : "xxx");
- case "ISO8601_PERIOD":
- return "yyyy-MM-dd'T'HH:mm:ss.SSS";
- case "ISO8601_PERIOD_MICROS":
- return "yyyy-MM-dd'T'HH:mm:ss." + (compat ? "nnnnnn" :
"SSSSSS");
- case "US_MONTH_DAY_YEAR2_TIME":
- return "dd/MM/yy HH:mm:ss.SSS";
- case "US_MONTH_DAY_YEAR4_TIME":
- return "dd/MM/yyyy HH:mm:ss.SSS";
+ try {
+ return NamedDatePattern.valueOf(pattern).getPattern();
+ } catch (IllegalArgumentException ignored) {
+ return pattern;
}
Review Comment:
Yes — even today, exception handling remains relatively expensive compared
to standard control flow.
To compare both approaches, I wrote a small JMH benchmark. In the more
common case (based on most user questions I’ve seen), where predefined patterns
are **not** used, the exception-based approach incurs a significant performance
penalty due to the cost of creating and handling the exception:
| Benchmark | Mode | Cnt | Score | Error
| Units |
|------------------------------------------|------|-----|----------|---------|--------|
| NamedDatePatternBenchmark.withException | avgt | 25 | 643.222 | ±16.663
| ns/op |
| NamedDatePatternBenchmark.withoutException | avgt | 25 | 42.912 | ±
0.191 | ns/op |
For the smaller group of users who **do** use predefined patterns,
`NameDateFormat.valueOf()` is of course faster, as it uses a map lookup rather
than a linear search:
| Benchmark | Mode | Cnt | Score | Error
| Units |
|------------------------------------------|------|-----|--------|---------|--------|
| NamedDatePatternBenchmark.withException | avgt | 25 | 2.202 | ± 0.299 |
ns/op |
| NamedDatePatternBenchmark.withoutException | avgt | 25 | 46.423 | ±11.093
| ns/op |
It is worth noting, however, that this logic runs only during logging
configuration — typically at startup — so performance here is not critical.
Still, I believe it's good practice to avoid exceptions for control flow when
cleaner alternatives exist.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
