On 02/14/2015 04:33 PM, Peter Levart wrote:
Well, internally I think it should be stored as an Instant. So you
don't have to reconstruct Instant objects at each call to
getInstant(). Serialization of LogRecord is not a frequent
requirement, so the overhead should be moved to it, rather than to
frequent code-paths. That's my opinion.
Documenting serializable format should be easy anyway. It doesn't have
to be based directly on public getters/setters. For example:
The LogRecord's "instant" is serialized as two hypothetical fields to
keep backwards compatibility:
long millis = getInstant().toEpochMilli();
int nanoOfMilli = getInstant().getNano() % 1000_000;
Regards, Peter
Hi Daniel,
I must admit, it's not so simple after all. I tried to do it and I had
to do the following to get a decent javadoc:
http://cr.openjdk.java.net/~plevart/jdk9-dev/LogRecord.instant/webrev.01/
So take it if you think this isn't too much to support or leave it and
do it your way (with just an additional @serial nanoAdjustment field).
Regards, Peter
