• Rename preference methods to follow consistent naming conventions
  - isUseCustom() → shouldUseCustom() for DOIPreferences
  - isUseOwner() → shouldUseOwner() for OwnerPreferences
  - isAddImportedEntriesEnabled() → shouldAddImportedEntries() for LibraryPreferences
  - useRemoteServer() → shouldEnableRemoteServer() for RemotePreferences
• Add getDefault() and setAll() methods to preference classes
  - Enables proper reset and import functionality for preferences
  - Implemented for LibraryPreferences, DOIPreferences, OwnerPreferences, TimestampPreferences, and
  RemotePreferences
• Refactor RemotePreferences with clearer naming and parameter reordering
  - Rename port → remoteServerPort, httpPort → httpServerPort
  - Rename useRemoteServer → enableRemoteServer, enableLanguageServer →
  shouldEnableLanguageServer()
  - Reorder constructor parameters for consistency
• Consolidate timestamp cleanup classes into single generic class
  - Merge TimeStampToCreationDate and TimeStampToModificationDate into TimeStampToDateField
  - Reduces code duplication and improves maintainability
• Reorganize preference constants in JabRefCliPreferences with region markers
  - Group related constants by preference type (Library, DOI, Owner, Timestamp, Remote)
  - Rename constants to follow naming pattern (e.g., LIBRARY_*, DOI_*, OWNER_*)

Update RemotePreferences method calls to new naming

jabgui/src/main/java/org/jabref/Launcher.java

Update RemotePreferences and LibraryPreferences method calls

jabgui/src/main/java/org/jabref/gui/JabRefGUI.java

Update LibraryPreferences method call to new naming

jabgui/src/main/java/org/jabref/gui/externalfiles/ImportHandler.java

Description

RemotePreferences changes public constructor and method names (e.g.,
getPort/setPort/useRemoteServer) which breaks any external callers still using the old API.
This is a backward-incompatible change without an explicit compatibility bridge (deprecated
wrappers).

Code

jablib/src/main/java/org/jabref/logic/remote/RemotePreferences.java[R33-47]

+    public RemotePreferences(boolean enableRemoteServer,
+                             int remoteServerPort,
+                             boolean enableHttpServer,
+                             int httpServerPort,
+                             boolean enableLanguageServer,
+                             int languageServerPort,
+                             boolean directHttpImport) {
+        this.enableRemoteServer = new SimpleBooleanProperty(enableRemoteServer);
+        this.remoteServerPort = new SimpleIntegerProperty(remoteServerPort);
this.enableHttpServer = new SimpleBooleanProperty(enableHttpServer);
+        this.httpServerPort = new SimpleIntegerProperty(httpServerPort);
this.enableLanguageServer = new SimpleBooleanProperty(enableLanguageServer);
this.languageServerPort = new SimpleIntegerProperty(languageServerPort);
this.directHttpImport = new SimpleBooleanProperty(directHttpImport);
}

Evidence

PR Compliance ID 2 requires preserving backward compatibility unless explicitly instructed; the diff
shows a public API rename/restructure in RemotePreferences (constructor signature and accessors
renamed to getRemoteServerPort, shouldEnableRemoteServer, etc.), removing the previous
method/field names used by callers.

AGENTS.md
jablib/src/main/java/org/jabref/logic/remote/RemotePreferences.java[22-101]
jabgui/src/main/java/org/jabref/Launcher.java[79-80]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`RemotePreferences` introduces backward-incompatible public API changes by renaming/removing existing methods and changing the public constructor signature.
## Issue Context
Downstream code (including plugins/consumers) may still call legacy methods like `getPort()`, `setPort(int)`, `useRemoteServer()`, etc. Removing these without deprecated delegating wrappers breaks backward compatibility.
## Fix Focus Areas
- jablib/src/main/java/org/jabref/logic/remote/RemotePreferences.java[22-158]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Public preference classes rename/remove established boolean getters (e.g., isUseCustom,
isUseOwner, isOverwriteOwner, isAddImportedEntriesEnabled) which is a breaking change for any
external callers. These should keep deprecated compatibility methods or a migration strategy.

Code

jablib/src/main/java/org/jabref/logic/preferences/DOIPreferences.java[L17-19]

-    public boolean isUseCustom() {
+    private DOIPreferences() {
+        this(
+                false,            // useCustom
+                "https://doi.org" // defaultBaseURI
+        );
+    }
+
+    public static DOIPreferences getDefault() {
+        return new DOIPreferences();
+    }
+
+    public void setAll(DOIPreferences preferences) {
+        this.useCustom.set(preferences.shouldUseCustom());
+        this.defaultBaseURI.set(preferences.getDefaultBaseURI());
+    }
+
+    public boolean shouldUseCustom() {
return useCustom.get();
}

Evidence

PR Compliance ID 2 requires preserving public behavior/APIs; the diff removes/renames public getters
across multiple preference classes (e.g., isUseCustom() -> shouldUseCustom(), isUseOwner() ->
shouldUseOwner(), etc.), which is a direct source-level breaking change.

AGENTS.md
jablib/src/main/java/org/jabref/logic/preferences/DOIPreferences.java[17-35]
jablib/src/main/java/org/jabref/logic/preferences/OwnerPreferences.java[21-67]
jablib/src/main/java/org/jabref/logic/LibraryPreferences.java[68-92]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Multiple preference classes rename/remove existing public getters, breaking existing callers.
## Issue Context
These are public classes in `org.jabref.logic...` and are likely used outside the immediate module.
## Fix Focus Areas
- jablib/src/main/java/org/jabref/logic/LibraryPreferences.java[66-100]
- jablib/src/main/java/org/jabref/logic/preferences/DOIPreferences.java[12-43]
- jablib/src/main/java/org/jabref/logic/preferences/OwnerPreferences.java[35-76]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

TimeStampToDateField.cleanup() checks/parses/clears the *targetField* instead of the legacy
*sourceField*, so timestamp migration usually won’t run (when the target field is absent) and can
act on the wrong field while leaving the legacy timestamp untouched. Additionally, the FieldChange
for the target field captures the “oldValue” after the entry has been mutated, making the change
list incorrect (breaks undo/auditing expectations).

Code

jablib/src/main/java/org/jabref/logic/cleanup/TimeStampToDateField.java[R62-76]

+        if (entry.getField(targetField).isPresent()) {
+            Optional<String> formattedTimeStamp = formatTimeStamp(entry.getField(targetField).get());
   if (formattedTimeStamp.isEmpty()) {
       // In case the timestamp could not be parsed, do nothing to not lose data
       return List.of();
   }
   // Setting the EventSource is necessary to circumvent the update of the modification date during timestamp migration
-            entry.clearField(timeStampField, EntriesEventSource.CLEANUP_TIMESTAMP);
+            entry.clearField(targetField, EntriesEventSource.CLEANUP_TIMESTAMP);
   List<FieldChange> changeList = new ArrayList<>();
   FieldChange changeTo;
   // Add removal of timestamp field
-            changeList.add(new FieldChange(entry, StandardField.TIMESTAMP, formattedTimeStamp.get(), ""));
-            entry.setField(StandardField.CREATIONDATE, formattedTimeStamp.get(), EntriesEventSource.CLEANUP_TIMESTAMP);
-            changeTo = new FieldChange(entry, StandardField.CREATIONDATE, entry.getField(StandardField.CREATIONDATE).orElse(""), formattedTimeStamp.get());
+            changeList.add(new FieldChange(entry, sourceField, formattedTimeStamp.get(), ""));
+            entry.setField(targetField, formattedTimeStamp.get(), EntriesEventSource.CLEANUP_TIMESTAMP);
+            changeTo = new FieldChange(entry, targetField, entry.getField(targetField).orElse(""), formattedTimeStamp.get());
   changeList.add(changeTo);

Evidence

CleanupWorker constructs TimeStampToDateField with (source=timestampPreferences.getTimestampField(),
target=CREATIONDATE/MODIFICATIONDATE), but TimeStampToDateField.cleanup() reads and clears
targetField (so it will skip migration when target is empty, which is the common case). The unit
test expects TIMESTAMP to be migrated into CREATIONDATE, which cannot happen with the current
targetField check. FieldChange’s constructor is (oldValue, newValue), but the code computes the
target field’s “oldValue” after calling setField, so it records the new value as the old one.

jablib/src/main/java/org/jabref/logic/cleanup/TimeStampToDateField.java[59-79]
jablib/src/main/java/org/jabref/logic/cleanup/CleanupWorker.java[80-106]
jablib/src/test/java/org/jabref/logic/cleanup/TimeStampToDateFieldTest.java[22-46]
jablib/src/main/java/org/jabref/model/FieldChange.java[13-25]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`TimeStampToDateField.cleanup()` currently migrates based on `targetField` presence/value and clears `targetField`, but the migration is supposed to read/clear the *legacy timestamp* (`sourceField`) and write into the *date field* (`targetField`). Also, `FieldChange` objects are built with incorrect `oldValue` because the code reads values after mutating the entry.
### Issue Context
`CleanupWorker` passes `(timestampPreferences.getTimestampField(), StandardField.CREATIONDATE/MODIFICATIONDATE)` to `TimeStampToDateField`, so `sourceField` is the legacy timestamp field.
### Fix Focus Areas
- jablib/src/main/java/org/jabref/logic/cleanup/TimeStampToDateField.java[59-80]
- jablib/src/main/java/org/jabref/logic/cleanup/CleanupWorker.java[100-106]
### Implementation notes
- Trigger migration when `entry.getField(sourceField).isPresent()`.
- Parse the value from `sourceField`.
- Capture `String oldSource = entry.getField(sourceField).orElse("")` and `String oldTarget = entry.getField(targetField).orElse("")` **before** modifying the entry.
- Clear `sourceField` (not `targetField`) with `EntriesEventSource.CLEANUP_TIMESTAMP`.
- Set `targetField` with the formatted timestamp.
- Create `FieldChange(sourceField, oldSource, "")` and `FieldChange(targetField, oldTarget, formatted)` using the captured old values.
- Ensure existing unit tests in `TimeStampToDateFieldTest` pass.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

RemotePreferences.shouldEnableHttpServer(boolean) is a setter but is named like a boolean
predicate, which breaks established naming conventions and makes call sites misleading. This harms
readability and maintainability in changed code paths.

Code

jablib/src/main/java/org/jabref/logic/remote/RemotePreferences.java[R111-113]

+    public void shouldEnableHttpServer(boolean enableHttpServer) {
this.enableHttpServer.setValue(enableHttpServer);
}

Evidence

PR Compliance ID 1 requires following existing style/conventions; introducing a setter method named
shouldEnableHttpServer violates common Java/JabRef naming patterns (setters should be set...,
predicates should be should... without parameters).

AGENTS.md
jablib/src/main/java/org/jabref/logic/remote/RemotePreferences.java[111-113]
jabgui/src/main/java/org/jabref/gui/preferences/general/GeneralTabViewModel.java[316-322]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A setter was renamed to `shouldEnableHttpServer(boolean)` which reads like a predicate and is misleading.
## Issue Context
Call sites now read like a query but actually mutate state.
## Fix Focus Areas
- jablib/src/main/java/org/jabref/logic/remote/RemotePreferences.java[103-125]
- jabgui/src/main/java/org/jabref/gui/preferences/general/GeneralTabViewModel.java[314-323]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

formatData.getFirst() was replaced with formatData.get(EXPORTER_NAME_INDEX), moving away from
modern SequencedCollection APIs available in current Java. This reduces clarity and conflicts with
the project’s preference for modern Java idioms.

Code

jablib/src/main/java/org/jabref/logic/preferences/JabRefCliPreferences.java[R1823-1827]

for (String toImport : getSeries(CUSTOM_EXPORT_FORMAT)) {
   List<String> formatData = convertStringToList(toImport);
   TemplateExporter format = new TemplateExporter(
-                    formatData.getFirst(),
+                    formatData.get(EXPORTER_NAME_INDEX),
           formatData.get(EXPORTER_FILENAME_INDEX),

Evidence

PR Compliance ID 5 asks to prefer modern Java best practices; the changed code replaces a modern
getFirst() usage with older index-based access for the first element.

AGENTS.md
jablib/src/main/java/org/jabref/logic/preferences/JabRefCliPreferences.java[1823-1827]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Modern `SequencedCollection` method `getFirst()` was replaced with index-based access.
## Issue Context
This code already uses other sequenced methods (e.g., `addFirst`), so using `getFirst()` is consistent and clearer.
## Fix Focus Areas
- jablib/src/main/java/org/jabref/logic/preferences/JabRefCliPreferences.java[1823-1827]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

storeSettings() contains two identical blocks updating the remote server port,
introducing/retaining unnecessary duplication in modified code. This increases maintenance cost and
risk of inconsistent future edits.

Code

jabgui/src/main/java/org/jabref/gui/preferences/general/GeneralTabViewModel.java[R279-289]

getPortAsInt(remotePortProperty.getValue()).ifPresent(newPort -> {
-            if (remotePreferences.isDifferentPort(newPort)) {
-                remotePreferences.setPort(newPort);
+            if (remotePreferences.isDifferentRemoteServerPort(newPort)) {
+                remotePreferences.setRemoteServerPort(newPort);
   }
});
getPortAsInt(remotePortProperty.getValue()).ifPresent(newPort -> {
-            if (remotePreferences.isDifferentPort(newPort)) {
-                remotePreferences.setPort(newPort);
+            if (remotePreferences.isDifferentRemoteServerPort(newPort)) {
+                remotePreferences.setRemoteServerPort(newPort);
   }
});

Evidence

PR Compliance ID 6 requires avoiding duplication; the changed region includes two consecutive
identical getPortAsInt(remotePortProperty.getValue())...setRemoteServerPort(newPort) blocks.

AGENTS.md
jabgui/src/main/java/org/jabref/gui/preferences/general/GeneralTabViewModel.java[279-289]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
There are two identical remote port update blocks back-to-back.
## Issue Context
This duplication is in the modified area and should be consolidated to a single update.
## Fix Focus Areas
- jabgui/src/main/java/org/jabref/gui/preferences/general/GeneralTabViewModel.java[279-289]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools