Add getL and getstreamLength methods to GFPDInlineImage#738
Add getL and getstreamLength methods to GFPDInlineImage#738LonelyMidoriya wants to merge 1 commit into
Conversation
📝 WalkthroughWalkthroughChangesInline image stream length
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
update OperatorParser and GFOp_EI for rule 6.1.9-2
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
validation-model/src/main/java/org/verapdf/gf/model/impl/operator/inlineimage/GFOp_EI.java (1)
48-53: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winVerify the public constructor contract before removing the overload.
GFOp_EIis still public, but the current constructor only acceptsLong dataStreamLengthand assigns it tolong, so passingnullwill throw on autounboxing. Rename the parameter tolong, or keep a delegating overload if callers need the older nullable signature.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@validation-model/src/main/java/org/verapdf/gf/model/impl/operator/inlineimage/GFOp_EI.java` around lines 48 - 53, Update the public GFOp_EI constructor contract to use primitive long dataStreamLength if null is not supported, or retain a delegating Long overload when existing callers require nullable input; ensure assignment to the field cannot trigger unintended null unboxing.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@validation-model/src/main/java/org/verapdf/gf/model/factory/operators/OperatorParser.java`:
- Around line 628-636: Update the inline-image handling in OperatorParser so a
getStreamLength() IOException is not converted into the valid value 0. Propagate
the parse failure or pass an explicit unknown length that GFOp_EI and downstream
consumers handle, while preserving normal length metadata on successful reads.
In
`@validation-model/src/main/java/org/verapdf/gf/model/impl/pd/images/GFPDInlineImage.java`:
- Around line 164-171: Restore API alignment for GFPDInlineImage.getL() and
getstreamLength(): use accessor names available on the declared
org.verapdf.pd.images.PDInlineImage dependency and ensure the implemented model
interface declares matching methods. Update the related interfaces,
implementation, and dependency version together as needed; do not merely remove
`@Override` annotations, and preserve the intended inline-image length behavior.
---
Nitpick comments:
In
`@validation-model/src/main/java/org/verapdf/gf/model/impl/operator/inlineimage/GFOp_EI.java`:
- Around line 48-53: Update the public GFOp_EI constructor contract to use
primitive long dataStreamLength if null is not supported, or retain a delegating
Long overload when existing callers require nullable input; ensure assignment to
the field cannot trigger unintended null unboxing.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 6449423a-f008-4617-a4d2-58a9211450ec
📒 Files selected for processing (3)
validation-model/src/main/java/org/verapdf/gf/model/factory/operators/OperatorParser.javavalidation-model/src/main/java/org/verapdf/gf/model/impl/operator/inlineimage/GFOp_EI.javavalidation-model/src/main/java/org/verapdf/gf/model/impl/pd/images/GFPDInlineImage.java
| long streamLength = 0; | ||
| try { | ||
| streamLength = ((ASMemoryInStream) rawOperator.getImageData()).getStreamLength(); | ||
| } catch (IOException e) { | ||
| LOGGER.log(Level.SEVERE, "Error during computing inline image data stream length", e); | ||
| } | ||
| processedOperators.add(new GFOp_BI(new ArrayList<>())); | ||
| processedOperators.add(new GFOp_ID(arguments)); | ||
| processedOperators.add(new GFOp_EI(arguments, resourcesHandler, gs.getFillColorSpace())); | ||
| processedOperators.add(new GFOp_EI(arguments, resourcesHandler, gs.getFillColorSpace(), streamLength)); |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Do not convert a length-read failure into a valid zero length.
When getStreamLength() throws, the parser still creates GFOp_EI with 0, so downstream validation receives concrete but incorrect stream-length metadata. Propagate the parse failure or preserve an explicit “unknown” state handled by consumers; do not silently use zero.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@validation-model/src/main/java/org/verapdf/gf/model/factory/operators/OperatorParser.java`
around lines 628 - 636, Update the inline-image handling in OperatorParser so a
getStreamLength() IOException is not converted into the valid value 0. Propagate
the parse failure or pass an explicit unknown length that GFOp_EI and downstream
consumers handle, while preserving normal length metadata on successful reads.
| @Override | ||
| public Long getL() { | ||
| return ((org.verapdf.pd.images.PDInlineImage) this.simplePDObject).getL(); | ||
| } | ||
|
|
||
| @Override | ||
| public Long getstreamLength() { | ||
| return ((org.verapdf.pd.images.PDInlineImage) this.simplePDObject).getStreamLength(); |
There was a problem hiding this comment.
🎯 Functional Correctness | 🔴 Critical | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
rg -nP --glob '*.java' '\b(getL|getStreamLength|getstreamLength)\s*\(' .
rg -n --glob 'pom.xml' --glob '*.gradle*' 'pdf-model|validation-model' .Repository: veraPDF/veraPDF-validation
Length of output: 1300
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== files =="
git ls-files | rg '(^|/)PDFModel\.java$|(^|/)GFPDInlineImage\.java$'
echo
echo "== PDFModel outline =="
if [ -f src/main/java/org/verapdf/model/impl/pd/PDFModel.java ] || [ -f src/main/java/org/verapdf/model/pdf/PDFModel.java ]; then
ast-grep outline $(git ls-files | rg '(^|/)PDFModel\.java$') --view expanded || true
fi
echo
echo "== PDFModel relevant PDInlineImage section =="
rg -n --glob '*.java' 'interface PDInlineImage|class PDInlineImage|PDInlineImage' . | head -80
echo
echo "== GFPDInlineImage full relevant file =="
cat -n validation-model/src/main/java/org/verapdf/gf/model/impl/pd/images/GFPDInlineImage.java | sed -n '1,240p'
echo
echo "== pom dependency refs =="
cat -n pom.xml | sed -n '1,140p'
cat -n validation-model/pom.xml | sed -n '1,90p'
echo
echo "== current git status/stat =="
git diff --stat HEAD~1..HEAD 2>/dev/null || git status --shortRepository: veraPDF/veraPDF-validation
Length of output: 19723
🌐 Web query:
veraPDF 1.31.0 PDFModel PDInlineImage getL getStreamLength interface methods
💡 Result:
In the veraPDF model (specifically within the org.verapdf.model.pdlayer package), PDInlineImage is a model interface representing inline images, rather than a direct implementation of the Apache PDFBox PDInlineImage class [1][2]. Based on the veraPDF model definition files (.mdl) and API structure, PDInlineImage does not possess methods named getL or getStreamLength [1]. These specific method names do not exist within the veraPDF PDInlineImage interface [1][2]. The veraPDF PDInlineImage interface is designed to map PDF model features for validation purposes [2]. While Apache PDFBox's PDInlineImage class (org.apache.pdfbox.pdmodel.graphics.image.PDInlineImage) provides methods to access image data—such as getData or createInputStream—the veraPDF model abstraction layer for inline images is distinct and primarily focused on exposing properties required for PDF/A validation, rather than providing direct stream manipulation methods like getStreamLength [1][3]. If you are encountering references to getL or getStreamLength, they are likely not standard members of the veraPDF 1.31.0 PDInlineImage interface [1]. You may be confusing the veraPDF model abstraction with the underlying Apache PDFBox library methods or a custom extension [3].
Citations:
- 1: https://github.com/veraPDF/veraPDF-model/blob/integration/src/main/java/PDLayer.mdl
- 2: https://javadoc.io/static/org.verapdf/validation-model/1.18.1/org/verapdf/model/pdlayer/PDObject.html
- 3: https://pdfbox.apache.org/docs/2.0.5/javadocs/org/apache/pdfbox/pdmodel/graphics/image/PDInlineImage.html
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== pdf-model dependency declarations across repository =="
rg -n --glob 'pom.xml' 'artifactId>pdf-model|verapdf\.pdfmodel\.version|groupId>org\.verapdf|artifactId>parser|verapdf\.parser\.version' .
echo
echo "== local maven cache pdf-model files if present =="
find $HOME/.m2/repository/org/verapdf -path '*pdf-model*' 2>/dev/null | sort | tail -50 || true
if [ -d "$HOME/.m2/repository/org/verapdf/pdf-model" ]; then
find "$HOME/.m2/repository/org/verapdf/pdf-model" -maxdepth 4 -type f \( -name 'pdf-model-*.jar' -o -name 'PDInlineImage.java' -o -name '*.mdl' \) | sort
fi
echo
echo "== resolve pdf-model version and search inside jars (if cached) =="
python3 - <<'PY'
import os, json, re
root = os.path.expanduser('~/.m2/repository/org/verapdf/pdf-model')
versions = sorted(os.listdir(root)) if os.path.isdir(root) else []
print(json.dumps({"versions": versions, "count": len(versions)}))
PY
echo
echo "== inspect changed files context =="
git diff -- validation-model/src/main/java/org/verapdf/gf/model/impl/pd/images/GFPDInlineImage.java | sed -n '1,220p'Repository: veraPDF/veraPDF-validation
Length of output: 2885
🌐 Web query:
github veraPDF veraPDF-pdf-model PDInlineImage.java 1.31.0
💡 Result:
As of July 24, 2026, the veraPDF project maintains the veraPDF-model repository, which defines the validation model using a domain-specific language (DSL) [1]. The specific class PDInlineImage.java is not a manually written source file but is generated from the model definition (typically defined in files like PDLayer.mdl) via Xtext [1][2]. Regarding version 1.31.0: - The veraPDF consortium has been working on version 1.31, as evidenced by development release directories (e.g., /dev/1.31) [3]. - Artifacts for version 1.31.1 exist in the developer repository [4], indicating that 1.31.0 was a preceding development or release version in that cycle. - The project documentation and source code are primarily managed through the GitHub organization veraPDF [1][5]. Developers wishing to inspect the generated code or the underlying model DSL can clone the veraPDF-model repository from GitHub and perform a Maven build to generate the source files [1]. Because PDInlineImage.java is a generated artifact, you will not find it directly in the repository's main file tree; instead, you must generate it locally from the DSL definition [1][2].
Citations:
- 1: https://github.com/veraPDF/veraPDF-model
- 2: https://mvnrepository.com/artifact/org.verapdf/pdf-model
- 3: https://software.verapdf.org/dev/1.31
- 4: https://artifactory.openpreservation.org/artifactory/list/vera-dev/org/verapdf/pdf-model/1.31.1/
- 5: https://github.com/veraPDF/veraPDF-library
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== git tags/ref state =="
git rev-parse HEAD
git branch --show-current 2>/dev/null || true
git tag --points-at HEAD 2>/dev/null | sort
git tag | rg '^(v?1\.31|1\.31\.0|1\.31\.1)' | sort | tail -20 || true
echo
echo "== local PDFLayer model definitions =="
find . -type f \( -name 'PDLayer.mdl' -o -path '*/pdf-model/*' -o -path '*/PDFLayer/*' \) | sort | head -100
rg -n --glob '*.mdl' --glob '*.xml' --glob '*.java' 'PDInlineImage|PDXImage' .
echo
echo "== direct URL artifact listing for 1.31.1 artifact =="
python3 - <<'PY'
import urllib.request
url = 'https://artifactory.openpreservation.org/artifactory/vera-dev/org/verapdf/pdf-model/'
for prefix in ['1.31.0/', '1.31.1/', '1.32.0-RC/']:
try:
lines = urllib.request.urlopen(url + prefix, timeout=20).read().decode()
print(f'\n--- {prefix} ---')
for line in lines.splitlines()[:40]:
print(line.rstrip())
except Exception as e:
print(f'\n--- {prefix} --- ERROR: {e}')
PY
echo
echo "== download and inspect pdf-model API for relevant methods if 1.31.1 is available =="
python3 - <<'PY'
import urllib.request, zipfile, io, re
bases = [
'https://artifactory.openpreservation.org/artifactory/vera-dev/org/verapdf/pdf-model/1.31.1/pdf-model-1.31.1.jar',
'https://artifactory.openpreservation.org/artifactory/vera-dev/org/verapdf/parser/1.31.1/parser-1.31.1.jar',
]
for href in bases:
try:
jar_path = '/tmp/' + href.split('/')[-1]
with urllib.request.urlopen(href, timeout=40) as r, open(jar_path, 'wb') as f:
f.write(r.read())
print(f'\n--- {jar_path} ---')
with zipfile.ZipFile(jar_path, 'r') as z:
names = z.namelist()
hits = [n for n in names if re.search(r'(/\b|\.)(PDInlineImage|PDXImage|PDFModel|PDFLayer|parser).*java|/getL|/getStreamLength', n, re.I)]
print('candidate hits:')
for n in hits[:100]:
print(n)
target = 'org/verapdf/model/pdlayer/PDInlineImage.java'
if target in z.namelist():
source = z.read(target).decode()
for line_no, line in enumerate(source.splitlines(), 1):
if re.search(r'getL|getStreamLength|getImage\s?\(|getL(Length)?\s?\(', line):
print(f'{target}:{line_no}: {line}')
except Exception as e:
print(f'ERROR for {href}: {e}')
PYRepository: veraPDF/veraPDF-validation
Length of output: 14092
Restore API alignment before merging.
The current build cannot resolve getL() or getStreamLength() on the underlying PDInlineImage, and both @Override annotations report no matching methods on the implemented interface. Update the corresponding model interfaces/implementation and dependency version together, or use the exact accessors available in the declared API; removing only @Override will not fix the unresolved method calls.
🧰 Tools
🪛 GitHub Check: Checkout and Build (17)
[failure] 171-171:
cannot find symbol
[failure] 169-169:
method does not override or implement a method from a supertype
[failure] 166-166:
cannot find symbol
[failure] 164-164:
method does not override or implement a method from a supertype
[failure] 171-171:
cannot find symbol
[failure] 169-169:
method does not override or implement a method from a supertype
[failure] 166-166:
cannot find symbol
[failure] 164-164:
method does not override or implement a method from a supertype
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@validation-model/src/main/java/org/verapdf/gf/model/impl/pd/images/GFPDInlineImage.java`
around lines 164 - 171, Restore API alignment for GFPDInlineImage.getL() and
getstreamLength(): use accessor names available on the declared
org.verapdf.pd.images.PDInlineImage dependency and ensure the implemented model
interface declares matching methods. Update the related interfaces,
implementation, and dependency version together as needed; do not merely remove
`@Override` annotations, and preserve the intended inline-image length behavior.
Source: Linters/SAST tools
1 participant
update OperatorParser and GFOp_EI for rule 6.1.9-2
Summary by CodeRabbit