-
Notifications
You must be signed in to change notification settings - Fork 78
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
Review unused imports in classes in CDI 4 #600
Comments
I do think this is intended, because it affects how the javadoc is rendered, but I haven't been here since the beginning, so it's just my guess :-) |
I vaguely recall that this was discussed in meetings before CDI 2.0 and deliberately kept this way but OFC I am not 100% sure. |
If the javadoc uses the full name, the import statement on the top can be omitted. It is better not to directly mention the import statement as it plays a part in the build. |
I'd repurpose this to: we need to have a proper linter in the CDI project (and the TCK). |
Checkstyle is what is commonly used, and the MicroProfile project has an example usage to review: |
I'd personally lean towards using |
+1 on creating a set of rules. |
I'm seeing quite a lot of imports that are only used to refer to documentation while the class or interface itself is not dependent on such a class. Examples:
jakarta.enterprise.inject.Instance
refers tojakarta.enterprise.util.AnnotationLiteral
but only in@See
jakarta.enterprise.context.spi.Contextual
refers tojakarta.enterprise.inject.CreationException
only in docsjakarta.enterprise.inject.spi
refers tojakarta.enterprise.inject.Alternative
andjakarta.enterprise.inject.Stereotype
only in docsjakarta.enterprise.inject.spi
refers tojakarta.enterprise.context.Dependent
,jakarta.enterprise.inject.Disposes
,jakarta.enterprise.event.Observes
andjakarta.enterprise.inject.Produces
only in docs.Is this intended? I personally consider this bad form and convert those to fully qualified names to avoid creating the illusion of dependencies on other parts of the system where there are none.
Note that if I remove those imports, a minimal set of classes (
Contextual
,CreationalContext
,Instance
,Annotated
,Bean
,BeanAttributes
,InjectionPoint
,TypeLiteral
) could be extracted to support minimal implementations of this specification.The text was updated successfully, but these errors were encountered: