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

Removes old nullable annotation and fixes problems caught with analyzer #1703

Merged
merged 1 commit into from
Aug 24, 2017

Conversation

codefromthecrypt
Copy link
Member

This can't break anything at runtime because the nullable annotation
removed was source retention. This makes Intellij Nullable analysis
possible.

@codefromthecrypt codefromthecrypt force-pushed the analyze-nullable branch 2 times, most recently from 08a9e3a to be0c4d5 Compare August 24, 2017 09:50
This can't break anything at runtime because the nullable annotation
removed was source retention. This makes Intellij Nullable analysis
possible.
@codefromthecrypt codefromthecrypt merged commit 65e7db8 into master Aug 24, 2017
@codefromthecrypt codefromthecrypt deleted the analyze-nullable branch August 24, 2017 12:20
codefromthecrypt pushed a commit that referenced this pull request Oct 14, 2017
Before, we optimized to drop our source-retention Nullable in favor of
JSR 305. In doing so, we got null analysis from Intellij. However, in
doing so, we entered a swamp of dependency conflicts, which started with
OSGi (hence switch to service mix bundle) and now with Java 9 (conflict
with apps using jax-ws.

Since we are a core dependency, and particularly not a user-api, this
change caused more problems than it fixed. Hence, this reverts to the
safer model of using internal source-retention nullable (which allows
things like AutoValue to work, but don't introduce any chance of runtime
class conflicts).

See #1703
See openzipkin/brave#451
codefromthecrypt pushed a commit that referenced this pull request Oct 14, 2017
Before, we optimized to drop our source-retention Nullable in favor of
JSR 305. In doing so, we got null analysis from Intellij. However, in
doing so, we entered a swamp of dependency conflicts, which started with
OSGi (hence switch to service mix bundle) and now with Java 9 (conflict
with apps using jax-ws.

Since we are a core dependency, and particularly not a user-api, this
change caused more problems than it fixed. Hence, this reverts to the
safer model of using internal source-retention nullable (which allows
things like AutoValue to work, but don't introduce any chance of runtime
class conflicts).

See #1703
See openzipkin/brave#451
abesto pushed a commit to abesto/zipkin that referenced this pull request Sep 10, 2019
…er (openzipkin#1703)

This can't break anything at runtime because the nullable annotation
removed was source retention. This makes Intellij Nullable analysis
possible.
abesto pushed a commit to abesto/zipkin that referenced this pull request Sep 10, 2019
Before, we optimized to drop our source-retention Nullable in favor of
JSR 305. In doing so, we got null analysis from Intellij. However, in
doing so, we entered a swamp of dependency conflicts, which started with
OSGi (hence switch to service mix bundle) and now with Java 9 (conflict
with apps using jax-ws.

Since we are a core dependency, and particularly not a user-api, this
change caused more problems than it fixed. Hence, this reverts to the
safer model of using internal source-retention nullable (which allows
things like AutoValue to work, but don't introduce any chance of runtime
class conflicts).

See openzipkin#1703
See openzipkin/brave#451
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.

1 participant