Thanks, done
Tilman
On 12.08.2023 15:19, Daniel Gredler wrote:
Hi Tilman,
Thanks! I would have sent a patch, but I've run into some build issues :-)
I think cloning would just ensure that the static final `TimeZone` instance
is not modified by client code (i.e. defensive copy). For example, if an
application is using the `Calendar` instance provided by
`readInternationalDate()`, and calls
`calendar.getTimeZone().setRawOffset(foo)`, I think they will have modified
the offset of the UTC constant. Not very common, but a possible source of
errors. I think there are only two methods which might modify the TimeZone,
so it's *almost* immutable, but not quite.
The `TimeZone` internals are funky, but it seems like depending on how the
`TimeZone` is created, it also sometimes needs to create a defensive copy
in order to stay safe.
@Andreas: Thanks for the information about Calendar vs `java.time` APIs.
It's not a biggie, but the new APIs do have some advantages (for this
situation: fully immutable time zones, and an out-of-the-box UTC constant).
Daniel
On Thu, Aug 10, 2023 at 6:38 AM Tilman Hausherr <[email protected]>
wrote:
On 08.08.2023 19:30, Daniel Gredler wrote:
If not, what about keeping a static final UTC `TimeZone` constant and
creating a clone each time it is needed, to avoid the synchronization?
(`Calendar.getTimeZone()` makes liberal use of `clone()`, for example).
I've added a static final for UTC but no cloning yet; why would we have
to clone it when needed? Why does java do it?
I looked a bit in the source code, there is a "sharedZone" flag, but
it's unclear if set or not.
https://issues.apache.org/jira/browse/PDFBOX-5645
Tilman
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
