Issues in entry creation workflow with Jabref 5.5

Hi everybody
I noticed a couple of issues in Jabref 5.5 portable (win10/64bit) and I need your help to identify whether these are bugs or expected behavior.

Working scenario: I drag n drop several pdf files (let’s say 5-10) in the user interface in order to import them and automatically create the corresponding entries. But:

  1. Only some of the expected entries are created. Nothing happens for the rest of the files, no warning message appears. Same behavior with Shift F7 and with different group of files. I cannot identify which file forces the entry creation to stop. A workaround is to add files one by one but it takes more time.

  2. No timestamp is created for the created entries. “Add timestamp to new entries (field creationdate)” is ticked. Is this an expected behavior? I think that since an entry is created even by parsing a pdf, it should be timestamped.

  3. When a new entry is created from DOI, the timestamp is successfully created but only with date information (no time info as in previous versions).

  4. Use “Menu>Edit>Manage field names & content” to manually add the timestamps: A timestamp is added to the first entry only and an error message pops up with an exception. If I ignore it and press OK, then a timestamp is added to the next entry and the popup appears again and so on…

  5. In previous Jabref versions we could change “EntryType” for multiple entries at once. In Jabref 5.5, when selecting multiple entries>right click>Change entry type, only the first entry changes.

Sorry for posting multiple issues in a single post. Help appreciated.


Thanks for your feedback. Can you please test the latest development version? We are planning a new release soon and there have been numerous bug fixes already also regarding entry creation.
You can get the version here:

Please remember to make a backup of your library before trying out the new version,


JabRef 5.6–2022-04-04–dbf921e
Windows 10 10.0 amd64
Java 17.0.2
JavaFX 18+12

With regard to issues

  1. Yes, check out the the development version. There have been some bug fixes! In addition to that, keep in mind that metadata imported from pdf is most of the time less reliable than importing from DOI (at least currently), unless you trust the source of the pdf and have attached correct metadata to the pdf before importing it into Jabref. Using drag and drop, Jabref parses pdf metadata using grobid, which is based on machine learning algorithms. Disabling Grobid, or manually importing using File > importyou can also choose to import XMP metadata.

  2. Creation-time IS created. Worked for both bibtex and biblatex library mode. See here:

  3. Please post the error message of the exception.

Thanks Christoph & ThiloteE for your help. I tried the proposed beta. Results:

  1. Seems solved. Entries for all pdfs are created.
    Even if entries miss information, most of the times the DOI field is ok, so then it is easy to proceed specific entries one by one.
    Will also try importing xmp pdf, thanks for this suggestion!

  2. & 3) Indeed “creationdate” field IS generated for new entries. I was confused because I was expecting the “Timestamp” field to be created as in older versions. I did not realize that “creationdate” is a new field.
    Question 1: How to fill “creatιondate” of old library entries with their “Timestamp” value massively? (or vice versa: fill “timestamp” of new entries with the value of “creationdate” field?
    Question 2: How to control the creationdate format? For visual clarity in entry table, personally I prefer “2022.04.07 17:33:45” instead of “2022-04-07T17:33:45”

  3. Error message: Uncaught exception occurred in Thread [JavaFX.Application Thread, 5,Main]

  4. I confirm in 5.5 & 5,6: when selecting multiple entries>right click>Change entry type, only the first entry changes.

  1. Great!

  2. The timestamp field is not an official bibtex or biblatex field. Neither apparently is creationdate (Jabref is trying to follow bibtex and biblatex standards as close as possible wherever it makes sense). I am not aware for the cause of this switch, but I could imagine it has something to do with interoperationally and the ability to import bibliographic data from and export to other programs.

    • Answer to Question 1: Use the find and replace function of a text editor. Make a backup of your library file first, then open your library with a text editor. Notepad++ is one you could use, but there are others around. If you are using that one, go to Search > Replace... (CTRL+H) → Enter into Find: timestamp; Enter into replace: creationdate. Done.
    • Answer to Question 2: Jabref also has a find and replace function. It has the advantage that it can be limited to work only within certain fields. You can use this to replace all the . in the date with -. You might want to do this, because of this and this.
      Also, in theory you could add a space in front of the T by finding T and replacing it with T, but please don’t. Where to find this feature: Within Jabref, go to Edit > Find and replace (CTRL+R); Then limit to creationdate field. Every new creationdate will not have a space though, so I would discourage this method. Furthermore, JabRef will not add a space here, because it follows the standard set in ISO 8601.
  3. Please post the full error message within six accents such as:
    the error message

  4. I don’t know how to change multiple entry types. Maybe we can open an issue at github for this.

  1. Select the entries you want to change. Export these entries to a separate library. Save this library. Open this library with an external editor. Find and replace.

Thanks for your help.
Issues 1,2,3 are considered solved for me after the info/solutions/workarounds proposed.
I cannot reproduce 4 for the moment, I’ll come back if it reappears.
Regarding 5: Exporting in a new library, then find/replace, works indeed but it takes time. If I remember well, in previous versions it was possible to change multiple entry types. If it is a bug, we can open an issue at github. Which is the expected behavior for this?

I added a github issue for 5. here

I don’t think issue 5 is a bug. Adding this feature was probably just forgotten, when the new javaFX ui was implemented.

Glad you seem to have made it work! :slight_smile: