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] > >
