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

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

As discussed, here a Draft PR.

… and objectIdGenerators

cowtowncoder · 2026-03-11T21:26:12Z

        }
    }

+    private SerializationContext getContext(SerializationContext context) {


Ugh. No, this adds way too much per-property write overhead -- must NOT be done on per-call basis. That is, things need to be pre-processed when constructing/initializing BeanPropertyWriters; especially annotation introspection.

Also, even then, should not be constructing new SerializationConfigs or -Contexts on critical path -- just overriding active view (_activeView, needs to change to non-final) in SerializationContext before, resetting after.

Might be possible to wrap BeanPropertyWriter to do that... ?

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.

cowtowncoder · 2026-03-30T22:31:10Z

+    public Class<?> findApplyView(MapperConfig<?> config, Annotated a)
+    {
+        JsonApplyView ann = _findAnnotation(a, JsonApplyView.class);
+        return (ann == null) ? null : ann.value();


I think this should translate JsonApplyView.NONE.class into null so callers need do the translation or know about special casing.

Don't we need to differentiate between

JsonApplyView.NONE.class (for this property / serialization we don't want to apply any view aka setActiveView to null) and

NULL (for this property / seriailzation we don't want to change anything to the current activeView) and process views as until now in Jackson
-> I think we need to document this NONE class but cannot totally hide it. It is also a special use case since the normal case will be to replace with another view and not suppress the current one.

Hmmmh. If there is use case of forcing Active View to be set to null, yes, a placeholder needed I suppose.

So documenting this makes sense, then, and letting NONE.class be exposed.

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

cowtowncoder · 2026-04-21T22:23:50Z

Will try to get annotations PR sorted today, first, then get back here.

github-actions · 2026-04-22T04:02:32Z

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	81.58%	📈 +0.000%
Branches	74.86%	📉 -0.010%

Coverage data generated from JaCoCo test results

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

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

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

Merge branch '3.x' into 3.x

6146639

Uh oh!

Conversation

f-aubert commented Mar 10, 2026

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

f-aubert commented Apr 15, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

cowtowncoder commented Apr 21, 2026

Uh oh!

github-actions Bot commented Apr 22, 2026

🧪 Code Coverage Report

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

f-aubert commented Mar 12, 2026 •

edited

Loading

cowtowncoder commented Mar 30, 2026 •

edited

Loading