If you are short of time, you can ignore this for now and come back to it later. Below are important Question & Answers taken from the Q&A discussions in this section.

Q1. While writing industry level code which one of them (Scanner and  BufferedReader ) would be a better option to use to take console input?

Answer: I don't think there is any specific recommendation. For me when it comes  to console, Scanner seems good as it helps read primitives without any  conversion. Even if you are not reading any primitives and just have to  read strings, you can still use Scanner and stick to it for consistency  sake. But, if you are reading large text files, you can probably use  BufferedReader as it has bigger buffer size than what Scanner uses.

Q2. I  have stored an object with it's current state in a file and then I have  tried to change state of that object (without creating a new object) and saved it again to the same file. But, when retrieving objects from the  file, I am able to retrieve both the objects but the state of both the  objects is same as the first object that is stored.

Here is a piece of code that will help you understand what I am trying to saying:

Writing objects to file:
SerializableDemo s = new SerializableDemo();// s has an int num and a string name
s.setNum(26);
s.setName("XYZ");
out.writeObject(s);
s.setName("ABCD");
out.writeObject(s);
out.close();

Reading objects from the file:
s = (SerializableDemo)in.readObject();
s.display(); //displays: 26 and XYZ
s = (SerializableDemo)in.readObject();
s.display(); //also displays: 26 and XYZ, but it should be 26 and ABCD

Could  you explain me the reason for this? I though it might be using hashcode  to store objects and I have even tried with overriding the hashcode  which return a unique value based on both num and name, but it didn't  make any difference (num+name.hashCode()).

Answer: Interesting. Never tried it before. Check out the below post, which  uses the same example. In the comments part of the answer, Crowder makes  it even more clear where he says "It sees you're writing out an object  it's already written out, and only writes out a reference to the object that previously was serialized.".

https://stackoverflow.com/questions/27542699/changing-instance-state-does-not-get-reflected-in-serialized-object

Q3. Should  we maintain the serialVersionID for all the classes? Like a class, it's  subclass, other classes (which most probably remain unchanged in  future).

Say that we have HAS-A relation in which class A has an  object of class B and both of them are serializable. Consider that class  B will most probably remain unchanged (say heart object in human  class), and class A keeps changing. Should we include the constant  serialVersionID in class B as well? And what about nested classes,  should the nested class implement  Serializable when it's outer class  implements it and if yes should we also include the constant in nested  class as well?

Answer: Yes, as a good practice, have serialVersionUID for all (sub-class or  one with HAS-A or nested) classes that implement serializable. Moreover,  to keep it simple, it seems we can start with 0L and increment it as  class evolves.

If an inner class like a non-static member class  implements Serializable then make sure outer class also implements  Serializable. Otherwise, serialization fails as such an inner class  maintains a reference to outer class. This is not a problem with static  member class though.

References:

https://stackoverflow.com/questions/23465613/is-serialversionuid-inherited-by-subclasses-if-i-have-default-serialversionuid

https://stackoverflow.com/questions/15477169/java-should-serializable-inner-anonymous-classes-have-serialversionuid

https://stackoverflow.com/questions/605828/does-it-matter-what-i-choose-for-serialversionuid-when-extending-serializable-cla/605832#605832

https://stackoverflow.com/questions/26045065/same-serial-version-id-for-all-the-classes?rq=1

https://stackoverflow.com/questions/888335/why-generate-long-serialversionuid-instead-of-a-simple-1l

https://help.semmle.com/wiki/display/JAVA/Serializable+inner+class+of+non-serializable+class

https://coderanch.com/t/270242/certification/serialization-classes

https://coderanch.com/t/268954/certification/classes-serialization

Q4. Why does Reader.read() return an int. Why was int used instead of say short?

With Reader, the read() method returns character as an Integer in the  range [0, 65535] or -1 if end of stream is reached. If the return type  was short, then the value range becomes [-32768, 32767] and so short is  not useful. The same argument also applies for InputStream.read, which  returns an int in the range [0, 255] with -1 for end of stream. Adam  Liss puts it nicely in the below SO post where he says "A byte of data is an unsigned value with a range from 0 to 255, while a byte in java is defined to range from -128 to 127,  which doesn't make sense when reading binary data.  read()  returns an  integer to allow it to use all of the non-negative values to  represent  valid data, and a negative value to signal end of data. "

https://stackoverflow.com/questions/10060589/why-does-the-read-in-fileinputstream-return-an-integer

https://stackoverflow.com/questions/4659659/why-does-inputstreamread-return-an-int-and-not-a-byte

Q5. Why developers need the byte order mark (BOM) and big endian and low  endianness in character encoding scheme? Why they came up with such a  think, how it identify Most significant bit? 

Answer: Developers need to take BOM in context because when you are reading a  BE file (say it is coming from a partner) and if you are reading it as  LE, then you are reading incorrectly. So, in certain cases at least when  you do not know how the files are encoded, then it may be better to  determine the BOM. Below is a post that talks about how to identify BOM.  Now, why they came up with such a thing is a historical thing. BE &  LE is not just about this concept of IO. It is to do with computer  architecture itself. Some designers preferred to use LE as it has some  advantages and while others preferred to use BE as it has its own  advantages. Second article below talks about the advantages of both.

https://stackoverflow.com/questions/1835430/byte-order-mark-screws-up-file-reading-in-java

https://stackoverflow.com/questions/13926760/the-reason-behind-endianness