Getter/Setter - Serialization
 

Hi,

probably a silly question. I have a class and some members will be
initialized only when calling a 'create' method. I'm using Eclipse and
there I get a warning "Found non-transient, non-static member. Please
mark as transient or provide accessors."

My question is now how to handle it correct. When I provide a setter
(assume a creation date) then I could set the creation date to another
as initialized when calling 'create'. That's why I wouldn't provide a
setter for this member. But obviously the warning want to tell me that
I might have problems with the serialization then obviously requiring
that the setter exists (and yes I'm intending to do serialization -
probably XML).

Could you please give some helpful comments on this?

Re: Getter/Setter - Serialization
 

On 7/24/2011 8:07 AM, Thomas Lehmann wrote:
> I might have problems with the serialization then obviously requiring
> that the setter exists


Yeah, I think the setter/getter might be required for XML style
serialization, but not in the general case.

What are you doing that Eclipse says you need to mark a field as
transient? This doesn't make sense to me, because general serialization
will handle this just fine. I think I need some context here.

Here's a good article on serialization:

<http://java.sun.com/developer/technicalArticles/Programming/serialization/>

Re: Getter/Setter - Serialization
 

The warning message comes with PMD (plugin).
I'm intending to use XStream for XML serialization and so far I can
see
there is no need to provide getter and setter.

I know that article (URL) but reading also "Effective Java" you will
be warned
about the problem with using "Serializable".


On 24 Jul., 17:30, markspace <-@.> wrote:
> On 7/24/2011 8:07 AM, Thomas Lehmann wrote:
>
> > I might have problems with the serialization then obviously requiring
> > that the setter exists
>
> Yeah, I think the setter/getter might be required for XML style
> serialization, but not in the general case.
>
> What are you doing that Eclipse says you need to mark a field as
> transient? *This doesn't make sense to me, because general serialization
> will handle this just fine. *I think I need some context here.
>
> Here's a good article on serialization:
>
> <http://java.sun.com/developer/technicalArticles/Programming/serializa...>

Re: Getter/Setter - Serialization
 

On 7/24/2011 9:33 AM, Thomas Lehmann wrote:
> The warning message comes with PMD (plugin). I'm intending to use
> XStream for XML serialization and so far I can see there is no need
> to provide getter and setter.


I haven't used XStream; if you don't think there's a problem, I'd
ignore the PMD plug-in and just do the right thing. PMD is likely in error.


> I know that article (URL) but reading also "Effective Java" you will
> be warned about the problem with using "Serializable".


I don't have time to review EJ right now, care to refresh my memory what
is pertinent in EJ to this problem?

Re: Getter/Setter - Serialization
 

On Jul 24, 8:07*am, Thomas Lehmann
<thomas.lehmann.priv...@googlemail.com> wrote:
> Hi,
>
> probably a silly question. I have a class and some members will be
> initialized only when calling a 'create' method. I'm using Eclipse and
> there I get a warning "Found non-transient, non-static member. Please
> mark as transient or provide accessors."
>
> My question is now how to handle it correct. When I provide a setter
> (assume a creation date) then I could set the creation date to another
> as initialized when calling 'create'. That's why I wouldn't provide a
> setter for this member. But obviously the warning want to tell me that

Did you declare the attribute as 'final'? If you want to protect a
member variable from change, that's often the best way. It has other
benefits as well.

> I might have problems with the serialization then obviously requiring
> that the setter exists (and yes I'm intending to do serialization -
> probably XML).
>
> Could you please give some helpful comments on this?

Could you please give us an SSCCE?
http://sscce.org/

As markspace points out, we need some context here.

To grok serialization, you should rigorously study the material in
Joshua Bloch's seminal book /Effective Java/, which thoroughly covers
the risks and best practices involved.
http://java.sun.com/docs/books/effective/
Chapter 11

--
Lew

Re: Getter/Setter - Serialization
 

On 7/24/2011 12:33 PM, Thomas Lehmann wrote:
> On 24 Jul., 17:30, markspace<-@.> wrote:
>> On 7/24/2011 8:07 AM, Thomas Lehmann wrote:
>>
>>> I might have problems with the serialization then obviously requiring
>>> that the setter exists
>>
>> Yeah, I think the setter/getter might be required for XML style
>> serialization, but not in the general case.
>>
>> What are you doing that Eclipse says you need to mark a field as
>> transient? This doesn't make sense to me, because general serialization
>> will handle this just fine. I think I need some context here.
>>
>> Here's a good article on serialization:
>>
>> <http://java.sun.com/developer/technicalArticles/Programming/serializa...>
> The warning message comes with PMD (plugin).
> I'm intending to use XStream for XML serialization and so far I can
> see
> there is no need to provide getter and setter.
>
> I know that article (URL) but reading also "Effective Java" you will
> be warned
> about the problem with using "Serializable".

Yes.

But his arguments against serialization applies to xstream as
well, so ...

Arne

Re: Getter/Setter - Serialization
 

On Sun, 24 Jul 2011 08:07:06 -0700 (PDT), Thomas Lehmann
<thomas.lehmann.private@googlemail.com> wrote, quoted or indirectly
quoted someone who said :

>Hi,
>
>probably a silly question. I have a class and some members will be
>initialized only when calling a 'create' method. I'm using Eclipse and
>there I get a warning "Found non-transient, non-static member. Please
>mark as transient or provide accessors."

Is this field for some reason non-serialisable? If it is serialisable,
you could just ignore the warning.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Most of computer code is for telling the computer
what do if some very particular thing goes wrong.