Increase saving speed about jabref

[koppor]

One caller modifying the array is net.sf.jabref.logic.bibtex.BibtexEntryWriter.writeNewStyle(BibtexEntry, Writer). Possibly a cache of the sorted fields would help.

[lenhard]

I had a look in this problem and the only place where the arrays are modified are the positions you mentioned above. Hence it is "save" to remove the call to clone and to introduce a cache. This is done in 8b2821d

@koppor: I do not have such a large bibtex file. Can you please check if the change really has an impact on saving speed?

However, I really don't like the change. The underlying problem is that someone is trying to modify the optionalFields / requiredFields, which should not be possible (and has already caused bugs). How about changing the return types of these methods from String[] to List<String> and having the methods return an unmodifiable reference to the internal list via Collections.unmodifiableList(). This should not punish performance too much, since it is not a copy, but just an unmodifiable view on the internal list. The benefit is that if someone tries to modify the list, she will get an exception at runtime. Changing the return type triggers changes at several positions in the code, but the changes are fairly simple, i.e., just a conversion from array to list. Opinions on that?

[lenhard]

Related: #123

[koppor]

👍 for List<String>. "Item 25: Prefer lists to arrays" of Effective Java, even though our setting is different from the one described there.

[koppor]

A quick check showed that it increases the saving speed. Additional tests, maybe with artificially generated bibtex files might be required.