[WIP] Integrate journal abbreviations into JabRef

[lenhard]

Meetings are good for easy programming tasks...

This takes care of parts of #919. It takes the existing built-in journal lists and transforms them from text files into source code. We've found the abbreviation loading to be a performance problem. This should reduce this problem a little, because we replace file parsing with class loading and the reading of the lists can be optimized by the compiler. Changes are completely internal to the abbreviation code.

This doesn't check the lists for consistency, the other parts of #919. It just takes the existing lists and turn them into source code.

This doesn't need to be merged into 4.0, but can be included later.

EDIT: Turns out our built-in list has 15195. This is too large for a Java class and I am getting the error Error:(8, 45) java: code too large on compilation. So we need to think about this. We can leave the built-in list as a text file (no performance improvement) or distribute it into multiple source code files (seems rather brittle).

• Change in CHANGELOG.md described
• Tests created for changes
• Screenshots added (for bigger UI changes)
• Manually tested changed features in running JabRef
• Check documentation status (Issue created for outdated help page at help.jabref.org?)
• If you changed the localization: Did you run gradle localizationUpdate?

[koppor]

In case we want to keep the Java-class, I would add a transformation transforming the list into Java-Classes. End users are maintaining the abbreviation lists (https://github.com/JabRef/abbrv.jabref.org/pulls?q=is%3Apr+is%3Aclosed) and I assume, they do not want to maintain Java-Code.

Does loading of the lists still take that much time? Maybe we should ship SQLite?

[lenhard]

But those are different lists, right? This PR was just about the integration of the built-in lists. For the gigantic list, there's no clean way to convert this into code, so we might have to load it anyway. The IEEE lists could go into code, but they probably don't matter performance-wise anyway.

I am not even sure if this PR is worth following up.

[koppor]

Yes, these are different lists - and this also confuses users of JabRef. Why is there https://github.com/JabRef/jabref/blob/master/src/main/resources/journals/journalList.txt and http://abbrv.jabref.org/.

Current state: On http://abbrv.jabref.org/ at the end, the internal list is linked somehow...

I would not follow up here, but possible follow up in the same context:

A) support three kinds of modes: full, abbreviated, shortest unique abbreviation
B) add support for abbreviating conference names.

[Siedlerchr]

What about storing them as Properties file? That would be actual equivalent of storing it into code
This was suggested here: https://stackoverflow.com/a/2407930
And here is an analysis of Performance: https://stackoverflow.com/a/10756739

[lenhard]

@Siedlerchr This sounds like a good suggestion.