Optimize saving

[Ali96kz]

#7265 Changed to simpleDateFormatter it doesn't throw a lot of exception

• Change in CHANGELOG.md described in a way that is understandable for the average user (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for UI changes)
• Checked documentation: Is the information available and up to date? If not created an issue at https://github.com/JabRef/user-documentation/issues or, even better, submitted a pull request to the documentation repository.

[Siedlerchr]

Now this is not a good idea, you are effectively switching back to the legacy api 👎
Do the exceptions really matter? They are ignored anyways

[Ali96kz]

@Siedlerchr DateTimeFormatter throw a lot of exception, that's why it leads to OOM. Regex validation is too complicated and will less efficiently than these solution

[Ali96kz]

The same problem is here #6057

[calixtus]

Hi @Ali96kz , first of all, thanks for your interest in JabRef and the issue triangulation. Since you found the most probable source of the issue, we can think about a fix.

Secondly, I have to agree with @Siedlerchr that switching back to the old 1.1 Java DateTime API seems not to be an option (see here: https://www.oracle.com/technical-resources/articles/java/jf14-date-time.html ).
JabRef tries to be both, ready to use in production environment and be an project to teach about open source programming. So returning to a maybe not-to-far-in-the-future deprecated API seems not possible.

The question is, is there any way to avoid the expensive operations or to cache the pattern etc.

[calixtus]

Btw. the tests and checkstyle are failing.

[Ali96kz]

I will investigate possible solutions

[calixtus]

I found some resources to work with the DateTimeFormatter and DateTimeFormatterBuilder, which can probably reduce the cost.
https://www.baeldung.com/java-datetimeformatter

This may be especially interesting:
https://stackoverflow.com/a/45618412

Like something here:

        SIMPLE_DATE_FORMATS = formatStrings.stream()
                                           .map(DateTimeFormatter::ofPattern)
                                           .reduce(new DateTimeFormatterBuilder(),
                                                   DateTimeFormatterBuilder::appendOptional,
                                                   (builder, formatterBuilder) -> builder.append(formatterBuilder.toFormatter()))
                                           .toFormatter(Locale.US);

[...]

        try {
            TemporalAccessor parsedDate = SIMPLE_DATE_FORMATS.parse(dateString, new ParsePosition(0));
            return Optional.of(new Date(parsedDate));
        } catch (DateTimeParseException ignored) {
            return Optional.empty();
        }

Does not yet completely remove the costly stacktrace creation, but provides at least a unified parser for all the patterns.
I read somewhere, that maybe the patters have to be sorted from more complex to simple to provide correct parsing, but I'm not sure if that is the case for the DateTimeFormatterBuilder. That probably would have to be tested.

[calixtus]

Hi @Ali96kz , i took the liberty to push a commit on your branch with a little proposal for a first step towards a solution. You already moved the creation of the patterncompiler out of the parse method, so there should already be an enhancement in speed (even though still a lot of exceptions are probably thrown). However, i hope the new unified DateTimeFormatter, created from the DateTimeFormatterBuilder can enhance the speed a bit more.
The Nullpointer must be thrown, since this is a test convention.

If you don't like my changes, you can always force-push over them.

[Ali96kz]

@calixtus I think it solves our problem because the number of exception should not be too much

[calixtus]

Thanks for your start @Ali96kz end especially for the part about the early creation of patterns. Let's hope that this speeds up the parsing of Dates.