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

Fix @NullableType annotations to be compatible with Kotlin #6792

Open
imcloud opened this issue Dec 20, 2019 · 6 comments
Open

Fix @NullableType annotations to be compatible with Kotlin #6792

imcloud opened this issue Dec 20, 2019 · 6 comments
Assignees
Labels

Comments

@imcloud
Copy link

imcloud commented Dec 20, 2019

image

return type can be null, but I got compile error

image

rendererConfigurations = Array<RendererConfiguration?>()
rendererTrackSelections = Array<TrackSelection?>()

I think it's right to pass arrayOfNull

@tonihei
Copy link
Collaborator

tonihei commented Dec 20, 2019

Thanks for reporting. We'll fix the MediaClock problem.

The RendererConfigurations and TrackSelections in the second example are a problem though because they use the deprecated @NullableType of checkerframework's compat-qual package that has been removed just over a year ago. It seems Kotlin is also not recognizing them as a valid nullable annotation and we need to switch to an alternative.

@tonihei
Copy link
Collaborator

tonihei commented Dec 20, 2019

While we are trying to figure out how to solve the @NullableType issue, you can work around the problem by making an unchecked cast:

TrackSelectorResult(
    rendererConfigurations as Array<RendererConfiguration>,
    rendererTrackSelections as Array<TrackSelection>,
    info)

ojw28 pushed a commit that referenced this issue Dec 20, 2019
Without this @nullable, potential subclasses can't  override the
method to return null if they don't want to use the renderer as a
media clock.

Issue:#6792
PiperOrigin-RevId: 286545736
@ojw28
Copy link
Contributor

ojw28 commented Dec 20, 2019

The fix for MediaClock will be included in 2.11.1. For the @NullableType issue, please use the workaround mentioned above for now.

ojw28 pushed a commit that referenced this issue Dec 20, 2019
Without this @nullable, potential subclasses can't  override the
method to return null if they don't want to use the renderer as a
media clock.

Issue:#6792
PiperOrigin-RevId: 286545736
@imcloud
Copy link
Author

imcloud commented Dec 23, 2019

thanks for your help

1 similar comment
@imcloud
Copy link
Author

imcloud commented Dec 23, 2019

thanks for your help

@imcloud imcloud closed this as completed Dec 24, 2019
@tonihei tonihei reopened this Dec 31, 2019
@ojw28 ojw28 changed the title 2.11.0 kotlin compile error Fix @NullableType annotations to be compatible with Kotlin Jan 2, 2020
@imcloud
Copy link
Author

imcloud commented Jun 23, 2020

another kotlin error

TrackSelector.java

image

info cannot be null type,

but, TrackSelectorResult allow array elements to be null

This can lead to exceptions in the kotlin language

The fix for MediaClock will be included in 2.11.1. For the @NullableType issue, please use the workaround mentioned above for now.

marcbaechinger pushed a commit to androidx/media that referenced this issue Jun 19, 2023
The existing NullableType has been deprecated 5 years ago and causes
crashes in Kotlin apps because Kotlin doesn't recognize this annotation
as a nullable type annotation.

While we can't align on a single @nullable annotation yet, we can at
least replace this one by JSR305's @nonnull(MAYBE) as it fulfils all
requirements, including full Kotlin compatiblity. To avoid the
cumbersome name, we can redefine it as our own @nullabletype
annotation. (We can't use @nullable to avoid name clashes with the main
@nullable annotation from AndroidX)

Issue: google/ExoPlayer#6792
PiperOrigin-RevId: 540497469
icbaker pushed a commit that referenced this issue Jun 20, 2023
The existing NullableType has been deprecated 5 years ago and causes
crashes in Kotlin apps because Kotlin doesn't recognize this annotation
as a nullable type annotation.

While we can't align on a single @nullable annotation yet, we can at
least replace this one by JSR305's @nonnull(MAYBE) as it fulfils all
requirements, including full Kotlin compatiblity. To avoid the
cumbersome name, we can redefine it as our own @nullabletype
annotation. (We can't use @nullable to avoid name clashes with the main
@nullable annotation from AndroidX)

Issue: #6792
PiperOrigin-RevId: 540497469
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants