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

What should we do with non-transient value-based classes? #4553

Closed
jdubois opened this issue Nov 26, 2016 · 5 comments
Closed

What should we do with non-transient value-based classes? #4553

jdubois opened this issue Nov 26, 2016 · 5 comments
Milestone

Comments

@jdubois
Copy link
Member

jdubois commented Nov 26, 2016

Our Sonar analysis available here shows we often have the same "bug", which is Make this value-based field transient so it is not included in the serialization of this class.

To have an explanation on why value-based fields must not be transient have a look here. In fact, this isn't a bug "yet", it just might be in the future.

Now this is in fact a real problem:

  • Our JPA entities need to be Serializable as it's part of the JPA spec, and as it's very likely people will put them in a cache (which can be distributed, or off heap)
  • We obviously have dates in those entities, and classes from java.time are marked as value-based
  • The solution proposed by Sonar, which is to make those fields transient, is not possible: those fields should not be transient, they should be saved in a database, and they should be available in a cache... You just don't resolve a problem by deleting it!

So I'm wondering what's the best solution is!

@jdubois
Copy link
Member Author

jdubois commented Nov 29, 2016

So it looks like nobody has a solution :-(

This really looks like one those Sonar rules that shouldn't be there in the first place. It's probably OK in plain Java code, but when using Hibernate this just makes no sense to have the field transient.

@jdubois jdubois closed this as completed Nov 29, 2016
@cbornet
Copy link
Member

cbornet commented Nov 29, 2016

We could maybe have a page for configuring Sonar in which we explain why this rule (and probably others. eg if we choose to keep field injection) must be deactivated ?

@jdubois
Copy link
Member Author

jdubois commented Nov 29, 2016

In fact I'm starting to think we should have our own Sonar rules... The default rules are really not good for us.

@jdubois jdubois modified the milestone: 3.12.0 Nov 30, 2016
@rzauel
Copy link

rzauel commented Sep 15, 2017

@SuppressWarnings("squid:S3437")

@felipeaffonso
Copy link

@rzauel thanks for giving the solution. I was worried about this issue, but in my case I don't actually need to Serialize the objects, since I'm using SpringData instead of JPA.

@jdubois JPA Specs says that you have some situations you have to implement Serializable, as you can see: https://stackoverflow.com/questions/2020904/when-and-why-jpa-entities-should-implement-serializable-interface. I don't know if it is you case.

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

No branches or pull requests

4 participants