The introduction
In the course of the week
In a business scenario, I needed to ask my colleague Li to open an interface. He found that the return value he gave me contained variables of enumeration type. I casually mentioned that the return value of this interface had better not use such objects containing enumeration type
Li asked me why, I said directly, in the Java Development Manual, it is mandatory that the two libraries can define enumerations, parameters can use enumerations, but the interface return value is not allowed to use enumerations or POJO objects containing enumerations
But, after thinking about it, gu do the teacher in the “manual” written in this rule must be correct?
The body of the
Yang Xiaoshuai: I don’t understand my classmate, what’s wrong with this interface, serialization exception?
Don’t understand although the heart panic of a batch, but the surface still pretend steady a pen: no, it must be you call the way is wrong, you are back to check check, I did not touch this interface
Do not understand the confidence of the triple strike, let the small handsome doubt back to the seat
At this point, don’t understand, hurriedly opened the idea “I just changed a interface enumeration values, zha will deserialize abnormalities, wrong, I remember about interface returns a value in the manual are not allowed to use enumerated types or POJO object contains enumerated types, die die, zha forgot when writing code, let me back quickly, as long as I change fast enough, No one will find my bug.”
At this time Yang Xiaoshuai has quietly standing in the work station do not understand, see do not understand in the change enumeration, “do not understand is you, the specification you can forget, why do you”
Don’t understand a little shy smile: “mistake, mistake, controllable, controllable”
Yang Xiaoshuai: “like this two-sided library interface return value remember to worry more”
At this time small beautiful gather together come over: “what is two square library?”
Yang Xiaoshuai shook his head: two-party library, also known as two-party package, generally refers to the company’s internal release to the central warehouse, available for other internal applications to rely on the library (JAR package); One party library is the library that the subproject module of this project depends on; Third-party libraries are open source libraries outside the company, such as FastJSON and EasyExcel
Mei: Why is the return value of this interface not allowed to use enumerations or POJO objects that contain enumerations?
Yang Xiaoshuai: Yes, if we change the enumeration, the enumeration of both of us will be different, which will appear in the interface resolution, and an exception will appear during deserialization
For example, if your local enumeration class has a weather Enum: SUNNY, RAINY, CLOUDY, it would be fine to pass in any of the three values if you used guess(WeatcherEnum xx) to calculate your mood based on the weather
If Weather guess is returned, then it returns a SNOWY value. If this value is not present in the local enumeration, it is an exception
Small beauty nodded, so it is ah
At this time, manager Wang came over and asked everyone: is this standard appropriate?
M: I think what Xiao Shuai said is very reasonable, the interface return value using enumeration does cause such an exception
Manager Wang: What do you think is the significance of enumeration?
1, 2, 3, 1, 2, 3, 3, 1, 2, 3, 3, 1, 2, 3, 3, 1, 2, 3, 3, 3, 1, 3, 3, 3, 3, 3, 3, 1, 3, 3, 3, 3
Manager Wang: That makes sense. To enumerate means to list all the known ones. As a two-party/three-party library provider, it is safe to use what I support. I support more when I update the library. You won’t use it if you don’t know about it, and you can’t pass it to me if I don’t support it anyway, so as input, enumerations are almost safe, but as return values, it’s the other way around. I tell you that these and these can be there, and then you stipulate that these and these can be there, and nothing else. But I’m in charge, not you, so your rules are bullshit. The provider upgrades stealthily, and the probability of throwing an exception is almost 100%
That we encounter, like do not understand such a pit goods, secretly upgrade how to do, this interface call less can notify synchronous upgrade, then, if an interface has hundreds of callers, can do synchronous upgrade?
So can we strengthen the robustness of our framework when we call it by setting the field to null if a new enumeration value is found during serialization, as in the Apache Thrift code?
Manager Wang: Ok, that’s all for today. Think about it
Small beauty, do not understand, small handsome was immersed in thinking…..
conclusion
In fact?
In the interface returned by the binary library, configure a policy that will report an error if the values of the enumeration are methods and properties that must be used within the enumeration
If the enumeration can only process the recognized enumeration in the business, and the unrecognized enumeration is not processed, configure the policy to convert it to null
If the enumeration is treated as a default value if it is not recognized in the business, configure a policy to convert to the default value
If the enumeration is not used by the local business at all and you don’t care, you can define it as an int or String when defining the receiving object.
In this way, the conversion of custom enumerated classes in the overall serialization framework is more compatible with security checks and extensibility, both to be compatible with the benefits of enumerations and to be robust to our RPC framework, so what can we do at the top level to make developers more comfortable?
Of course, all the starting point, or based on our current business scenario and the actual situation to the use of time can be more thinking
Attached is teacher Gu Jin’s answer about this rule
Because of the upgrade, the enumeration classes of both sides are not the same, and an exception occurs during interface parsing and class deserialization. Any element that appears in Java, such as interfaces, abstract classes, annotations, and the enumerations mentioned in this article, has the thought and logic behind it from Gosling’s perspective (although it’s not absolutely perfect, Java’s top-level abstraction is already genius). Enumerations have the advantage of being type safe, clear and straightforward, and can also be used with the equal sign, which can also be used in switch. The disadvantage is obvious: don’t expand. But why the return value and the parameter distinction, if not compatible, then both problems, how to allow parameters can have an enumeration. It was considered that enumerations would be of little use if the parameters could not be used either. Parameter output, after all, is determined locally, you have it locally, pass it over, forward compatibility is not a problem. If it is returned by an interface, it is more disgusting, because the enumeration value that is parsed back may not be locally available, and then a serialization exception will be thrown. For example, if your local enumeration class has a weather Enum: SUNNY, RAINY, CLOUDY, it would be fine to pass in any of the three values if you used guess(WeatcherEnum xx) to calculate your mood based on the weather. Another value is Weather guess(parameter), and then it returns a SNOWY value.
Phase to recommend
3 minutes to understand the bridge mode 
