[
https://issues.apache.org/jira/browse/HADOOP-19454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yaniv Kunda updated HADOOP-19454:
---------------------------------
Description:
Many pieces of code still use old Java date/time classes, and can benefit from
migrating to the "new" (Java 8) {{java.time}} APIs for several reasons,
including:
* Non thread-safe SimpleDateFormat - forces ThreadLocal usages and is generally
bad practice these days (see YARN-11116)
* Redundant object creation - e.g. creating a {{java.util.Date}} just to get an
epoch millis value
* Use of {{Calendar}}, {{TimeZone}}, etc.
* All sorts of date/time arithmetics
I propose 3 types of changes in this area:
1) Internal changes - should be trivial to change without user-facing changes
2) User-facing APIs - should be done _extending_ current code, with the
question of deprecating existing code discussed separately
3) External dependencies - value of change vs. cost (complexity/performance)
should be discussed on a case-by-case basis.
was:
Many pieces of code still use old Java date/time classes, and can benefit from
migrating to the "new" (Java 8) {{java.time}} APIs for several reasons,
including:
* Non thread-safe SimpleDateFormat - forces ThreadLocal usages and is generally
bad practice these days (see YARN-11116)
* Redundant object creation - e.g. creating a {{java.util.Date}} just to get an
epoch millis value
* All sorts of date/time arithmetics
I propose 3 types of changes in this area:
1) Internal changes - should be trivial to change without user-facing changes
2) User-facing APIs - should be done _extending_ current code, with the
question of deprecating existing code discussed separately
3) External dependencies - value of change vs. cost (complexity/performance)
should be discussed on a case-by-case basis.
> Migrate usage of old Java date/time classes to java.time
> --------------------------------------------------------
>
> Key: HADOOP-19454
> URL: https://issues.apache.org/jira/browse/HADOOP-19454
> Project: Hadoop Common
> Issue Type: Improvement
> Components: hadoop-common
> Reporter: Yaniv Kunda
> Priority: Minor
>
> Many pieces of code still use old Java date/time classes, and can benefit
> from migrating to the "new" (Java 8) {{java.time}} APIs for several reasons,
> including:
> * Non thread-safe SimpleDateFormat - forces ThreadLocal usages and is
> generally bad practice these days (see YARN-11116)
> * Redundant object creation - e.g. creating a {{java.util.Date}} just to get
> an epoch millis value
> * Use of {{Calendar}}, {{TimeZone}}, etc.
> * All sorts of date/time arithmetics
> I propose 3 types of changes in this area:
> 1) Internal changes - should be trivial to change without user-facing changes
> 2) User-facing APIs - should be done _extending_ current code, with the
> question of deprecating existing code discussed separately
> 3) External dependencies - value of change vs. cost (complexity/performance)
> should be discussed on a case-by-case basis.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
