On 31 juil. 2013, at 13:14, Hardy Ferentschik wrote:
On 31 Jan 2013, at 10:41 AM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> Personally I prefer to include a class via fully qualified name if it is only used in
the javadocs.
> I think the readability does not suffer too much and adding an actual import has
actually
> runtime consequences. We already had cases where a javadoc import caused a hard link
> between code which is otherwise decoupled.
>
> WDYM exactly by "hard link" in this context? Is it about referencing a type
from an optional dependency which might not be present at runtime?
Right, optional dependencies. Take JPA and Search. In the engine module we avoid
importing it directly and do processing of
@Id reflectively. Having an import of javax.persitence.Id would create a runtime
dependency.
> I just tried out this scenario (adding an import statement just for JavaDoc to a type
which is not present at runtime) and still could execute the importing class
> without problems. Only when accessing the imported type in the actual code I'm
getting a CNFE. But this might be specific to the VM in use, not sure.
We had this discussion now several times. I remember when we wrote this reflection code
the first time (many years back ;-))
all referenced classes were eagerly loaded. In this case just having the import statement
required the class being
available at runtime. Obviously this must have changed a bit which also is proven by
your experiment.
Of course my memory might be flawed but the problems I recall around isolating a piece of
code for hv, search and later bean validation from core did not involve unused imports.
Come to think of it, I have never seen an *unused* import eagerly loading a class even
though in practice it's left unspecified by the JLS.