AI chatting functionality

build.gradle

@@ -44,6 +44,7 @@ version = project.findProperty('projVersion') ?: '100.0.0'
 java {
  sourceCompatibility = JavaVersion.VERSION_21
  targetCompatibility = JavaVersion.VERSION_21
+
  // Workaround needed for Eclipse, probably because of https://github.com/gradle/gradle/issues/16922
  // Should be removed as soon as Gradle 7.0.1 is released ( https://github.com/gradle/gradle/issues/16922#issuecomment-828217060 )
  modularity.inferModulePath.set(false)
@@ -96,6 +97,13 @@ application {
 // See also https://github.com/java9-modularity/gradle-modules-plugin/issues/165
 modularity.disableEffectiveArgumentsAdjustment()
 
+// Required as workaround for https://github.com/langchain4j/langchain4j/issues/1066
+modularity.patchModule("langchain4j", "langchain4j-core-0.31.0.jar")
+modularity.patchModule("langchain4j", "langchain4j-embeddings-0.31.0.jar")
+modularity.patchModule("langchain4j", "langchain4j-embeddings-all-minilm-l6-v2-0.31.0.jar")
+modularity.patchModule("langchain4j", "langchain4j-embeddings-all-minilm-l6-v2-q-0.31.0.jar")
+modularity.patchModule("langchain4j", "langchain4j-open-ai-0.31.0.jar")
+
 sourceSets {
  main {
  java {
@@ -230,12 +238,17 @@ dependencies {
  exclude module: 'commons-lang3'
  exclude group: 'org.apache.commons.validator'
  exclude group: 'org.apache.commons.commons-logging'
+ exclude module: 'kotlin-stdlib-jdk8'
+ exclude group: 'com.squareup.retrofit2'
  exclude group: 'org.openjfx'
  exclude group: 'org.apache.logging.log4j'
  exclude group: 'tech.units'
  }
  // Required by gemsfx
  implementation 'tech.units:indriya:2.2'
+ implementation ('com.squareup.retrofit2:retrofit:2.11.0') {
+ exclude group: 'com.squareup.okhttp3'
+ }
 
  implementation 'org.controlsfx:controlsfx:11.2.1'
 
@@ -307,6 +320,23 @@ dependencies {
  // YAML formatting
  implementation 'org.yaml:snakeyaml:2.2'
 
+ // AI
+ implementation 'dev.langchain4j:langchain4j:0.31.0'
+ implementation 'dev.langchain4j:langchain4j-embeddings-all-minilm-l6-v2:0.31.0'
+ implementation 'dev.langchain4j:langchain4j-embeddings-all-minilm-l6-v2-q:0.31.0'
+ implementation('dev.langchain4j:langchain4j-open-ai:0.31.0') {
+ exclude group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib-jdk8'
+ }
+ // openai depends on okhttp, which needs kotlin - see https://github.com/square/okhttp/issues/5299 for details
+ // GemxFX also (transitively) depends on kotlin
+ implementation 'org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.9.24'
+
+ implementation "one.jpro.platform:jpro-mdfx:0.3.3-SNAPSHOT"
+
+ implementation ('com.squareup.okhttp3:okhttp:4.12.0') {
+ exclude group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib-jdk8'
+ }
+
  implementation 'commons-io:commons-io:2.16.1'
 
  testImplementation 'io.github.classgraph:classgraph:4.8.174'
@@ -450,7 +480,22 @@ compileJava {
  // TODO: Remove access to internal api
  addExports = [
  'javafx.controls/com.sun.javafx.scene.control' : 'org.jabref',
- 'org.controlsfx.controls/impl.org.controlsfx.skin' : 'org.jabref'
+ 'org.controlsfx.controls/impl.org.controlsfx.skin' : 'org.jabref',
+
+ 'langchain4j/dev.langchain4j.data.document' : 'org.jabref',
+ 'langchain4j/dev.langchain4j.data.segment' : 'org.jabref',
+ 'langchain4j/dev.langchain4j.model.chat' : 'org.jabref',
+ 'langchain4j/dev.langchain4j.model.embedding' : 'org.jabref',
+ 'langchain4j/dev.langchain4j.model.openai' : 'org.jabref',
+ 'langchain4j/dev.langchain4j.rag.content.retriever' : 'org.jabref',
+ 'langchain4j/dev.langchain4j.store.embedding' : 'org.jabref',
+ 'langchain4j/dev.langchain4j.store.embedding.inmemory' : 'org.jabref',
+ 'langchain4j/dev.langchain4j.memory' : 'org.jabref',
+ 'langchain4j/dev.langchain4j.store.memory.chat' : 'org.jabref',
+ 'langchain4j/dev.langchain4j.data.message' : 'org.jabref',
+ 'langchain4j/dev.langchain4j.store.embedding.filter' : 'org.jabref',
+ 'langchain4j/dev.langchain4j.store.embedding.filter.comparison' : 'org.jabref',
+ 'langchain4j/dev.langchain4j.data.embedding' : 'org.jabref',
  ]
  }
 }
@@ -469,6 +514,9 @@ run {
  'javafx.base/com.sun.javafx.event' : 'org.jabref.merged.module',
  'javafx.controls/com.sun.javafx.scene.control' : 'org.jabref',
 
+ 'langchain4j/dev.langchain4j.model.chat' : 'org.jabref',
+ 'langchain4j/dev.langchain4j.model.chat' : 'org.jabref.merged.module',
+
  // We need to restate the ControlsFX exports, because we get following error otherwise:
  // java.lang.IllegalAccessError:
  // class org.controlsfx.control.textfield.AutoCompletionBinding (in module org.controlsfx.controls)

docs/decisions/0031-store-chats-alongside-database.md

@@ -0,0 +1,61 @@
+---
+nav_order: 0031
+parent: Decision Records
+---
+<!-- markdownlint-disable-next-line MD025 -->
+# Store chats alongside database
+
+## Context and Problem Statement
+
+Chats with AI should be stored somewhere. But where and how?
+
+## Considered Options
+
+* Inside `.bib` file
+* In local user folder
+* Alongside `.bib` file
+
+## Decision Outcome
+
+Chosen option: "Alongside `.bib` file", because
+simple to implement and gives the user the ability to share or not to share the chats.
+
+### Positive Consequences
+
+* Simple implementation
+* The user can send the chats file alongside the `.bib` file if they want to share the chats. If users do not want
+ to share the messages, then they can omit the chats file
+* `.bib` files is kept clean
+
+### Negative Consequences
+
+* User may not expect that a new file will be created alongside their `.bib` (or other LaTeX-related) files
+* It may be not convenient to share both files (`.bib` file and chats file) in order to share chat history.
+* If `.bib` files are edited externally (meaning, not inside the JabRef), then chats file will not be updated correspondingly
+* If user moves `.bib` file, they should move the chats file too
+
+## Pros and Cons of the Options
+
+### Inside `.bib` file
+
+* Good, because we already have a machinery for managing the fields and other information of BIB entries
+* Good, because chats are stored inside one file, and if the `.bib` file is moved, the chat history is preserved
+* Bad, because there may be lots of chats and messages and `.bib` file become too cluttered and too big which slows down the processing of `.bib` file
+* Bad, because if user shares a `.bib` file, they will also share chat messages, but chats are not ideal, so user may not
+ want to share them
+
+### In local user folder
+
+One can use `%APPDATA%`, where JabRef stores the Lucene index and other information.
+See `org.jabref.gui.desktop.os.NativeDesktop#getFulltextIndexBaseDirectory` for use in JabRef and
+<https://github.com/harawata/appdirs> for general information.
+
+* Good, because `.bib` file is kept clean
+* Good, because chat messages are saved locally
+* Neutral, because may be a little harder to implement
+* Bad, because chat messages cannot be easily shared
+* Bad, because when path of a `.bib` file is changed, the chats are lost
+
+### Alongside `.bib` file
+
+Refer to positive and negative consequences of the decision outcome.

docs/decisions/0032-store-chats-in-mvstore.md

@@ -0,0 +1,49 @@
+---
+nav_order: 0032
+parent: Decision Records
+---
+# Store chats in MVStore
+
+## Context and Problem Statement
+
+This is a follow-up to [ADR-031](0031-store-chats-alongside-database.md).
+
+The chats with AI should be saved on exit from JabRef and retrieved on launch. We need to decide the format of
+the serialized messages.
+
+## Decision Drivers
+
+* Easy to implement and maintain
+* Memory-efficient (because JabRef is said to consume much memory)
+
+## Considered Options
+
+* JSON
+* MVStore
+* Custom format
+
+## Decision Outcome
+
+Chosen option: "MVStore", because it is simple and memory-efficient.
+
+## Pros and Cons of the Options
+
+### JSON
+
+* Good, because allows for easy storing and loading of chats
+* Good, because cross-platform
+* Good, because widely used and accepted, so there are lots of libraries for JSON format
+* Good, because it is even possible to reuse the chats file for other purposes
+* Bad, because too verbose (meaning the file size could be much smaller)
+
+### MVStore
+
+* Good, because automatic loading and saving to disk
+* Good, because memory-efficient
+* Bad, because the order of messages need to be "hand-crafted" (e.g., by mapping from an Integer to the concrete message)
+
+### Custom format
+
+* Good, because we have the full control
+* Bad, because involves writing our own language and parser
+* Bad, because we need to implement optimizations found in databases on our own (storing some data in RAM, other on disk)

docs/decisions/0033-use-citation-key-for-grouping-chat-messages.md

@@ -0,0 +1,69 @@
+---
+nav_order: 0033
+parent: Decision Records
+---
+<!-- markdownlint-disable-next-line MD025 -->
+# Use citation key for grouping chat messages
+
+## Context and Problem Statement
+
+Because we store chat messages not inside a BIB entry in `.bib` filecc, the chats file is represented as a map to
+BIB entry and a list of messages. We need to specify the key of this map. Turns out, it is not that easy.
+
+## Decision Drivers
+
+* The key should exist for every BIB entry
+* The key should be unique along other BIB entries in one library file
+* The key should not change at run-time, between launches of JabRef, and should be cross-platform (most important)
+
+## Considered Options
+
+* `BibEntry` Java object
+* `BibEntry` ID
+* Citation key
+* Use `ShareId`
+
+## Decision Outcome
+
+Chosen option: "Citation key", because this is the only choice that complains to the third point in Decision Drivers.
+
+### Positive Consequences
+
+* Easy to implement
+* Cross-platform
+
+### Negative Consequences
+
+* If the citation key is changed externally, then the chats file becomes out-of-sync
+* Additional user interaction in order to make the citation key complain the first and second points of Decision Drivers
+
+## Pros and Cons of the Options
+
+### `BibEntry` Java object
+
+Very bad, because it works only at run-time and is not stable.
+
+### `BibEntry` ID
+
+JabRef stores a unique identifier for each BibEntry.
+This identifier is created on each load of a library (and not stored permanently).
+
+Very bad, for the same reasons as `BibEntry` Java object.
+
+### Citation key
+
+* Good, because it is cross-platform, stable (meaning stays the same across launches of JabRef)
+* Bad, because it is not guaranteed that citation key exists on BIB entry, and that it is unique across other
+BIB entries in the library
+
+### Use `ShareId`
+
+[ADR-0027](0027-synchronization.md) describes the procedure of synchronization of a Bib(La)TeX library with a server.
+Thereby, also local and remote entries need to be kept consistent.
+The solution chosen there is that the **server** creates a UUID for each entry.
+
+This approach cannot be used here, because there is no server running which we can ask for an UUID of an entry.
+
+## More Information
+
+Refer to [issue #160](https://github.com/JabRef/jabref/issues/160) in JabRef main repository

docs/decisions/0034-use-textarea-for-chat-content.md

@@ -0,0 +1,84 @@
+---
+nav_order: 0034
+parent: Decision Records
+---
+<!-- markdownlint-disable-next-line MD025 -->
+# Use TextArea for chat message content
+
+## Context and Problem Statement
+
+This decision record concerns the UI component that is used for rendering the content of chat messages.
+
+## Decision Drivers
+
+* Looks good (renders Markdown)
+* Can select and copy text
+* Have good performance
+
+## Considered Options
+
+* Use TextArea
+* Use a [third-party package](https://github.com/JPro-one/jpro-platform)
+* Use a Markdown parser and convert AST nodes to JavaFX TextFlow elements
+* Use a Markdown parser to convert content into HTML and use a WebView for one message
+* Use a Markdown parser and WebView for the whole chat history
+
+## Decision Outcome
+
+Chosen option: "Use TextArea".
+All other options require some time to implement.
+Some of the options doesn't support text selection and copying,
+which for now we value better than Markdown rendering.
+
+## Pros and Cons of the Options
+
+### Use TextArea
+
+* Good, because it is easy to implement
+* Good, because it supports text selection and copying
+* Bad, because it cannot render Markdown
+* Bad, because default JavaFX's `TextArea` shrinks
+
+### Use a third-party package
+
+There seems to be only one package for JavaFX that provides a ready-to-use UI node for Markdown rendering.
+
+* Good, because it is easy to implement
+* Good, because it renders Markdown
+* Good, because it renders Markdown to JavaFX nodes (does not use a `WebView`)
+* Good, because complex elements from Markdown are supported (tables, code blocks, etc.)
+* Bad, because it has very strange issues and architectural flaws with styling
+* Bad, because it does not support text selection and copying (because of underlying JavaFX `Text` nodes)
+
+### Use a Markdown parser and convert AST nodes to JavaFX TextFlow elements
+
+* Good, because we will support Markdown
+* Good, because no need to write a Markdown parser from scratch
+* Good, because does not use a WebView
+* Good, because easy styling
+* Bad, because we need some time to implement Markdown AST -> JavaFX nodes converter
+* Bad, because rendering tables and code blocks may be hard
+* Bad, because it will not support text selection and copying
+
+### Use a Markdown parser to convert content into HTML and use a WebView for one message
+
+* Good, because there are libraries to convert Markdown to HTML
+* Good, because may be easier to implement than other choices (except `TextArea`)
+* Good, because it supports text selection and copying
+* Bad, because it may be a problem to connect JavaFX CSS to `WebView`
+* Bad, because one `WebView` for one message is resourceful
+
+### Use a Markdown parser and WebView for the whole chat history
+
+* Good, because there are libraries to convert Markdown to HTML
+* Good, because it supports text selection and copying
+* Bad, because it may be a problem to connect JavaFX CSS to `WebView`
+* Bad, because it may be a problem to correctly communicate with Java code and `WebView` to add new messages
+
+## More Information
+
+Actually we used an `ExpandingTextArea` from `GemsFX` package so the content can occupy
+as much space as it needs in the `ScrollPane`.
+
+About the selection and copying, this goes down to fundamental issue from JavaFX.
+`Text` and `Label` cannot be selected by any means.

settings.gradle

@@ -1,5 +1,5 @@
 plugins {
- id("org.gradle.toolchains.foojay-resolver-convention") version "0.8.0"
+  id("org.gradle.toolchains.foojay-resolver-convention") version "0.8.0"
 }
 
 rootProject.name = "JabRef"

src/main/java/module-info.java

@@ -123,6 +123,10 @@
 
  requires org.jooq.jool;
 
+ // AI
+ requires langchain4j;
+ requires kotlin.stdlib;
+
  // fulltext search
  requires org.apache.lucene.core;
  // In case the version is updated, please also adapt SearchFieldConstants#VERSION to the newly used version
@@ -150,4 +154,9 @@
  requires dd.plist;
  requires mslinks;
  requires org.apache.httpcomponents.core5.httpcore5;
+ requires com.dlsc.unitfx;
+ requires org.checkerframework.checker.qual;
+ requires jakarta.validation;
+ requires one.jpro.platform.mdfx;
+ requires scala.library;
 }