Grpc-java: Context in its own package?

Created on 22 Mar 2017  Â·  6Comments  Â·  Source: grpc/grpc-java

Although io.grpc.Context is shipped in its own artifact, and non-gRPC users can also depend on it, the package name still causes branding issue (google/instrumentation-java/issues/162), and a practical issue with OSGI (#2727). We may consider moving it into its own package and splitting it completely from gRPC.

We have two questions to answer:

  1. What should the new package name be? Probably something starting with com.google, but probably not com.google.common.context because it collides with a Google's proprietary context class.
  2. How to bridge the old Context and Deadline to the new ones.

Most helpful comment

Could be a non-company'specific package name similar to dagger which just
uses one word iirc. Short package helps as you can fully qualify the class
easily in adapters

On 30 Mar 2017 08:02, "Bogdan Drutu" notifications@github.com wrote:

We can put it under com.google.instrumentation.context (but again it may
not be generic enough and probably the name is too long). Can we put it in
com.google.context or com.google.base?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grpc/grpc-java/issues/2847#issuecomment-290262409,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD613167xYd09n-xX3Rd_yj7o2T7Himks5rqvD9gaJpZM4MleqG
.

All 6 comments

cc @ejona86 @adriancole @bogdandrutu

We can put it under com.google.instrumentation.context (but again it may not be generic enough and probably the name is too long). Can we put it in com.google.context or com.google.base?

Could be a non-company'specific package name similar to dagger which just
uses one word iirc. Short package helps as you can fully qualify the class
easily in adapters

On 30 Mar 2017 08:02, "Bogdan Drutu" notifications@github.com wrote:

We can put it under com.google.instrumentation.context (but again it may
not be generic enough and probably the name is too long). Can we put it in
com.google.context or com.google.base?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/grpc/grpc-java/issues/2847#issuecomment-290262409,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD613167xYd09n-xX3Rd_yj7o2T7Himks5rqvD9gaJpZM4MleqG
.

@bogdandrutu I don't see why instrumentation should be included in the package name. com.google.context sounds like a good choice.

@adriancole IMO non-organization-specific package names, especially with a widely used term like "context", go against the principles of Java package as a name-spacing measure. We are not the only context solution for Java, neither are we the canonical one (at least for now). We should be a good citizen and label our context with something can identify where it's from. Short fully-qualified class names in adapters is a non-goal, because adapters are one-off efforts.

@zhangkun83 your opinion duly noted :) just bear in mind that google branding this is a double-edged sword, especially since indeed the purpose of this library is for more than just google to use.

As I mentioned in #3522, it definitely feels like something like this should already be a part of JDK, but unfortunately it isn't. Based on the discussion above, com.google.context does seem to make most sense.

The bottom line is that it certainly doesn't feel like it belongs to io.grpc namespace (or project), considering that it has nothing to do with gRPC itself, and that both instrumentation-api and opencensus-api depend on it (which creates a really strange dependency graph, considering that grpc-core depends on both of those).

Was this page helpful?
0 / 5 - 0 ratings