Java Serialization Constructor Execution and Output
Given: What is the result? - 
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The core concept tested is that Java deserialization bypasses constructors; the common trap is assuming standard object creation flow applies to readObject processes.
This question tests the behavior of Java serialization regarding constructor invocation during deserialization. It establishes that constructors are not called when deserializing an object, affecting the expected console output.
Many learners incorrectly choose options involving 'error' or assume the constructors run again, leading to duplicate output like option C.
Community Discussion (4 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The correct answer is D because Java's serialization mechanism does not invoke the constructor of a class during deserialization. When the object is serialized, its state (fields) is saved. Upon deserialization, the JVM restores the field values directly into memory without executing any initialization code in the constructor. Therefore, the print statements inside the constructors ('Software', 'Game') are executed only once during the initialnew Game(...) call. The final System.out.println(s) prints the restored fields: title "Chess" and players count 2.Why the Other Options Are Wrong
Options A and E suggest errors, but serialization works fine here as there are no invalid states or missing handlers. Option B assumes the constructor runs again, printing 'Chess' but with an incorrect player count or missing context. Option C assumes both the initial creation and deserialization trigger constructors, leading to redundant 'Software Game' prefixes. Since constructors are skipped during deserialization, this double-printing does not occur.Community Comment Notes
The community consensus strongly supports option D. As user xplorerpj noted, "Software is printed from constructor... then when de-serialized... it prints raw string." Another user, SrinivasJasti, clarified that "The result of System.out.println(s) prints the title and the number of players, i.e., 'Chess 2'." These comments correctly identify the single execution of constructors and the direct restoration of state.Exam Strategy
Remember that readObject or default deserialization skips constructors. If you see side effects like print statements in constructors, they will NOT happen again during deserialization unless explicitly implemented in a custom readObject method.
Frequently Asked Questions
Why doesn't the constructor run during deserialization?
Java deserialization restores object state directly from the byte stream without invoking constructors to ensure security and efficiency, bypassing initialization logic.
Can we make constructors run during deserialization?
Not automatically. You would need to implement a custom readObject method that manually triggers constructor-like logic, but this is rare and complex.