-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
None
-
generic
-
generic
ADDITIONAL SYSTEM INFORMATION :
all java versions, all osx.
A DESCRIPTION OF THE PROBLEM :
The most frustrating unnecessary exception in java is the InvalidClassException when doing 3th party version upgrade. The exception is not needed and gives us many offline times on production since all services has to be released at once..
See also my issue:
https://bugs.openjdk.org/browse/JDK-8336826.
I understand that during development with tests you whant to have a way to see that client and server classes are different and can have field or method deviations. But me, as a developer, can not control that all 3th parties handle the correct way of adding an serialVersionUID that does NOT change if there is nothing breaking.
every time again and again 3th parties like spring security, hazelcast and many others change there serialVersionUID or do not specifiy serialVersionUID at all (spring security making mistakes on all levels).
But my complaint is that most of the time there is nothing breaking since java is getting better in adding a additional field. The breaking thing IS the serialVersionUID.
i want to have an option to disable the serialVersionUID check so that i don not have to go down on production fully and release all services at once, since i have tested there is nothing breaking.
OPtions to override java code itself , many users offer, like objectinputstream and many others would not be needed with an option offered by Java.
see the many frustrations on many forms by other developers.
this is only 1 of many:
https://github.com/spring-projects/spring-security/issues/3737
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
setup client server with for example redis or hc caching with different spring security versions (even minor versions like 3.3.6->3.4.2 can be breaking, or when using custom classes within hc session. Many examples can be think of..
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
option to disable the version check if all tests written say there is no issue.
ACTUAL -
We cat invalidclassexceptions on all kinds of levels when only upgradiing hc server or only upgrading 1 of our many services (client site), on many levels oauth, session, custom made code.
CUSTOMER SUBMITTED WORKAROUND :
No real workarround is available only by overriding java core classes OR by planning offline time on production and releasing all services at once.
FREQUENCY : often
all java versions, all osx.
A DESCRIPTION OF THE PROBLEM :
The most frustrating unnecessary exception in java is the InvalidClassException when doing 3th party version upgrade. The exception is not needed and gives us many offline times on production since all services has to be released at once..
See also my issue:
https://bugs.openjdk.org/browse/JDK-8336826.
I understand that during development with tests you whant to have a way to see that client and server classes are different and can have field or method deviations. But me, as a developer, can not control that all 3th parties handle the correct way of adding an serialVersionUID that does NOT change if there is nothing breaking.
every time again and again 3th parties like spring security, hazelcast and many others change there serialVersionUID or do not specifiy serialVersionUID at all (spring security making mistakes on all levels).
But my complaint is that most of the time there is nothing breaking since java is getting better in adding a additional field. The breaking thing IS the serialVersionUID.
i want to have an option to disable the serialVersionUID check so that i don not have to go down on production fully and release all services at once, since i have tested there is nothing breaking.
OPtions to override java code itself , many users offer, like objectinputstream and many others would not be needed with an option offered by Java.
see the many frustrations on many forms by other developers.
this is only 1 of many:
https://github.com/spring-projects/spring-security/issues/3737
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
setup client server with for example redis or hc caching with different spring security versions (even minor versions like 3.3.6->3.4.2 can be breaking, or when using custom classes within hc session. Many examples can be think of..
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
option to disable the version check if all tests written say there is no issue.
ACTUAL -
We cat invalidclassexceptions on all kinds of levels when only upgradiing hc server or only upgrading 1 of our many services (client site), on many levels oauth, session, custom made code.
CUSTOMER SUBMITTED WORKAROUND :
No real workarround is available only by overriding java core classes OR by planning offline time on production and releasing all services at once.
FREQUENCY : often
- relates to
-
-
- New
-