[log4j] Java 8 and java.time

[Gary Gregory <ga...@gmail.com>]

Some notes.

Java 8 provides a java.time package. It would be nice to reuse it instead
of keeping our own Java 7-based code.

We provide a MutableInstant class akin to the final immutable thread-safe
java.time.Instant class.

Our class is not interchangeable with java.time.Instant but it could be a
little more playful by implementing the java.time interfaces Temporal,
TemporalAdjuster, Comparable<Instant>.

Java 8 also provides Clock classes. We do as well. Our clocks initialize
MutableInstant instances.

It does not seem possible to move from our custom time code to java.time.

It should be possible to update TimeFilter to use java.time, but I wonder
if it would be as performant.

Thoughts?

Gary

Re: [log4j] Java 8 and java.time

[Ralph Goers <ra...@dslextreme.com>]

I am sure we can find a way to eliminate our custom time code or base it on java.time. Whether it performs better or not would require that it be tested and compared. It wouldn’t be a simple matter to create a JMH benchmark and create our time formatting against java.time.

Ralph

> On Nov 4, 2018, at 10:33 AM, Gary Gregory <ga...@gmail.com> wrote:
> 
> Some notes.
> 
> Java 8 provides a java.time package. It would be nice to reuse it instead
> of keeping our own Java 7-based code.
> 
> We provide a MutableInstant class akin to the final immutable thread-safe
> java.time.Instant class.
> 
> Our class is not interchangeable with java.time.Instant but it could be a
> little more playful by implementing the java.time interfaces Temporal,
> TemporalAdjuster, Comparable<Instant>.
> 
> Java 8 also provides Clock classes. We do as well. Our clocks initialize
> MutableInstant instances.
> 
> It does not seem possible to move from our custom time code to java.time.
> 
> It should be possible to update TimeFilter to use java.time, but I wonder
> if it would be as performant.
> 
> Thoughts?
> 
> Gary

Re: [log4j] Java 8 and java.time

[Remko Popma <re...@gmail.com>]

> On Nov 5, 2018, at 2:33, Gary Gregory <ga...@gmail.com> wrote:
> 
> Some notes.
> 
> Java 8 provides a java.time package. It would be nice to reuse it instead
> of keeping our own Java 7-based code.
> 
> We provide a MutableInstant class akin to the final immutable thread-safe
> java.time.Instant class.
> 
> Our class is not interchangeable with java.time.Instant

Correct, we use a mutable data structure to carry precise (sub-milli) time stamps from the call site to the appenders in a GC-free manner. The Java.time package only has immutable data structures. 

> but it could be a
> little more playful by implementing the java.time interfaces Temporal,
> TemporalAdjuster, Comparable<Instant>.
I haven’t looked at these APIs but I see no reason why this can’t be done. (It may not be garbage free, but that’s a trade off for the client code.)

> 
> Java 8 also provides Clock classes. We do as well. Our clocks initialize
> MutableInstant instances.
I haven’t looked in detail but perhaps in Log4j 3 our Clock could extend java.time.Clock.

> 
> It does not seem possible to move from our custom time code to java.time.
What do you mean by “move to java.time”? We use the custom MutableInstant implementation class rather than the Instance interface because we need the extra facilities provided by this class. 

Or do you mean something else, like the formatting code?

> 
> It should be possible to update TimeFilter to use java.time, but I wonder
> if it would be as performant.

We’d need to measure. 
> 
> Thoughts?
> 
> Gary