0

Since I'm working with a framework that uses the Serializable interface in like every class, I want to make sure that the annotation interfaces in the project I'm working for are serializable as well. However, I can't neither implement nor extend Serializable in any @interface java file. This is why I'm wondering if these files are serializable by default (like enums for example) and if not, if there is a way to implement it in these files. (Even if it isn't an elegant way to code. Just want to know if it's possible in the first place). It's hard to find out where the NotSerializableExceptions come from, since the project has many fields that are not serializable (Lamdas etc.)

The Annotations are mostly structured like this in my case:

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.ANNOTATION_TYPE)
public @interface RandomAnnotation {

    //random code 

    @Retention(RetentionPolicy.RUNTIME)
    @Target(ElementType.METHOD)
    @interface RandomA {
        // no value
    }

    @Retention(RetentionPolicy.RUNTIME)
    @Target(ElementType.METHOD)
    @interface RandomB {
        // no value
    }

}
Michael
  • 41,989
  • 11
  • 82
  • 128
ladybug
  • 45
  • 1
  • 6
  • @zapl So if I receive a NotSerializableException, I can 100% be sure it's not caused by files like above? Since they are never included in the Serialization in the first place? – ladybug Nov 16 '22 at 22:19
  • Hard to say without a stack trace and the code that produces the exception. – Turing85 Nov 16 '22 at 22:20
  • 1
    [This answer](https://stackoverflow.com/a/15904913/4216641) by [jtahlborn](https://stackoverflow.com/users/552759/jtahlborn) suggests that - when using standard serialization methods - annotations are not serialized. – Turing85 Nov 16 '22 at 22:23
  • Thank you @Turing85, I also came across this post before. But I didn't quite understand if this applies to manually coded Annotations as well. Somewhere else, I also read that Annotations with `Retention(RetentionPolicy.RUNTIME)` can cause problems, so I'm totally lost right now haha – ladybug Nov 16 '22 at 22:28
  • To give a more definitive answer, we need a [MRE]. – Turing85 Nov 16 '22 at 22:29
  • 4
    The question doesn't make sense. When you serialize a class, you serialize data about the *instance* of that class. Both the sender and reciever must still have a copy of the actual class definition, and usually it must be identical in order to work (though different-but-still-compatible class versions is the problem serialversionuid is designed to solve). There is some necessary minimal class-level data when you serialize (like the full class name), but retransmitting annotations every time would be incredibly wasteful. – Michael Nov 16 '22 at 22:34
  • 1
    serialized objects / instances requires that the deserializing java runtime knows what the class of that object looks like, that's why you have a serialVersionUid that you're supposed to change for breaking changes (https://stackoverflow.com/a/3285023/995891) - A serialized object only contains it's class name and version and the field names and their values. Deserialization then basically creates an instance by name via reflection and sets the fields. That's why there's no need to include class meta data like annotations on fields since they don't do anything to the state of the instance – zapl Nov 16 '22 at 22:36

0 Answers0