Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unstable serialization of jabref-entrytype #181

Closed
koppor opened this issue Sep 25, 2015 · 11 comments
Closed

Unstable serialization of jabref-entrytype #181

koppor opened this issue Sep 25, 2015 · 11 comments

Comments

@koppor
Copy link
Member

koppor commented Sep 25, 2015

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
Copy link
Contributor

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
Copy link
Member

lenhard commented Sep 25, 2015

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
Copy link
Member Author

koppor commented Sep 25, 2015

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
Copy link
Member Author

koppor commented Oct 6, 2015

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
Copy link
Member

What? 😦

@lenhard
Copy link
Member

lenhard commented Oct 7, 2015

@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
Copy link
Member Author

koppor commented Oct 11, 2015

Just tested and commit small 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
Copy link
Member Author

koppor commented Nov 24, 2015

With 1.8.0_66 it shows the behavior of 1.8.0_51.

@stefan-kolb
Copy link
Member

Is this still relevant?

@koppor
Copy link
Member Author

koppor commented Mar 13, 2016

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.

@koppor koppor closed this as completed Mar 13, 2016
@i2000s
Copy link

i2000s commented Sep 29, 2016

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants