I have a class that I want to serialize with XMLEncoder, but some of its properties are transient and do not need to be serialized. It's similar to this:
Because the last two methods do not start with "get," "set," or "is," they are not discovered by XMLEncoder, so the following code only saves the value of lastingInfo when it writes an instance of the class:
However, in Using XMLEncoder, Philip Mine suggests this approach to declaring transient data:
(I assume this would first require that the getter and setter for the fleetingInfo field be recoded to JavaBean standard.)
That's fine, but it seems a bit cumbersome if, to "hide" a field from XMLEncoder, all I have to do is not use JavaBean standard names for my getters and setters. In my tests, that's exactly what happens. XMLEncoder just ignores my getters and setters that don't have standardized JavaBean names. That seems like a much easier way to avoid serializing transient properties than Mine's technique.
Anyone see a problem with how I'm doing this?
In the other disciplines, we rise by standing on each others' shoulders. In computer science, we do it by standing on each others' toes.
Paul Clapham wrote:...if you don't follow standard JavaBean naming conventions, then anything which expects your bean to be following those conventions won't be able to use those methods.
Good point. With my trick, the properties I am "hiding" from XMLEncoder will be just as hidden from anything else that relies on the JavaBean naming conventions. This may not be inherently evil, though, as the JavaBeans Specification appears to say it's an option you can choose deliberately:
Section 2.2 wrote:The methods a Java Bean exports are just normal Java methods which can be called from other
components or from a scripting environment. By default all of a bean’s public methods will be
exported, but a bean can choose to export only a subset of its public methods (see Section 8.5).
Frustratingly, Section 8.5 doesn't quite speak to this as directly as that excerpt made me think, but it does seem to say that a matching BeanInfo class can actually help overcome the "hiding" effect. I can't claim to be sure about that, though.
As it happens, I wasn't intending to write a JavaBean class in the first place. I just use getters/setters for everything that follow the get/set/is convention because that appears to be How Things Are Done (and because the NetBeans "Insert Code" wizard follows it automatically). That, in turn, made it possible for me to use XMLEncoder, which seemed like a much easier way to serialize my object than any other option I had (and that met my criteria of being human-readable, able to handle my data without me writing code for each new property I add, and not accompanied by warnings that it won't work across versions of Java).
I suppose I could have asked this: What options do I have for serializing objects that meet my criteria of being human-readable, able to handle my data without me writing code for each new property I add, and not accompanied by warnings that it won't work across versions of Java, as well as easily allowing me to select some properties as persistent and some as transient? But, I don't like it when other people ask general "tell me how to do this so I won't have to look it up" questions, and I had spent a fair amount of time working on this already, so here I am. (That said, if you know an obvious alternative I should consider, please do let me know )
I'd say only providing JavaBeans-compatible getters and setters for those attributes that you intend to serialize sounds fine. After all, having getters and setters for all fields is not recommended practice, it is more like a code smell. Tell, don't ask does apply to that.
If you need really advanced Java<-->XML mapping, then that's what JAXB is for. It does have a learning curve, though, but once you got going with it, it's easy to specify which fields to serialize and which not.
Sehr geschätzt, Ulf. I hadn't heard of JAXB before. I'll have a quick look at the tutorial, though and- Egad, man! That's not a learning curve! That's an educational K2. Still, good to know about it. Thanks.