Where did you get that from? The transient keyword is not intended so much to reduce workload as to prevent secret data, eg passwords, being stored in such a fashion that they can easily be read. Is serialisation such an overhead that you need to worry about transient?
Campbell Ritchie wrote:Where did you get that from? The transient keyword is not intended so much to reduce workload as to prevent secret data, eg passwords, being stored in such a fashion that they can easily be read. Is serialisation such an overhead that you need to worry about transient?
My guess is that the OP wants to know if he could knock out certain members from being serialized by using transient, regardless of whether the data is sensitive.
keiwer villabona ruiz wrote:"Serialization and deserialization of objects is a CPU-intensive procedure and is likely to slow
down your application. Use the transient keyword to reduce the amount of data serialized."
Welcome to CodeRanch!
As a matter of fact, the members marked as 'transient' are not serialized.
keiwer villabona ruiz wrote:how to use the transient keyword to improve the serialization/Deserialization
As mentioned above, you'll need to figure out which members of a class must be serialized and which members can be exempted from serialization(further, those members can be marked as transient). Please note that you might get improvement in 'performance' by not serializing all the members. This does not improve serialization, but simply bypasses the serialization process for that particular member.
Now of course we may disagree with that advice - it may well be premature optimization, and can easily be taken to excess. But aside from secrecy (which I do not think is the primary reason transient exists), there are plenty of classes that you can't or shouldn't serialize. For example a database or network connection - you might serialize the connection info, but not the actual connection. That gets re-connected after you reinstantiate the instance that needs it. Or an Xml parser, or other object with complex internals. Or any object of a library class (outside your direct control) that does not implement Serializable. You need to mark such a field transient, and figure out how to work around it. Any data that is redundant in some way, that can be derived from other values or looked up from some other resource, is a candidate for transient - especially anything that is implemented to be lazily instantiated.
I have been working in Java for a couple of years. Never used serialization till date. I think it used for very specific purposes and not by many programmers. Correct me if this sounds not common to you folks?
I think that's probably fairly common. It depends on what technology stack you're working with for a given company or project - it's definitely possible to go years without ever using it (or at least, without being aware of it). It's also very possible to use it every day. Many traditional uses of serialization have been replaced by alternate forms of serialization, e.g. using JAXB to convert to an XML representation.