Map as a return value? 2004-01-27 - By Damon Hart-Davis
Back
Hi,
1) If the Map is going to passed across a non-local EJB (RMI) boundary then
in theory it will be (deep) copied anyway (unless your J2EE server lets you
turn this off). So it would be a shame to copy it twice.
2) Rather than copy it, if it's not going to change, return it wrapped in a
Collections.unmodifiableMap() wrapper. Then its safe and efficient for
local or remote use.
3) If the underlying Map content might change once you've passed a view of
it to the client then you have concurrency and behaviour issues to consider.
You may just have to copy anyway to be safe in this case.
All IMHO; your mileage and my sanity may vary.
Rgds
Damon
-- -- Original Message -- --
From: "Erik Beijnoff" <erik@(protected)>
To: <J2EE-INTEREST@(protected)>
Sent: Tuesday, January 27, 2004 10:06 AM
Subject: Map as a return value?
> Pardon me if you find this question to common to fit into the j2ee
> category.
>
> I suppose this question is impossible to answer with a simple yes or no,
> but I'm looking for standard practices when an object deals with
> collections as return values from a method invocation.
>
> Say that I call some getParameters() method on some object that returns
> a Map of parameters. Should the Map be copied before it is returned so
> that the calling object can't affect the original Map, or should the Map
> be returned by reference?
>
> My spontaneous feeling is that the object shouldn't spill it's internal
> guts around, so the Map should really be a copy of the other Map, but
> what about performance if you have to create and recreate copies of all
> Maps that gets passed around the system?
>
> What are the situations where it is acceptable, or even wanted for an
> object to return a shared Map? Or do you find it acceptable, from a
> performance point of view to hand out the Map as long as you "know" that
> you will only read the Map?
>
> I know that there are different situation where different rules apply,
> of course, but what I'm looking for is what these different situations
> really are. I've found my self contemplating this implementation detail
> quite often recently, and often tended to go with the shared object
> approach, propably out of scare to affect performance.
>
> Regards Erik Beijnoff
>
>
===========================================================================
> To unsubscribe, send email to listserv@(protected) and include in the
body
> of the message "signoff J2EE-INTEREST". For general help, send email to
> listserv@(protected) and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to listserv@(protected) and include in the body
of the message "signoff J2EE-INTEREST". For general help, send email to
listserv@(protected) and include in the body of the message "help".
|
|
