feat: introduce java.time methods and variables
#2826
Conversation
product-auto-label
bot
added
size: m
| public java.time.Duration getTerminationAwaitDurationDuration() { | ||
| return java.time.Duration.ofMinutes(1); |
There was a problem hiding this comment.
I don't think we've seen this case before (or at least I don't recall). But if the method ends with Duration then we come across DurationDuration and I think that's even more confusing.
Maybe we want to keep this for consistency with all other SDK methods, but I'm thinking that naming scheme isn't ideal.
Perhaps getTerminationAwaitJavaTimeDuration()? Open to suggestions for this.
There was a problem hiding this comment.
Cross linking googleapis/java-datastore#1671 (comment)
I like JavaTimeDuration as the suffix. Let's use it in datastore too
There was a problem hiding this comment.
I agree with the point in googleapis/java-datastore#1671 (comment) saying that using DurationJavaTime keeps the prefixes consistent
There was a problem hiding this comment.
to confirm this with @sydney-munro and @JesseLovelace
This PR introduces
java.timealternatives to existingorg.threeten.bp.*methods, as well as switching internal variables (if any) tojava.timeThe main constraint is to keep the changes backwards compatible, so for each existing threeten method "
method1(org.threeten.bp.Duration)" we will add an alternative with a Duration (or Timestamp when applicable) suffix: "method1Duration(java.time.Duration)".For most cases, the implementation will be held in the
java.timemethod and the old threeten method will just delegate the call to it. However, for the case of abstract classes, the implementation will be kept in the threeten method to avoid breaking changes (i.e. users that already overloaded the method in their user code).