This article analyzes the usage of transient keywords in Java. Share it for your reference. The specific analysis is as follows:
Java has a feature of serialization. Simply put, it is possible to store this class in physical space (of course it still exists in the form of a file). Then when you restore this file from locally, you can convert it to itself. This can greatly facilitate some operations on the network, but at the same time, because it involves security issues, it is not intended to store everything in the class (because in that way, others can know the content in the class through serialization). We can use the keyword transient, which means temporary, that is, it will not be serialized locally with the class, so after restoring, the variables defined by this keyword no longer exist.
Usually, the programs we write require that specific information be persisted or saved to disk for use by one program or on another run of the same program. This persistence can be achieved in several ways, including writing. In the database or using JAVA to provide support for object serialization. No matter what method we choose, the persistence of class instances is accomplished by saving the state of the class's domain, saving these states so that they can be accessed in the future. Or use them to create the same instance. However, it is possible that not all domains need to be saved. When an instance is persisted, some domains within it do not need to be persisted, you can use the trainsient modifier to tell The compiler-specified domain does not need to be persisted.
First, let's look at some Java serialization code:
public class LoggingInfo implements java.io.Serializable { private Date loggingDate = new Date(); private String uid; private transient String pwd; LoggingInfo(String user, String password) { uid = user; pwd = password; } public String toString( ) { String password=null; if(pwd == null) { password = "NOT SET"; } else { password = pwd; } return "logon info: /n " + "user: " + uid + "/n logging date : " + loggingDate.toString() + "/n password: " + password; } }Now we create an instance of this class, serialize it, and then write this serialized object like disk.
LoggingInfo logInfo = new LoggingInfo("MIKE", "MECHANICS"); System.out.println(logInfo.toString()); try { ObjectOutputStream o = new ObjectOutputStream( new FileOutputStream("logInfo.out")); o.writeObject (logInfo); o.close(); } catch(Exception e) {//deal with exception}To read the object back, we can write try { ObjectInputStream in =new ObjectInputStream( new FileInputStream("logInfo.out")) ; LoggingInfo logInfo = (LoggingInfo)in.readObject(); System.out.println(logInfo.toString()); } catch(Exception e) {//deal with exception}If we run this code, we will notice that the object read-back (de-serializing)) from disk prints password as "NOT SET". This is the correct result that we expect when we define the pwd domain as transient.
Now, let's look at the potential problems that can arise from careless treatment of transient domains. Suppose we modify the class definition and provide a default value to the transient domain, the code is as follows:
public class GuestLoggingInfo implements java.io.Serializable { private Date loggingDate = new Date(); private String uid; private transient String pwd; GuestLoggingInfo() { uid = "guest"; pwd = "guest"; } public String toString() { //same as above } } Now, if we pass through an instance of GuestLoggingInfo, write it to disk, and read it out of disk, we still see the readback object print password as "NOT SET".
When an instance of a class is read from disk, the constructor of this class is not actually executed.
Instead, a persistent state of an object of this class is loaded and this state is assigned to another object of this class.
I hope this article will be helpful to everyone's Java programming.