GleanInternalAPI leaks through the public API
Categories
(Data Platform and Tools :: Glean: SDK, defect, P3)
Tracking
(Not tracked)
People
(Reporter: Dexter, Unassigned)
Details
(Whiteboard: [telemetry:glean-rs:backlog])
+++ This bug was initially created as a clone of Bug #1554104 +++
GleanInternalAPI
only has an internal constructor, it's not internal itself, so it leaks outside of the package.
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Updated•6 years ago
|
Updated•5 years ago
|
Comment 1•5 years ago
|
||
It looks like the @PublishedApi
annotation has been implemented now, but after trying it and making all the necessary modifications to the code, it still fails with the error 'public' subclass exposes its 'internal' supertype GleanInternalAPI
.
I propose either closing this or moving it to backlog to await such a time when accomplishing this is possible. Alessio, what do you think?
Reporter | ||
Comment 2•5 years ago
|
||
(In reply to Travis Long [:travis_] from comment #1)
It looks like the
@PublishedApi
annotation has been implemented now, but after trying it and making all the necessary modifications to the code, it still fails with the error'public' subclass exposes its 'internal' supertype GleanInternalAPI
.I propose either closing this or moving it to backlog to await such a time when accomplishing this is possible. Alessio, what do you think?
Let's move it to backlog and revisit later, please. Thanks for looking into it!
Comment 3•5 years ago
|
||
Thanks! Moving this to backlog and untaking in the hopes that Kotlin adds/fixes this functionality in the future.
Comment 4•5 years ago
•
|
||
After re-reading the documentation on the @PublishedApi
annotation, it only appears to allow the internal
things to be called from public inline
functions, and would make the GleanInternalAPI
effectively public, which it already is. This means that using the @PublishedApi
annotation isn't going to do what we want it to do.
Since there doesn't appear to be a way to make GleanInternalAPI
actually be internal
and still be able to be instanced by the public Glean
singleton, and wrapping all of this in a public inline
function would be a breaking API change (think Glean().initialize()
rather than Glean.initialize()
), I am thinking that there isn't anything feasible that we could do about this unless we are willing to accept the breaking change.
Thoughts?
Reporter | ||
Comment 5•5 years ago
|
||
I think I agree with you: there is nothing we could really do here. I'd lean toward leaving this open though, in case things change in the future. This is still something we might want to do, somewhen.
Comment 6•5 years ago
|
||
Okay, leaving this open to come back and re-evaluate options later.
Comment 7•4 years ago
|
||
(Bit of a cleanup)
Nothing changed in 9 months, so I'm closing this.
Description
•