On 08/02/2011 11:17, Simon Nash wrote:
I'm very dubious about the wisdom of this. I bear the scars from a
previous life of a situation where a flag was added to an enterprise
application server (which shall remain nameless) to override the PBV
semantics required by the architecture in the interests of performance
optimization when the user of the product "knew" that using PBR would
be safe. Needless to say, on a number of occasions this flag was set
incorrectly and this resulted in accusations of runtime bugs that were
eventually shown after laborious debugging to have been caused by the
PBR "optimization" being enabled incorrectly.
IMO it's the implementation's responsibility to make the correct
assertions about whether it's PBR-safe. Implementations that don't
assert @AllowsPassByReference will have worse performance than those
that do support it. If a component developer cares about performance,
they need to code their implementation to play by the APBR rules and
turn on the flag to say they have done that. If the flag isn't turned
on by the implementer, I can't imagine that an assembler will have a
detailed enough knowledge of the implementation to be able to safely
provide the APBR assertion that the component developer couldn't/
wouldn't/didn't provide.
(Deep breath) Now I feel better after getting that off my chest :-)
Simon
Simon,
I sympathise with your viewpoint.
It is far better if the Java code itself asserts its "cleanliness".
My suggestion was not made with any conviction.
Yours, Mike.
