getsentry / getsentry/sentry-java
Decide hybrid SDK API marker for v9
- Dominant language
- Kotlin
- Stars
- 1.4k
- Forks
- 478
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 67
Description
As we mark more SDK surface `@ApiStatus.Internal` ahead of v9 package moves, some types/methods are still consumed by hybrid SDKs (Flutter, React Native, etc.) even when they are not customer-facing.
`@ApiStatus.Internal` alone does not distinguish hybrid-facing surface from pure SDK plumbing, so hybrid consumers can be broken by a later relocate/remove pass.
Known examples called out during review of the utils Internal pass:
* `io.sentry.util.LoadClass`
* `io.sentry.util.TracingUtils`
Context: NoOp stubs and most util helpers were recently marked Internal (getsentry/sentry-java#6016, getsentry/sentry-java#6017); hybrids were explicitly left unmarked for now.
Action taken on behalf of Nelson Osacky.
Contributor guide
Research direction
Start by reviewing the internal-marking changes referenced in getsentry/sentry-java#6016 and #6017, focusing on io.sentry.util.LoadClass and io.sentry.util.TracingUtils. Compare the treatment of NoOp stubs, util helpers, and hybrid SDK consumers, then define and apply a marker policy that distinguishes hybrid-facing surface from pure SDK plumbing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, kotlin
- Domain
- backend-api-design, mobile-dev
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100