Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

api: Add java.time.Duration overloads to CallOptions, AbstractStub #11562

Open
wants to merge 26 commits into
base: master
Choose a base branch
from

Conversation

SreeramdasLavanya
Copy link

@SreeramdasLavanya SreeramdasLavanya commented Sep 26, 2024

Overloading API's containing long, TimeUnit with java.time.Duration

Fixes #10245

Copy link

linux-foundation-easycla bot commented Sep 26, 2024

CLA Signed

The committers listed above are authorized under a signed CLA.

@@ -95,6 +101,11 @@ public static Deadline after(long duration, TimeUnit units, Ticker ticker) {
return new Deadline(ticker, units.toNanos(duration), true);
}

public static Deadline after(Duration duration, Ticker ticker) {
return after(TimeUnit.NANOSECONDS.convert(duration.getSeconds(), TimeUnit.SECONDS),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a concern about the loss of precision, I have raised a question on Eric's comment to use TimeUnit.NANOSECONDS.convert(duration) instead of Duration.toNano().

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As Eric replied, you should be using https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/concurrent/TimeUnit.html#convert(java.time.Duration) and not have to convert using the seconds value.

@SreeramdasLavanya SreeramdasLavanya changed the title Fix for long, TimeUnit to java.time.Duration changes to API's grpc-api: Changing long, TimeUnit to java.time.Duration Oct 4, 2024
@@ -149,16 +151,16 @@ public final ScheduledHandle schedule(
final Runnable task, long delay, TimeUnit unit, ScheduledExecutorService timerService) {
final ManagedRunnable runnable = new ManagedRunnable(task);
ScheduledFuture<?> future = timerService.schedule(new Runnable() {
@Override
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't format lines unrelated to your changes, it will make git blame difficult to identify changes specific to a fix.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The formatting changes have not been reverted, here and in other places.

@@ -72,7 +73,7 @@ public void uncaughtException(Thread t, Throwable e) {

@Mock
private Runnable task3;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove formatting changes in all unrelated places.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you take care of this comment? @SreeramdasLavanya

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whitespace formatting changes are still there in this fie.


@Internal
public final class InternalTimeUtils {
public static long convert(Duration duration) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code coverage is not detecting that this method is used from tests for some reason. I don't know if it is unable to detect static import of a function. Can you try removing the static import of InternalTimeUtils.convert in the test class, and import the class only, and use InternalTimeUtils.convert( in the test code and see if the Codecov warning goes away.


import java.time.Duration;

@Internal
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@internal is used to mark certain classes as should not be used by user code. This class being just a util helper, there is no need to mark it as Internal. Also drop the Internal prefix from the class and file name and make it just TimeUtils.

Copy link
Member

@ejona86 ejona86 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use commit prefixes without the "grpc-", so just "api: Changing...". Note that this is not "changing" to Duration. It is adding Duration.


import java.time.Duration;

public final class TimeUtils {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't create a new public API. This should be package-private.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are using it from a different package io.grpc.stub.AbstractStub too. We'd have to make a copy of this class then. Is that what we want? @ejona86

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a way to expose internal classes/methods from api:

  1. The class/method itself is package-private
  2. Create a new class for the class name that needs exposing, prefixing the class name with Internal and marking it @Internal
  3. Add accessors in that InternalFoo class.

So here you'd create a public InternalTimeUtils class that has convert() on it. We do the dance because 1) we hide Internal* classes from the javadoc, and 2) when we compile with Blaze we build the Internal* classes as a separate target which is visibility-restricted.

We normally do that for APIs needed to coordinate though, not utilities (core has most utilities). In this case, just duplicating the utility seems reasonable. We'll have at most three copies of it: api, stub, core. Most other things depend on core and it it can be public in core. Not the greatest, but it is small.

import java.time.Duration;

public final class TimeUtils {
public static long convert(Duration duration) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not at all clear you get nanos back. convertToNanos()? toNanos()?

@ejona86 ejona86 added the kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run label Oct 17, 2024
@grpc-kokoro grpc-kokoro removed kokoro:run Add this label to a PR to tell Kokoro the code is safe and tests can be run labels Oct 17, 2024
@SreeramdasLavanya SreeramdasLavanya changed the title grpc-api: Changing long, TimeUnit to java.time.Duration api: Add java.time.Duration overloads to CallOptions, AbstractStub Oct 18, 2024
@@ -19,7 +19,7 @@
import java.time.Duration;

public final class TimeUtils {
public static long convert(Duration duration) {
public static long convertToNanos(Duration duration) {
try {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ejona86 Why is Codecov complaining even though the class is in fact covered by unit tests?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see it complaining here. I see it complaining on the class. That is probably for the default public constructor. We should give this class a private, never-called constructor, FWIW. I think Codecov would still point out it isn't covered though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add java.time.Duration overloads to CallOptions, AbstractStub, Deadline, and other APIs
4 participants