`JsonNodeFeature.STRIP_TRAILING_BIGDECIMAL_ZEROES` not working with `ObjectMapper.valueToTree()`

[pankajxeine]

Search before asking

• I searched in the issues and found nothing similar.

Describe the bug

I have migrated code from jackson2 to jackson 3 and tried to trail BigDeciaml with zeroes using jackson 3x but it is not working with below configuration as suggested in document .
Jackson 2 Code (Working fine with jackson 2)

@Bean
public Jackson2ObjectMapperBuilderCustomizer customMapper () {
return builder -> builder.postConfigurer(objectMapper -> 
objectMapper.setNodeFactory(JsonNodeFactory.withExactBigdecimals(true)))
}

Jackson-databind 3.0.4 Code (output is different)

@Bean 
JsonMapperBuilderCustomizer customMapper () {
return builder-> builder
.enable(JsonNodeFeatue.STRIP_TRAILING_BIGDECIMAL_ZEROES)
.enable(StreamWriteFeature.WRITE_BIGDECIMAL_AS_PLAIN);

BigDecimalWrapper body = new BigDecimalWrapper(new BigDecimal("1.000"), new BigDecimal(2.000), new BigDecimal(3000l));

ResponseEntity.ok(objectMapper.valueToTree(body);
Expected :
output : {bd1: 1, bd2: 2, bd3: 3)

Actual
output: {bd1: 1.000, bd2:2, bd3: 3}

I have tried with simple java code as well but still getting same result.

public class MainApp {

public static void main(String[] args) throws JacksonException {
ObjectMapper mapper = JsonMapper.builder()
.enable((JsonNodeFeatue.STRIP_TRAILING_BIGDECIMAL_ZEROES)
.enable(StreamWriteFeature.WRITE_BIGDECIMAL_AS_PLAIN)
.build();
BigDecimalWrapper body = new BigDecimalWrapper(new BigDecimal("1.000"), new BigDecimal(2.000), new BigDecimal(3000l));

System.out.println(mapper.valueToTree(body)); // output:  {bd1: 1.000, bd2:2, bd3: 3}

}

Version Information

3.0.4

Reproduction

<-- Any of the following

1. Configure ObjectMapper with enable(JsonNodeFeatue.STRIP_TRAILING_BIGDECIMAL_ZEROES)
2. call mapper.valueToTree(body)
3. (JsonNodeFeatue.STRIP_TRAILING_BIGDECIMAL_ZEROES does not take effect with jackson 3x.
4. I observed this issue only occurred when we create BigDecimal with String literal e.g. new BigDecimal("1.000")
   -->

public class MainApp {

public static void main(String[] args) throws JacksonException {
ObjectMapper mapper = JsonMapper.builder()
.enable((JsonNodeFeatue.STRIP_TRAILING_BIGDECIMAL_ZEROES)
.enable(StreamWriteFeature.WRITE_BIGDECIMAL_AS_PLAIN)
.build();
BigDecimalWrapper body = new BigDecimalWrapper(new BigDecimal("1.000"), new BigDecimal(2.000), new BigDecimal(3000l));

System.out.println(mapper.valueToTree(body)); // output:  {bd1: 1.000, bd2:2, bd3: 3}

}

Class BigDecimalWrapper  {
BigDecimal bd1;
BigDecimal bd2;
BigDecimal bd3;

BigDecimalWrapper (BigDecimal bd1, BigDecimal bd2, BigDecimal bd3) {
this.bd1 = bd1;
this.bd2 = bd2;
this.bd3 = bd3;
}
}

Expected behavior

Expected behavior is Bigdecimal 0 should be trailed if JsonNodeFeatue.STRIP_TRAILING_BIGDECIMAL_ZEROE enabled as default it is disabled.

output: {bd1: 1.000, bd2:2, bd3: 3}

Additional context

Nothing

[pjfanning]

Can you test this without spring? We only accept POCs that use Jackson and built-in java code.

[pjfanning]

Actually, the reproduction case (MainApp) has no Spring. So that's fine.

[pjfanning]

The issue seem to specifically about valueToTree and I don't think the intention is for this feature setting to affect that method. It is more targeted at parsing and writing JSON (as opposed to a tree).

Copilot highlights these previous issues and it might be worth reviewing the conversations on these issues.

Most Closely Related Issue
writeValueAsString(Object) and writeValueAsString(JsonNode) produce different results with BigDecimal#5605
node-config
3.0
1
FasterXML/jackson-databind · JeanLouisArdoint closed on Jan 26
Issue #5605 is the most directly related. It reports the same class of problem: valueToTree() and direct serialization produce inconsistent results for BigDecimal when JsonNodeFeature.STRIP_TRAILING_BIGDECIMAL_ZEROES is involved. Specifically:

It was filed against Jackson 2.19.0 (not 3.x)
It shows writeValueAsString(bigDecimal) gives 100 but writeValueAsString(mapper.valueToTree(bigDecimal)) gives 1E+2
The reporter notes the workaround is using StreamWriteFeature.WRITE_BIGDECIMAL_AS_PLAIN or disabling STRIP_TRAILING_BIGDECIMAL_ZEROES
It was closed as completed and is milestoned for 3.0.0
Other Loosely Related Issues
There is also a pattern of historical valueToTree() + BigDecimal issues that have been fixed over the years:

TreeBuildingGenerator#writeNumber(String) writes Number as String#5528
3.1
9
FasterXML/jackson-databind · gaeljw closed on Dec 24, 2025
WRITE_BIGDECIMAL_AS_PLAIN is being ignored in Jackson 2.5.3#842
6
FasterXML/jackson-databind · ghost closed on Jun 25, 2015
Converting bound BigDecimal value to tree fails with WRITE_BIGDECIMAL_AS_PLAIN#232
1
FasterXML/jackson-databind · celkins closed on May 26, 2013
Summary
The core problem in issue #5819 — that STRIP_TRAILING_BIGDECIMAL_ZEROES is not applied during valueToTree() — is essentially the same root cause as #5605: the JsonNodeFeature flags are not being honoured when serializing via the tree-building path. Issue #5605 was reportedly closed/completed and milestoned for 3.0.0, but #5819 suggests the fix may be incomplete or the Jackson 3.x path still has a gap. It would be worth referencing #5605 in issue #5819.

[cowtowncoder]

Also note: test should be with 3.1.0 since 3.0.x branch is closed.

On JsonNodeFeature.STRIP_TRAILING_BIGDECIMAL_ZEROES JavaDocs say:

Feature that determines whether {@link java.math.BigDecimal} values
will be "normalized" by stripping trailing zeroes off, when constructing nodes 

so it should apply to ObjectMapper.valueToTree(), but not on writing.

So this looks like a flaw.

[cowtowncoder]

@pankajxeine What I struggle with here a bit are relative descriptions ("different between 2.x and 3.x"; "look at output") -- it would be better to just explain how you expect 3.x to work, not considering 2.x (except as background info). Difference b/w 2.x and 3.0.4 is not, in itself, a bug.

I think I know what is expected -- that trailing zeroes are to be removed with valueToTree() -- but it'd be good just say that.
I'll work based on this understanding.