Extract references typeset with biblatex standard styles (alphabetic labels)

[koppor]

Summary

Extracting references from a PDF with the rule-based parser now works for bibliographies typeset with the biblatex standard styles, including alphabetic labels such as [AL26]. Before, it found no references at all in such PDFs. Field values like the DOI are kept exactly as printed, which is the basis for reporting faults in a typeset reference list later.

Steps to test

1. ./gradlew :jabkit:installDist
2. jabkit/build/install/jabkit/bin/jabkit pdf extract-references --mode RULE_BASED jablib/src/test/resources/pdfs/biblatex/alphabetic.pdf
3. Eight entries are printed (article, inproceedings, misc) with authors, title, venue, year, pages, DOI, and URL.

Related issues and pull requests

Step towards checking the reference list of a PDF for faults (DOI given as URL, missing DOI, inconsistent fields).

AI usage

Claude Code (model claude-opus-5-5), AIL3.

AI CHECKLIST.md walkthrough

1. Code self-review

Nullability and control flow

• No == null / != null checks — JSpecify annotations (@NullMarked, @Nullable, @NonNull) used instead.
• No Objects.requireNonNull(...) — nullability expressed via JSpecify annotations.
• [/] New classes annotated with @NullMarked (org.jspecify.annotations.NullMarked).
• [/] New packages annotated with @NullMarked (org.jspecify.annotations.NullMarked).
• Optional consumed with ifPresent / ifPresentOrElse / map / orElseThrow — never orElse(unusedValue) nor an isPresent() + get() block.
• [/] StringUtil.isBlank(...) used instead of s == null || s.isBlank().

Exceptions

• No catch (Exception e) — only specific exceptions are caught.
• No throw new RuntimeException(...) / IllegalStateException(...) — these tear down the whole application.
• [/] Logged exceptions are passed as the last logger argument (LOGGER.info("...", e)), not concatenated into the message string.

Style and idioms

• New BibEntry objects built with withers (withField, not setField).
• Modern Java used: List.of() / Map.of() / Set.of(), Path.of(), SequencedCollection / SequencedSet, text blocks.
• Regexes use a precompiled Pattern.compile(...) constant, not String.matches(...).
• Keep alphabetical ordering when adding variables or enum items.
• [/] Background work uses org.jabref.logic.util.BackgroundTask, not new Thread().
• No commented-out code, no trivial comments restating the code, no AI-disclosure comments in source.
• Markdown Javadoc (///) uses Markdown syntax, not JavaDoc inline tags: `code` instead of {@code}, [ClassName] instead of {@link}.

User-facing text

• [/] All user-facing text localized (Localization.lang in Java, % prefix in FXML).
• [/] Sentence case (not Title Case); no trailing !; labels do not end with :.
• [/] Variance expressed with placeholders ("...: %0"), not string concatenation.

Security

• [/] User-controlled data (request params, entry fields, file contents) is HTML-escaped before being written into any text/html response — including exception/error messages, not just the success body (XSS).

Tests

• Behavior changes in org.jabref.model / org.jabref.logic have added or updated tests.
• Tests assert object contents (assertEquals), use plain JUnit asserts (not AssertJ), have no @DisplayName, do not catch exceptions (let them propagate so JUnit reports setup/teardown failures directly), and use @TempDir instead of manual temp directories.
• [/] Fetcher tests hit the live endpoints — the remote API is not mocked or stubbed (automated-review suggestions to mock it are rejected on purpose).

2. Verification commands

• ./gradlew :jablib:check (or ./gradlew check for all modules).
• ./gradlew checkstyleMain checkstyleTest checkstyleJmh.
• ./gradlew modernizer.
• ./gradlew --no-configuration-cache :rewriteDryRun reports no changes (run ./gradlew rewriteRun to fix).
• ./gradlew javadoc.
• npx markdownlint-cli2 "docs/**/*.md" "*.md" (only if Markdown changed).
• npm ci && npm run textlint reports no misspellings (only if Markdown changed).
• Only if formatting is still off after rewriteRun: docker run -v $(pwd):/github/workspace ghcr.io/leventebajczi/intellij-format:master "*.java" "" ".idea/codeStyles/Project.xml".

3. Documentation

• CHANGELOG.md entry added if the change is visible to the user (end-user wording, no extra blank lines, sorted in next to existing entries about the same component/feature). Link the issue if one exists; link the PR only when no issue exists. Use TODO as the placeholder when neither is known yet — never a fake number. No entry for fixes to changes that were themselves introduced after the last release (feature only in ## [Unreleased]) — update the existing unreleased entry instead if needed.
• Searched jabref/issues and jabref-koppor/issues for a related issue; linked only on a confident match, otherwise kept TODO (no closes/fixes for merely-similar issues).
• Requirement added to docs/requirements/<area>.md if the change is a new feature or significant bug fix (skip for refactors, minor fixes, and internal changes).
• [/] Developer documentation under docs/ updated if behavior or architecture changed.

4. Pull request

• PR body built from .github/PULL_REQUEST_TEMPLATE.md, every section filled.
• All checklist items kept and marked [x], [ ], or [/].
• [/] "Steps to test" is a numbered list with a cropped screenshot of the result for every visible change; no video (only allowed when another program is involved, e.g. drag and drop or push to an external application).
• All HTML comments removed from the PR body.
• PR created with gh pr create --body-file <file> (not --body).
• If CHANGELOG.md used a TODO placeholder (no issue confidently identified yet — an existing issue link always stays), the PR was opened as draft, the placeholder was replaced with the real PR-number link after PR creation, committed and pushed, and only then was the PR marked ready for review. If an issue is identified or created later, the link is switched to the issue.

Checklist

• I own the copyright of the code submitted and I license it under the MIT license
• If AI tools were used, I disclosed them in the "AI usage" section and reviewed, understood, and take full ownership of all AI-generated code
• I manually tested my changes in running JabRef (always required)
• I added JUnit tests for changes (if applicable)
• [/] I added screenshots in the PR description (if change is visible to the user)
• I added one sentence (max 20 words) to CHANGELOG.md describing the change from the user's point of view (if the change is visible to the user)
• I checked the user documentation for up to dateness and submitted a pull request to our user documentation repository

🤖 Generated with Claude Code