Unstable serialization of jabref-entrytype

[koppor]

I use JabRef on two different machines and I have a customized entry type. The last time, I wanted to check in my file, following diff is shown:

-@comment{jabref-entrytype: Collection: req[booktitle;editor;publisher;year] opt[abstract;month;volume;number;series]}
+@comment{jabref-entrytype: Collection: req[booktitle;editor;publisher;year] opt[abstract;month;number;series;volume]}

Note the flipped volume,number,series at the very end.

Is the serialization of entry types unstable? Maybe, it changed from the stable to the development version? The cause might be somewhere in net.sf.jabref.model.entry.CustomEntryType, but it looks good in the master branch at first sight.

[oscargus]

I assume you have noticed that it is now in alphabetical order. Not sure if
that is a coincidence, but may be a clue.

BR Oscar

[lenhard]

I am pretty sure the ordering of the output is done by BibtexEntryWriter. Currently, there are three different styles for ordering the serialization. If your preferences differ between your machines, maybe different styles are selected, resulting in a different output. Did you recently reset preferences?

As things stand, this is no bug or issue, but the design of jabref. I am very much for using only one serialization format and disallowing customizations, which would fix all this. But from what I can tell, customization is desired.

[koppor]

I was only referring to the contents within jabref-entrytype: Collection: opt. I went through the code and couldn't see any change of the ordering of the optional fields. This also cannot be configured, therefore I doubt, it has anything to do with the reset of my preferences (#132).

Did not want to open a general discussion as #116. 😇

[koppor]

I think, it has to do with different java versions: Java(TM) SE Runtime Environment (build 1.8.0_60-b27) seems to order alphabetically, whereas build 1.8.0_51-b16 seems to reverse the last two.

[matthiasgeiger]

What? 😦

[lenhard]

@koppor: can you determine which sorting style you use (which of the writing methods get called in BibtexEntryWriter)?

Sorting is done via calling Collection.sort() with a List<String>. For some fields it is done via putting them in a TreeSet. Regardless of the method, the order should be the same. It is hard to believe that the JVM suddendly sorts Strings from z-a and not from a-z.

See the following code from BibtexEntryWriter:

    private void writeRequiredFieldsFirstOptionalFieldsSecondRemainingFieldsThird(BibtexEntry entry, Writer out) throws IOException {
        // Write header with type and bibtex-key.
        out.write('@' + entry.getType().getName() + '{');

        HashSet<String> writtenFields = new HashSet<>();

        writeKeyField(entry, out);
        writtenFields.add(BibtexEntry.KEY_FIELD);

        // Write required fields first.
        // Thereby, write the title field first.
        boolean hasWritten = writeField(entry, out, "title", false);
        writtenFields.add("title");

        if (entry.getRequiredFields() != null) {
            List<String> requiredFields = getRequiredFieldsSorted(entry);
            for (String value : requiredFields) {
                if (!writtenFields.contains(value)) { // If field appears both in req. and opt. don't repeat.
                    hasWritten = hasWritten | writeField(entry, out, value, hasWritten);
                    writtenFields.add(value);
                }
            }
        }

        // Then optional fields
        if (entry.getOptionalFields() != null) {
            List<String> optionalFields = getOptionalFieldsSorted(entry);
            for (String value : optionalFields) {
                if (!writtenFields.contains(value)) { // If field appears both in req. and opt. don't repeat.
                    hasWritten = hasWritten | writeField(entry, out, value, hasWritten);
                    writtenFields.add(value);
                }
            }
        }

        // Then write remaining fields in alphabetic order.
        TreeSet<String> remainingFields = new TreeSet<>();
        for (String key : entry.getAllFields()) {
            boolean writeIt = write ? BibtexFields.isWriteableField(key) :
                    BibtexFields.isDisplayableField(key);
            if (!writtenFields.contains(key) && writeIt) {
                remainingFields.add(key);
            }
        }

        for (String field : remainingFields) {
            hasWritten = hasWritten | writeField(entry, out, field, hasWritten);
        }

        // Finally, end the entry.
        out.write((hasWritten ? Globals.NEWLINE : "") + '}' + Globals.NEWLINE);
    }

IF it really is a JVM thing, then it is not our fault and we can close this issue! @koppor: Are you really sure?

[koppor]

Just tested and commit small bib.

• https://github.com/JabRef/jabref/blob/master/src/test/resources/testbib/issue_181_1.8.0_51-b16.bib
• https://github.com/JabRef/jabref/blob/master/src/test/resources/testbib/issue_181_1.8.0_60-b27.bib

I don't know whether that's really an issue, because we expect our users to have the latest Java versions installed. Maybe you can try with your machines and check if JabRef modifies your file, too.

I know, that this is not a really MCVE, but close to it 😇. Feel free to strip it down further. The @Collection entry has to be present in the .bib file. Otherwise JabRef just deletes the @comment entry.

I'm using the default sorting style (reset preferences 😄). But I wonder what this could have to do with the entries in the @comment?

[koppor]

With 1.8.0_66 it shows the behavior of 1.8.0_51.

[stefan-kolb]

Is this still relevant?

[koppor]

1.8.0_74 shows the behavior of 1.8.0_60. Thus, it stabilized and the issue can be closed.

Minor remark: The file has been recognized as BibLaTeX even though with the @comment it should have been BibTeX. I had to insert @Comment{jabref-meta: DATABASE_TYPE:BibTeX;} manually and reopen the file in JabRef to be able to investigate that behavior. - Don't know, how to deal with it, but since no one complains, it's also OK for me.

[i2000s]

@koppor I encounters this issue when I open a bibtex file in JabRef v2.7.1, v2.10 and the latest v3.6. The ordering of fields in an entry behaves differently on different versions. That breaks my version control strategy. How to define the ordering of fields?