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

Nullability annotations continued: think of alternatives #319

Open
ljacqu opened this issue Jun 20, 2023 · 1 comment
Open

Nullability annotations continued: think of alternatives #319

ljacqu opened this issue Jun 20, 2023 · 1 comment
Labels
architecture Difficult architectural questions
Milestone

Comments

@ljacqu
Copy link
Member

ljacqu commented Jun 20, 2023

Unfortunately, @NotNull clutters the code and especially array/varargs and makes it more difficult to follow the code. In this issue, we want to think about a long-term solution for this, such as:

  • keep it as it is
  • see if we can default params to be not-null (I think that's not possible -> need to make sure Kotlin picks up on it)
  • migrate the project to Kotlin?
  • Introduce a Kotlin facade?
  • keep the notnull annotations only on API classes
@ljacqu ljacqu added this to the ConfigMe 2.0.0 milestone Jun 20, 2023
@ljacqu ljacqu added the architecture Difficult architectural questions label Aug 21, 2023
@ljacqu
Copy link
Member Author

ljacqu commented Aug 29, 2023

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architecture Difficult architectural questions
Development

No branches or pull requests

1 participant