Hi Peter,
On 23/02/15 11:29, Peter Levart wrote:
Caching of ZoneId in the defensive clone of defualt TimeZone object
would not have a desired effect as the clone is thrown away in each call
to ZoneId.systemDefault(). We must get hold of the TimeZone instance
that is cached. Another way to do that would be to take the route of
reflection objects (Field, Method, Constructor) and put a pointer to
'root' TimeZone instance in the clones, so it would be accessible
through the clone.
Ah I see. You would have to initialize the zoneId field in the
root object, i.e. in setDefaultZone - and possibly in
TimeZone.setDefault as well. So that might not be as good an
idea after all...
Finally, I also wonder whether a better idea would be to add
a variant of dosToJavaTime/javaToDosTime that would take an
additional zoneId as parameter.
For ZipEntry it would not make much sense as there's only one time value
that has to be converted only once in each ZipEntry.
If I'm not mistaken dosToJavaTime is only called from ZipFile
and ZipInputStream, and javaToDosTime from ZipOutputStream.
You probably don't want to support changing the time zone in
the middle of a Zip. Do you?
Ok, in that case the ZoneId would have to be attached to ZipFile and
passed to each ZipEntry. I agree that per ZipFile default zone atomicity
is a desired property. Speeding up ZoneId.systemDefault() retrieval is
also generally desirable, don't you think?
Agreed. I'm just not a big fan of using SharedSecrets if that can
be helped. I just wanted to see if there was other alternatives to
explore.
best regards,
-- daniel
