• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Transient Properties and XMLEncoder

 
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I guess the obvious problem is, 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.

But if you aren't using e.g. JSTL or anything else which translates e.g. ${thing.fleetingInfo} into the result of the getFleetingInfo() method when evaluated on the thing, perhaps it doesn't matter.
 
Stevens Miller
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 )
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Stevens Miller
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
His brain is the size of a cherry pit! About the size of this ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic