shortDOI formatter is very slow

[stertooy]

In one of my libraries, which contains approx 100 DOI entries, having the shortDOI field formatter active noticeably slows down the time it takes to save the library.
It takes <1 second to save without said formatter, but 30-40 seconds with, during which JabRef becomes unresponsive. This happens on every save, even when all DOI fields are already in the shortDOI format.

jabref/src/main/java/org/jabref/logic/formatter/bibtexfields/ShortenDOIFormatter.java

Lines 28 to 40 in d6a0e59

	@Override
	public String format(String value) {
	Objects.requireNonNull(value);
	return DOI.parse(value)
	.map(doi -> {
	try {
	return new ShortDOIService().getShortDOI(doi).getDOI();
	} catch (ShortDOIServiceException e) {
	LOGGER.error(e.getMessage(), e);
	return value;
	}
	}).orElse(value);
	}

jabref/src/main/java/org/jabref/logic/importer/util/ShortDOIService.java

Lines 30 to 35 in d6a0e59

	public DOI getShortDOI(DOI doi) throws ShortDOIServiceException {
	JSONObject responseJSON = makeRequest(doi);
	String shortDoi = responseJSON.getString("ShortDOI");
	return new DOI(shortDoi);
	}

If I interpret the above pieces of code correctly, the formatter always makes a request to the shortDOI service, even if the DOI is already shortened. Would it be possible to first check if the DOI is already shortened (i.e. starts with "10/"), and only make a request if it is not?

[Siedlerchr]

Thanks for the report and your analysis. Sounds like a good idea.

Solution: check if the DOI starts with the Pattern 10/[a-z]+ should be sufficient.

For future:
Ideally, the request should be executed in a background thread as well, but this would be a bit more complex from the current architecture and would require some major refactoring.

[michalfarago]

Hello, could I work on this? Thank you.

[stertooy]

Solution: check if the DOI starts with the Pattern 10/[a-z]+ should be sufficient.

Although the shortDOI website says that shortDOI's are "of the form 10/abcde", the "abcde" part often contains numbers as well (e.g. 10/grv3jv). Also taking into account that DOI's are case insensitive, perhaps 10/[a-zA-Z0-9]+ would be better?