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

Make GenericType not implement Serializable #73

Closed
garretwilson opened this issue Oct 5, 2023 · 4 comments
Closed

Make GenericType not implement Serializable #73

garretwilson opened this issue Oct 5, 2023 · 4 comments
Milestone

Comments

@garretwilson
Copy link

garretwilson commented Oct 5, 2023

The most common use of GenericType, as explained even in its own Javadocs, is:

new GenericType<List<Integer>>() { }

However, for reasons I don't understand, GenericType implements Serializable. This means that in ever single usage like the above, I will need to suppress a warning related to the lack of a serialVersionUID.

  • The original example in Neil Gafter's famous Super Type Tokens does not implement Serializable.
  • Jackson's TypeReference does not implement Serializable.
  • Spring's ParameterizedTypeReference does not implement Serializable.
  • The Guice TypeLiteral does not implement Serializable.
  • The GeantyRef fork of gentyref has a TypeToken which does not implement Serializable.
  • Guava's TypeToken unfortunately does implement Serializable, so at least ClassMate is not alone on this.

So only ClassMate and Guava implement Serializable for the class with identical functionality. The rest don't. It's not clear to me how it would ever be useful.

Can we remove implements Serializable from ClassMate GenericType<T>? No one needs or even wants Serializable in 2023. There are few if any cases that anyone should be creating new code using Serializable, and here it just brings a headache.

@garretwilson garretwilson changed the title Make GenericType not implement `Serializable. Make GenericType not implement Serializable. Oct 5, 2023
@cowtowncoder
Copy link
Member

I agree, sounds like an oversight to be corrected. I hope to address this later today (really busy at daytime job but maybe tonight).

As to need for java.io.Serializable, for the longest time there were some (possibly ill-conceived, legacy) use cases related to things like Spark processing, where things like Jackson ObjectMappers needed to be (or was useful to have) Serializable. That's why within Jackson many entities are Serializable. I don't see that as the reason for this one at all, but just mention for sake of completeness.

And yes, due to many, many issues, use of java.io.Serializable is definitely an anti-pattern in general.

@garretwilson
Copy link
Author

… really busy at daytime job but maybe tonight …

I can understand that! 😅

Hey, I'll be happy to take this one. I need to set up the project for other changes we've been discussing, and it will give me some pleasure to get Serializable out of there. If you haven't started it, I'll do it and file a pull request now.

@garretwilson
Copy link
Author

Hey, I'll be happy to take this one.

Eep, I take that back. I assumed that I could just fork the project, build it, make the change, make sure the unit tests pass, and then file a pull request. But it looks like we have some problems; see #74. (As mentioned there, I can help with that, with a caveat.)

So for the meantime, if this builds on your system, it's probably better if you go ahead and take care of this ticket as you had indicated earlier.

@cowtowncoder cowtowncoder changed the title Make GenericType not implement Serializable. Make GenericType not implement Serializable Oct 10, 2023
@garretwilson
Copy link
Author

I was dropping by here to fix this ticket, but I see you've already done it, and even released v1.6.0. 🎉 Thank you for your attention and quick work! I'm heading to go grab the new version now.

@cowtowncoder cowtowncoder added this to the 1.6.0 milestone Oct 20, 2023
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

2 participants