As others have mentioned, you can serialise Serializable subclass of a non-Serializable superclass.
If the superclass state is not required to be included in the serialisation, there is no problem. If the superclass state is required in the serialisation, you must resort to the unpleasant methods mentioned. Using direct field access or, if that's not possible, naughty reflection to bypass access controls, you will probably manage to save and load the superclass state.
HOWEVER, in many cases, if a class is non-Serializable, that is for a good reason: because it is inappropriate to try to store and reload an object of that class. Certainly, for most built-in
Java API classes this is true: you are strongly advised not to try to serialise non-Serializable API classes.
An example would be a java.lang.Process object. Trying to store and reload such an object would be totally inappropriate, even if you were somehow able to achieve it.