shashank created CAMEL-25359:
--------------------------------
Summary: camel-barcode - getWriterHintMap() and getReaderHintMap()
return the live maps, so hints changed through them are lost when the data
format starts
Key: CAMEL-25359
URL: https://issues.apache.org/jira/browse/CAMEL-25359
Project: Camel
Issue Type: Improvement
Components: camel-barcode
Reporter: shashank
{{BarcodeDataFormat.getWriterHintMap()}} and {{getReaderHintMap()}} return the
hint maps the data format encodes and decodes with. Since CAMEL-22354 (4.15)
{{doStart()}} computes the hints again ({{optimizeHints()}} clears both maps
and puts the defaults), and since CAMEL-25303 it applies again the hints added
and removed with {{addToHintMap}} / {{removeFromHintMap}}, which are tracked
separately. A hint put into or removed from the maps returned by the getters
bypasses that tracking, so it is lost: before the start always, after the start
at the next restart of the data format.
In the review of #27344 Claus Ibsen noted
"{{getWriterHintMap()}}/{{getReaderHintMap()}} still return the live maps, so
changes made through them bypass the new tracking and are lost on restart.
Could be a follow-up."
h3. Options considered
* Read-only views ({{Collections.unmodifiableMap}}): a change through the
getters fails with {{UnsupportedOperationException}} instead of being lost; the
documented way to change hints is {{addToHintMap}} / {{removeFromHintMap}} (the
component page only shows {{addToHintMap}}). Small change; code that changes
the maps after start (which worked until the next restart) must switch to the
methods.
* A map view that routes {{put}}/{{remove}}/{{clear}}/iterator removal through
the tracking: no exception, changes survive a restart, but a custom {{Map}}
implementation (entry set, iterator, {{setValue}}) for a rarely used getter.
Usage checked: in Camel (main) the getters are only read, by the camel-barcode
tests; the reifier and the generated configurer set only {{width}}, {{height}},
{{imageType}} and {{barcodeFormat}}. A GitHub code search for both getters
(2026-10-05) finds only copies of Camel; nothing in camel-spring-boot,
camel-quarkus, camel-kamelets, camel-k, camel-karaf or the example
repositories. Property binding cannot fill these maps either: it puts
{{String}} keys, which the {{EnumMap}} rejects with a {{ClassCastException}}.
So the read-only views are proposed.
h3. Reproduction
New {{BarcodeDataFormatTest.testHintMapsAreReadOnly}}: {{put}}, {{remove}} and
{{clear}} on both maps must throw {{UnsupportedOperationException}}; on main
nothing is thrown (two runs). Controls (pass on main):
{{testHintMapsShowLaterChanges}} (the returned maps show hints changed later
with the methods) and {{testHintsChangedAfterStartSurviveARestart}}.
h3. Proposed fix
Return {{Collections.unmodifiableMap}} views from both getters, javadoc
pointing to {{addToHintMap}} / {{removeFromHintMap}}; the component page says
the maps are read-only and mentions {{removeFromHintMap}} (catalog copy
updated). Upgrade guide: a new 4.23 section {{=== camel-barcode - the hint maps
are read-only}}, next to the existing {{=== camel-barcode - text outside
ISO-8859-1}}. Module: 41 tests pass.
Affected: 4.18.x and main (since CAMEL-22354 in 4.15 the hints are computed
again in {{doStart}}). In 4.14.x the maps are computed in the constructors and
in {{setBarcodeFormat}} / {{setBarcodeImageType}}, so a change through the
getters is lost only when one of these setters is called after it. The change
is proposed for main only (behaviour change).
Duplicate check (2026-10-05): JIRA "getWriterHintMap" / "getReaderHintMap":
none; GitHub pull requests: none besides #27344.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
