Investigate moving from Joda to java.time

[clintongormley]

Today we use a forked version of Joda for performance reasons. This can lead to problems with class loading (eg #10290, #3557, #4660), and requires us to have hacks to ensure that our version of Joda is loaded first.

We should investigate the possibility of replacing Joda with java.time. One roadblock would be the need to reimplement the dateOptionalTimeParser, which doesn't have an equivalent java.time. See http://sourceforge.net/p/joda/mailman/message/34327973/ for more

[uschindler]

Strong +1

[jack-pappas]

Another alternative might be to use date4j instead of Joda Time. It's supposedly faster than Joda and should also fix the timestamp-precision issues (Joda only maintains millisecond-level precision and truncates any timestamps more precise than that).

[dadoonet]

Note that date4j uses a BSD license.

[s1monw]

In general I think the less dependencies we have the better ie. I think cutting over to java.time would be ideal from a maintenance perspective

[uschindler]

In addition, as java.time (which is a fork of joda anyways) is part of the JDK, it should get more attention by Hotspot deveopers. We may get performance improvements...

BTW: forbidden-apis 2.0 has new signatures around java.time, but they are also part of Lucene's signature files. If you want to switch, I would recommend to use those (or update to 2.0, which comes earlier).

[uschindler]

See: policeman-tools/forbidden-apis@c34a02a

[jordansissel]

Slightly related -- Logstash will also be moving its date filter to use java.time. We will share any lessons learned if we get to this first.

[jpountz]

cc @elastic/es-search-aggs

[jpountz]

Closing in favour of #27330.