jabref VS JRuby

JabRef might work for you. Website link and GitHub link.

This issue https://github.com/JabRef/jabref/issues/5867 hints at JavaFX issue with the potential workaround of running with the environment variable GDK_DISPLAY=1.

I use JabRef for managing references, which allows you to generate entries via a DOI and saves to a local .bib file.

JabRef

If the town is "online reference managers," you are probably right, but I would argue that reference managers are one of those areas where you really want something offline:

- Offline ensures that you do not suffer an externally caused downtime just before a deadline

- Offline ensures that you have a path for keeping your database throughout your research career, and to do system updates when _you_ want to.

- Offline ensures that if you leave academia, you will always have access to local copies of the academic papers you have referenced.

My favorite offline/local reference manager is `jabRef` [0] which stores all metadata directly in a bibtex-file. The GUI has an excellent pdf-integration, and everything is local and super fast.

Case in point: after a decade in industry, I am looking to get back into my academic fief. All the papers I ever read are in my Dropbox, and all I had to do to pick up where I left was download a current version jabRef and point it to my database which it read without any issues.

[0]: https://www.jabref.org/

I used JabRef throughout my work. It's indeed too late for my PhD work, but Zotero does indeed look very nice.

As someone who has looked at Shoes several times but never dove in, it's confusing how Shoes 4 has been the "preview version" of Shoes for, like, a decade or more. It made me actively avoid getting invested in Shoes 3 (the release promoted on the linked website) because Shoes 4 requires JRuby and I am happy with CRuby (the Ruby interpreter most people think of when they hear "Ruby").

https://github.com/shoes/shoes4/

http://www.rubydoc.info/github/shoes/shoes4

No disrespect to the developers but to me it feels like taking over a GUI toolkit created "to teach programming to everyone" (to quote the Shoes 4 readme) and making it depend upon a super-complicated enterprise-focused Ruby was sort of Missing The Point™ in a huge way.

Heck I couldn't even switch to JRuby if I wanted to because I <3 Ractors and JRuby still lacks CRuby 3.0 feature parity: https://github.com/jruby/jruby/issues/7459

__callee__ now properly returns the name under which a method was called, which will be the new name in the case of aliased methods. #2305, #7702

Issue tracker: https://github.com/jruby/jruby/issues

rdoc has been updated to 6.3.3 to fix all known CVEs. (#7396, #7404)

Altering the visibility of an included module method no longer changes what super method gets called. (#7240, #7343, #7344, #7356)

It looks like the readme is copy pasta from jruby: https://github.com/jruby/jruby

Homepage: https://www.jruby.org/

Chris: Yeah, that's exactly right. So I was working at Sun at the time. I remember the JRuby guys. I saw them speak at one of the Java conferences, and they came to work for Sun. Just listening to them talk about JRuby...and then a lot of it was obviously about Ruby on Rails at the time. And I was like, wow, this was just mind-blowing the way they talked about it.

In fact, I built its GUI twice with two different approaches, one using the up and coming Glimmer DSL for LibUI on CRuby relying on a multi-canvas-grid (LibUI area) approach, and one using the very mature Glimmer DSL for SWT on JRuby by relying on a button-grid approach.