Serialization incompatibility between class generated by ajc and javac

Question

Recently I found out that some classes compiled by Java (Java 8) and by ajc (v.1.9.2) are not serialization-compatible. By serialization-compatibility I mean that calculated default serialVersionUID are not same.

Example:

public class Markup implements Serializable {
    private final MyUnit unit;
    public Markup(MyUnit unit) { this.unit = unit; }

    public enum MyUnit { DOUBLE, STRING }

    public static void main(String[] args) throws IOException, ClassNotFoundException {
        Path path = Paths.get("markup.bin");
        if (args.length == 0) {
            try (OutputStream fileOutput = Files.newOutputStream(path);
                 ObjectOutputStream objectOutput = new ObjectOutputStream(fileOutput))
            {
                objectOutput.writeObject(new Markup(MyUnit.STRING));
            }
        } else {
            try (InputStream fileInput = Files.newInputStream(path);
                 ObjectInputStream objectInput = new ObjectInputStream(fileInput))
            {
                System.out.println(objectInput.readObject());
            }
        }
    }

    static String switchType(MyUnit unit) {
        switch (unit) {
            case STRING: return "%";
            case DOUBLE: return "p";
            default: return "Undefined";
        }
    }
}

When I compile this class by ajc and run, and then compile this class by javac and run I get exception about incompatibility of serialization format:

Exception in thread "main" java.io.InvalidClassException: Markup; local class incompatible: stream classdesc serialVersionUID = -1905477862550005139, local class serialVersionUID = 793529206923536473

I also found out that's it's because of ajc switch code generator. It creates additional field in class private static int[] $SWITCH_TABLE$Markup$MyUnit

Fields generated by javac: Fields generated by ajc:

My questions are:

Is it allowed by specification for java compiler to generate fields which are not defined in the class?
Why ajc generates additional field? Some sort of performance optimization?
Are there any way to make ajc to not generate additional field?
What the reason why private static affects generation of serialVersionUID ?
Are developers of aspectj aware of this behavior? If so, why they choose generate field anyway?
Are there any guarantees how Java class will be serialized by JLS?
How Javac-generated code works without this field?

1. Yes. 2. Looks like a switch table. 3. No. 4. It isn't clear that it does. You need to specify the `serialVersionUID` yourself to overcome this problem. — user207421, Apr 28 '19 at 23:45
5. See 4. 6. Yes, there is a whole Object Seralization Specification. 7. Too broad. You could always try it the way I suggested, instead of just adding more pointless questions. One question per post is the usual maximum here. — user207421, Apr 29 '19 at 12:08
>6. Yes, there is a whole Object Seralization Specification. Why it doesn't work well in this case? If there is specification - it means some compiler ignores it. Which one? I want to know more deep details. Not just Yes/No answers. — turbanoff, Apr 29 '19 at 12:41
I don't think that clarifying questions are pointless. They help to explain context - what I wan't to know. — turbanoff, Apr 29 '19 at 13:08
Why make an easy thing complicated? Provide your own serialVersionUID! Do you really want to rely on internals of a compiler? And of course ajc creates different code because (a) it weaves aspects into your classes and (b) is forked off of ejc (Eclipse Java Compiler), not off of javac. BTW, this question possible suffers from the [XY problem](https://meta.stackexchange.com/a/66378/309898). — kriegaex, Apr 30 '19 at 04:45
@kriegaex I want to know is compiler behavior specified? yes - that's why we have JLS. Serialization behavior specified - yes. That's why we have serialization spec. It's not just "internals of a compiler". It's language/platform specification. I know that's adding `serialVersionUID` will help with `InvalidClassException`. It's not a "problem" actually for me. >Why make an easy thing complicated? Because, you know, we are engineers, and want to know how things work :) — turbanoff, Apr 30 '19 at 05:18
@turbanoff This isn't a question that even makes sense and you can find that https://docs.oracle.com/javase/tutorial/jndi/objects/serial.html. You are confusing a IDE internal usage for compiling. Please understand the class interpretation before asking about something that has nothing to do with bad coding practice that causes errors like these. — April_Nara, May 04 '19 at 16:12
@April_Nara can you please be more specific? I understand that not defining serialversionUIS is bad practice, because any change in class will be incompatible. I don't change class in my question. Compilation and serialization is standardized. So, from my opinion all should work well. — turbanoff, May 04 '19 at 17:07
See [§4.6 of the _Java Object Serialization Specification_](https://docs.oracle.com/en/java/javase/12/docs/specs/serialization/class.html#stream-unique-identifiers); it explicitly warns about how the default `serialVersionUID` computation is highly sensitive to compiler implementations. It also explains how the the default value is computed. Note that the [`Serializable`](https://docs.oracle.com/en/java/javase/12/docs/api/java.base/java/io/Serializable.html) documentation also has the same warning. — Slaw, May 05 '19 at 09:40

score 3 · Accepted Answer · answered May 06 '19 at 16:00

1. Is it allowed by specification for java compiler to generate fields which are not defined in the class?

Yes, though they should be marked as synthetic. Synthetics include accessors for inner classes (although that implementation has changed recently), lambda expressions methods and, I think, default constructors.

2. Why ajc generates additional field? Some sort of performance optimization?

Looks like a bad performance optimisation. Perhaps it's something to do with adding aspects efficiently.

3. Are there any way to make ajc to not generate additional field?

No idea. You should expect synthetics to be generated regardless.

4. What the reason why private static affects generation of serialVersionUID ?

Java Serialization was created in "Internet time". For compatibility, we are left with whatever the first version happened to do. Moral: If you create anything in Internet time, do throw it away.

5. Are developers of aspectj aware of this behavior? If so, why they choose generate field anyway?

I would hope so. Compilers are expected to genera synthetics.

6. Are there any guarantees how Java class will be serialized by JLS?

There is a Java Serialization specification (though I don't really expect many people to read it).

7. How Javac-generated code works without this field?

It's relatively easy to see how you could write a switch-on-string without an array. Exact details of an ugly optimised version are going to be messy. You can see what actually happens with javap -private -c.

Conclusion

It is recommended to add a serialVersionUID if data is expected to be used between different versions of a class. OTOH, it's also recommended to not use Java Serialization.

Serialization incompatibility between class generated by ajc and javac

1 Answers1