Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

objects and case objects not serialized properly on Scala 2.13/3 when getter visibilty is disabled #596

Open
lggmonclar opened this issue Aug 31, 2022 · 4 comments

Comments

@lggmonclar
Copy link

This issue is very similar to this: #429

Serialization is incorrect when using Scala 2.13 to serialize objects and case objects that do not belong to the same class as the method that is calling them.

Here's a minimum working example for this issue:

case object Foo {
  val field: String = "bar"
}

object Main {
  def main(args: Array[String]): Unit = {
    val mapper = JsonMapper.builder()
      .addModule(DefaultScalaModule)
      .visibility(PropertyAccessor.FIELD, JsonAutoDetect.Visibility.ANY)
      .visibility(PropertyAccessor.GETTER, JsonAutoDetect.Visibility.NONE) // This is the setting that didn't cause issues on Scala 2.12, but does on 2.13
      .build()

    val output = mapper.writeValueAsString(Foo)

    println(output) // prints {} on Scala 2.13, {"field": "bar"} on Scala 2.12 
  }
}

May be worth noting that in the case below, where the object belongs to the same class as the method that is calling it, the serialization works as expected (which was exactly the case described by #429):

class Main {
  case object Foo {
    val field: String = "bar"
  }
  def test(): Unit = {
    val mapper = JsonMapper.builder()
      .addModule(DefaultScalaModule)
      .visibility(PropertyAccessor.FIELD, JsonAutoDetect.Visibility.ANY)
      .visibility(PropertyAccessor.GETTER, JsonAutoDetect.Visibility.NONE)
      .build()

    val output = mapper.writeValueAsString(Foo)

    println(output) // Prints {"field":"bar"}
  }
}

object Main {
  def main(args: Array[String]): Unit = {
    new Main().test();
  }
}
@pjfanning
Copy link
Member

Thanks for the report. I reproduced the issue but not sure I have much time to debug in the next few days.
This serialization works if you don't mess with the visibility settings. Is there a reason to use those settings and not go with the default? jackson-module-scala does not have full test coverage for all the permutations of jackson configuration and annotations setting.

@lggmonclar
Copy link
Author

Unfortunately I don't have control of where the visibility settings are set, as they are defined in a common library that may have unintended side effects if altered, so changing them would not be my first solution.

Thanks for looking into this. We have a way to work around this issue but it's admittedly fairly ugly and cumbersome, so I'll look forward to a fix, even if it takes a while 😄

@pjfanning pjfanning changed the title objects and case objects not serialized properly on Scala 2.13 objects and case objects not serialized properly on Scala 2.13/3 when getter visibilty is disabled Sep 3, 2022
@pjfanning
Copy link
Member

The issue here is that Scala 2.13 and Scala 3 generate Java classes for the Scala Object that have the fields marked as static. It appears that in early versions, the Scala compiler does not make them static. jackson-databind AnnotatedFieldCollector._isIncludableField() ignores static fields. We still have access to a getter for the static field but the user has disabled the visibility setting for getters.

I'm reluctant to spend any time on this. The user should simply not mess with visibility settings in this case.

@cowtowncoder the only 'fix' I can see here is to have jackson-databind support an optional feature that gets AnnotatedFieldCollector._isIncludableField() to accept static fields. I don't really see the point myself. Or at least, there are plenty of more useful things that can be worked on.

@cowtowncoder
Copy link
Member

@pjfanning I concur. While it'd be good to have configurable things, this seems like it's way down the list of priorities.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants