PR for using `@JsonApplyView` (#5745) by f-aubert · Pull Request #5754 · FasterXML/jackson-databind

f-aubert · 2026-03-10T19:37:29Z

As discussed, here a Draft PR for #5745.

… and objectIdGenerators

cowtowncoder · 2026-03-11T21:29:48Z

+     * @return view (represented by class) that the property will be processed with;
+     *    if null, processing will use the current view if any
+     */
+    public Class<?> findApplyView(MapperConfig<?> config, Annotated a) { return null; }


Should the translation of "no view" be handled here?

(if so, marker effectively means "no override", same as no annotation -- except that allows for mix-ins and sub-classes to override and disable @JsonApplyView of target/base class).

f-aubert · 2026-03-12T11:20:05Z

@cowtowncoder thanks for supporting and helping me. You suggested the implementation shall go another direction with a caching of BeanWriterProperty and not cloning SerializationContext/SerializationConfig although it always check first if active view has changed or not and avoid unnecessary cloning (minimal performance impact?). Shall I attempt to find out where else we can do that, or do you have something specific in mind?
On an administrative note, shall we commit further on this PR or shall we start from a clean state with another branch and PR? Maybe you could create a branch on your side with TODOs and placeholders and I will fork and fill them in. I'm not very expert in github / prs and so on.
Have a good day

…PropertyWriter)

f-aubert · 2026-03-13T10:24:37Z

@cowtowncoder in the meanwhile I reworked the handling in BeanWriterProperty to read the annotation just once. Maybe it's enough so, as the SerializationContext creation happens only when needed and is ultimately just a copy by reference of the properties. If you still wish to make the activeView accessible, save it before and restore it after the property it should be quite easy as well. But then you possibly have an activeView not matching its config...

f-aubert · 2026-03-15T15:47:35Z

@cowtowncoder would you prefer another cleaner push request to be able to merge it easily?

f-aubert · 2026-03-29T08:50:24Z

@cowtowncoder is this implementation fine enough or would you prefer to mutate the context instead.

cowtowncoder · 2026-03-30T22:02:27Z

Ok, sorry, so no, not good as-is -- I don't think new SerializationConfig or -Context instances should be created on the fly.

Instead, active view in SerializationContext:

final protected Class<?> _activeView;

needs to be changed mutable. Method could then be added, something like

    void withView(Class<?> newActiveView, /* or whatever callback interface */ Runnable callback) {
        Class<?> oldView = _activeView;
        _activeView = newActiveView;
        try {
            callback.run();
        } finally {
            _activeView = oldView;
        }
    }

which would switch view around call.

As to this or new PR, no Strong opinion, either way fine with me.

During PR could also temporarily add new annotation in databind package to make code compile & CI run.

f-aubert · 2026-04-15T21:22:54Z

@cowtowncoder I managed to revert the cloning of Context and Config and just modify the activeView in BeanPropertyWriter. Can you review my change? And possibly move forward with this PR? Thanks

cowtowncoder · 2026-04-17T23:44:12Z

    protected final Class<?>[] _includeInViews;

+    /**
+     * Alternate set of property writers used when applyView is


Copy-pasted?

Yes, I suggest the following:
/**
* View to apply for this property when applyView is available for the Bean.
*
* @SInCE 3.2
*/

cowtowncoder · 2026-04-17T23:47:35Z

+
+        Class<?> currentActiveView = ctxt.getActiveView();
+        try {
+            ctxt.setActiveView(getAppliedView(ctxt));


This now adds overhead for every write call on hot path.
Not good. Should check if _applyView is null, if so, fast patch with no changes; if not null, then handle active view.

I did it as asked. Please review again

f-aubert · 2026-04-18T16:47:01Z

@cowtowncoder here the corrections.

f-aubert · 2026-04-21T20:34:07Z

@cowtowncoder did you get the cla? And does the change suits you? Thks

f-aubert · 2026-04-29T20:22:10Z

@cowtowncoder I added some more test (or more precisely more complete tests) combining applying another view, suppressing view, and nesting beans. Any other idea of what we shall test? Once again thanks for your involvement and looking forward to 3.2.0

github-actions · 2026-04-30T21:29:30Z

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	81.60%	📈 +0.000%
Branches	74.93%	📈 +0.000%

Coverage data generated from JaCoCo test results

github-actions · 2026-05-01T23:12:55Z

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	81.59%	📈 +0.000%
Branches	74.93%	📈 +0.020%

Coverage data generated from JaCoCo test results

github-actions · 2026-05-01T23:13:20Z

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	81.60%	📈 +0.010%
Branches	74.93%	📈 +0.020%

Coverage data generated from JaCoCo test results

cowtowncoder · 2026-05-01T23:14:45Z

+        public Bean beanWithApplyViewB = new Bean();
+
+        @JsonView(ViewA.class)
+        @JsonApplyView


Hmmmh. Should we actually allow this at all -- or require explicit use of NONE.class?

Looking at this case it is not obvious to me that plain @JsonApplyView means "disable View altogether". I would prefer that it'd need to be explicit like:

@JsonApplyView(NONE.class)

or -- perhaps -- either:

Keep one constant but rename as NO_VIEW

Keep NONE as default but mean "@JsonApplyView that does nothing", add NO_VIEW or DISABLE_VIEW to mean setting Active View to null (so no View processing).

cowtowncoder · 2026-05-01T23:20:45Z

+        Bean2 bean2 = new Bean2();
+
+        StringWriter sw = new StringWriter();
+        MAPPER.writerWithView(ViewA.class).writeValue(sw, bean2);


nit: could just use writeValueAsString() instead of StringWriter.

cowtowncoder · 2026-05-01T23:29:15Z

@cowtowncoder I added some more test (or more precisely more complete tests) combining applying another view, suppressing view, and nesting beans. Any other idea of what we shall test? Once again thanks for your involvement and looking forward to 3.2.0

Good stuff! I think test coverage may be ok now.

But one thing I realized -- and commented about -- was whether use of default value for @JsonApplyView (and naming of NONE) is a good idea wrt readability.
So maybe:

Should not define any default and
should rename NONE as NO_VIEW (or something)?

alternatively if we wanted to allow @JsonApplyView as no-op (do nothing), would have 2 constants, but I am not sure there is much point doing that.

Aside from this one last concern I think we are done.

f-aubert · 2026-05-02T20:13:36Z

I also see three options

as it
not defaulting to NONE/NO_VIEW but to ACTIVE/CURRENT/NO_OP
another annotation JsonSuppressView or JsonApplyNoView

As for me I could live with any of the three. The NoOp does not seem necessary to me because semantically you want to apply a view or suppress a view for a given property and just documenting the special value should be enough. So the current implementation. But if we go with 2) then for the sake of completeness we should add the active special value anyway. The last option would obviously be more explicit but what if both annotation are used on the same property. Not to mention it add some more work.

cowtowncoder · 2026-05-04T01:33:43Z

I also see three options

as it is

not defaulting to NONE/NO_VIEW but to ACTIVE/CURRENT/NO_OP

another annotation JsonSuppressView or JsonApplyNoView

As for me I could live with any of the three. The NoOp does not seem necessary to me because > semantically you want to apply a view or suppress a view for a given property and just
documenting the special value should be enough. So the current implementation. But if we go
with 2) then for the sake of completeness we should add the active special value anyway. The
last option would obviously be more explicit but what if both annotation are used on the same > property. Not to mention it add some more work.

I don't think what you list cover same cases as mine do.

Now: for me separate annotation seems like unnecessary, so no for option 3.

But wrt "no-op", to me the only use would be as mix-in override to "disable" @JsonApplyView on class, with a mix-in. And that is probably not a common use case, can defer to see if needed.

What I mean by NO_VIEW is different tho: that means setting Active View to null.
Whereas I think ACTIVE/CURRENT would mean "use whatever is already Active View (do not change).

cowtowncoder · 2026-05-04T01:35:41Z

Ok, so I do want to prevent use of plain

 @JsonApplyView

without argument. And question then is whether constant NONE is good -- for semantics of "set Active View to null" (disable View processing).
Maybe it is? If so, just removing default NONE.class is all that is needed.

cowtowncoder · 2026-05-04T18:10:57Z

Made change via FasterXML/jackson-annotations#347 (with minor Javadoc changes).

f-aubert · 2026-05-04T19:54:56Z

@cowtowncoder I think it makes perfectly sense to just drop the default forcing usage of the special value class to force the view to NULL. I wanted to thank you for actively contributing and supporting this feature and PR. I'm still amazed by your work and contribution in this great library. Looking forward to using the release candidate 3.2.0 ;)

github-actions · 2026-05-04T20:24:41Z

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	81.60%	📈 +0.010%
Branches	74.93%	📈 +0.020%

Coverage data generated from JaCoCo test results

github-actions · 2026-05-04T20:37:28Z

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	81.60%	📈 +0.010%
Branches	74.92%	📈 +0.010%

Coverage data generated from JaCoCo test results

github-actions · 2026-05-04T20:47:37Z

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	81.60%	📈 +0.010%
Branches	74.92%	📈 +0.010%

Coverage data generated from JaCoCo test results

cowtowncoder · 2026-05-04T20:48:59Z

@f-aubert Finally found time to finish up merging. Phew!

Thank you for all your work here: should be good for 3.2.0.

And maybe add deserialization support, probably for 3.3 (I am planning to finalize 3.2.0 this or next week).

f-aubert · 2026-05-20T18:52:49Z

@cowtowncoder : how does it look like with first release candidate of Jackson 3.2? If you want to start discussing the deserialization now or later, I'm ready to help or discuss

cowtowncoder · 2026-05-20T22:16:15Z

@f-aubert Bit slower than planned, but planning notes are here:

FasterXML/jackson-future-ideas#106

so probably skipping RCs altogether. But will also need Jackson 2.22(.0) released first.
And due to flow of vuln fixes for LTS versions (2.18, 2.21, 3.1), may need/want to push patches for those first too.

But if you could file an issue for "Deserialization support for @JsonApplyView" that'd be good first step I think.

isc-auf and others added 5 commits March 9, 2026 18:02

Fix FasterXML#5745: handle new JsonApplyView annotation

0064c6c

Merge branch 'FasterXML:3.x' into 3.x

74e2d79

Merge branch 'FasterXML:3.x' into 3.x

9ae5409

Fix FasterXML#5745: implements findApplyView

c2a0e0e

Fix FasterXML#5745: clones SerializationContextExt with seenObjectIds…

185ef8a

… and objectIdGenerators

cowtowncoder reviewed Mar 11, 2026

View reviewed changes

Comment thread src/main/java/tools/jackson/databind/introspect/AnnotationIntrospectorPair.java Outdated

cowtowncoder reviewed Mar 11, 2026

View reviewed changes

Comment thread src/main/java/tools/jackson/databind/introspect/AnnotationIntrospectorPair.java Outdated

cowtowncoder reviewed Mar 11, 2026

View reviewed changes

Comment thread src/main/java/tools/jackson/databind/ser/BeanPropertyWriter.java Outdated

cowtowncoder reviewed Mar 11, 2026

View reviewed changes

Merge branch '3.x' into 3.x

328f47a

Fix FasterXML#5745: performance improvement (saving applyView in Bean…

bbf5476

…PropertyWriter)

Merge branch '3.x' into 3.x

3c70196

cowtowncoder reviewed Mar 30, 2026

View reviewed changes

Comment thread src/main/java/tools/jackson/databind/introspect/JacksonAnnotationIntrospector.java

f-aubert and others added 2 commits April 15, 2026 22:18

Merge branch 'FasterXML:3.x' into 3.x

8821a19

Fix FasterXML#5745: change implementation to modify activeView

f8c1e2a

Merge branch '3.x' into 3.x

b2c411e

cowtowncoder reviewed Apr 17, 2026

View reviewed changes

Fix FasterXML#5745: performance improvement (hotpath as before)

bea9481

cowtowncoder added the cla-needed PR looks good (although may also require code review), but CLA needed from submitter label Apr 18, 2026

cowtowncoder added cla-received PR already covered by CLA (optional label) and removed cla-needed PR looks good (although may also require code review), but CLA needed from submitter labels Apr 21, 2026

Fix FasterXML#5745: adding unit tests (noneView, nesting)

70274a5

f-aubert marked this pull request as ready for review April 29, 2026 20:22

cowtowncoder added 2 commits April 30, 2026 14:32

Merge branch '3.x' into 3.x

4bec609

Merge branch '3.x' into 3.x

36c261d

cowtowncoder reviewed May 1, 2026

View reviewed changes

Fix compilation problem wrt @JsonApplyView defaulting

2fe4f0a

cowtowncoder added 2 commits May 4, 2026 13:27

Minor clean up

184f7a7

Extend test coverage

023f682

Add release notes

fdc5a72

cowtowncoder changed the title ~~PR for JsonApplyView (#5745)~~ PR for using @JsonApplyView (#5745) May 4, 2026

Last small fixes

9e3834c

cowtowncoder merged commit 58cd0eb into FasterXML:3.x May 4, 2026
6 checks passed

cowtowncoder mentioned this pull request May 5, 2026

Ability to change active JsonView on submodels (with `@JsonApplyView') #5745

Closed

Uh oh!

Conversation

f-aubert commented Mar 10, 2026 • edited by cowtowncoder Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cowtowncoder Mar 11, 2026

Choose a reason for hiding this comment

Uh oh!

f-aubert commented Mar 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

f-aubert commented Mar 13, 2026

Uh oh!

f-aubert commented Mar 15, 2026

Uh oh!

f-aubert commented Mar 29, 2026

Uh oh!

cowtowncoder commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

f-aubert commented Apr 15, 2026

Uh oh!

cowtowncoder Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

f-aubert Apr 18, 2026

Choose a reason for hiding this comment

Uh oh!

cowtowncoder Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

f-aubert Apr 18, 2026

Choose a reason for hiding this comment

Uh oh!

f-aubert commented Apr 18, 2026

Uh oh!

f-aubert commented Apr 21, 2026

Uh oh!

f-aubert commented Apr 29, 2026

Uh oh!

github-actions Bot commented Apr 30, 2026

🧪 Code Coverage Report

Uh oh!

github-actions Bot commented May 1, 2026

🧪 Code Coverage Report

Uh oh!

github-actions Bot commented May 1, 2026

🧪 Code Coverage Report

Uh oh!

cowtowncoder May 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cowtowncoder May 1, 2026

Choose a reason for hiding this comment

Uh oh!

cowtowncoder commented May 1, 2026

Uh oh!

f-aubert commented May 2, 2026

Uh oh!

cowtowncoder commented May 4, 2026

Uh oh!

cowtowncoder commented May 4, 2026

Uh oh!

cowtowncoder commented May 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

f-aubert commented May 4, 2026

Uh oh!

github-actions Bot commented May 4, 2026

🧪 Code Coverage Report

Uh oh!

github-actions Bot commented May 4, 2026

🧪 Code Coverage Report

Uh oh!

Uh oh!

f-aubert commented Mar 10, 2026 •

edited by cowtowncoder

Loading

f-aubert commented Mar 12, 2026 •

edited

Loading

cowtowncoder commented Mar 30, 2026 •

edited

Loading

cowtowncoder May 1, 2026 •

edited

Loading

cowtowncoder commented May 4, 2026 •

edited

Loading