Reverting source-incompatible change in 2.12 (ObjectMapper.treeToValue())

8 views
Skip to first unread message

Tatu Saloranta

unread,
Oct 12, 2020, 12:15:20 PM10/12/20
to jacks...@googlegroups.com
Ok, so, with 2.12.0-rc1 (more on this on another email), I got report:

https://github.com/FasterXML/jackson-databind/issues/2805

which points out that intended convenience change to remove some
checked exceptions will break some existing usage as it is
source-incompatible change.
This is true.

I am leaning towards reverting the change from 2.x and leaving for 3.0
(where there will be bigger exception rewrite anyway) but thought I'd
ask if anyone has other arguments to make in favor of incremental 2.x
changes, even at expense of some compatibility issues.

-+ Tatu +-

Mark Derricutt

unread,
Oct 12, 2020, 4:45:03 PM10/12/20
to jacks...@googlegroups.com

I’ve never really been a fan of APIs that have a dual pair of methods:

new ObjectMapper().treeToValue(tree);   
new ObjectMapper().uncheckedTreeToValue(tree);

but they can serve a purpose in situations like this. It does start to get rather verbose/wordy tho. If 3.0 is going to have a much larger exception rewrite, for those who want the relaxed behaviour now - would such a compromise be acceptable?

Mark

Tatu Saloranta

unread,
Oct 12, 2020, 6:48:16 PM10/12/20
to jacks...@googlegroups.com
On Mon, Oct 12, 2020 at 1:45 PM Mark Derricutt <ma...@talios.com> wrote:
>
> I’ve never really been a fan of APIs that have a dual pair of methods:
>
> new ObjectMapper().treeToValue(tree);
> new ObjectMapper().uncheckedTreeToValue(tree);
>
> but they can serve a purpose in situations like this. It does start to get rather verbose/wordy tho. If 3.0 is going to have a much larger exception rewrite, for those who want the relaxed behaviour now - would such a compromise be acceptable?

That's a good question. I must admit I am not big fan either, partly
since potential number of methods to duplicate is rather large.
At some point I was even contemplating idea of "UncheckedObjectMapper"
sub-class which would
simply override method without exceptions (as sub-classes may do).
This before realizing that in 3.0 we can make Jackson base exception
(`JacksonException`) unchecked, which avoids this problem altogether.

On plus side, change did not make it into release and I think my
immediate plan is simply to revert change from 2.x

-+ Tatu +-

>
> Mark
>
>
>
>
> From: Tatu Saloranta <ta...@fasterxml.com>
> Reply: jacks...@googlegroups.com <jacks...@googlegroups.com>
> Date: 13 October 2020 at 5:15:08 AM
> To: jacks...@googlegroups.com <jacks...@googlegroups.com>
> Subject: [jackson-dev] Reverting source-incompatible change in 2.12 (ObjectMapper.treeToValue())
>
> I am leaning towards reverting the change from 2.x and leaving for 3.0 (where there will be bigger exception rewrite anyway) but thought I'd ask if anyone has other arguments to make in favor of incremental 2.x changes, even at expense of some compatibility issues.
>
> --
> You received this message because you are subscribed to the Google Groups "jackson-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jackson-dev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CALYGm1xtvLOh7h1mXEh_fhwy6eX2mX2szT1Er4Q%2BDCvej9tG3Q%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages