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.
I think Steve had a similar experience when writing some code related to ORM and JPA I
think. However, I cannot find any official
reference stating that it is ok to have unused import statement and that they don't
have any runtime implications.
It seems to be some sort of VM optimisation which would imply that it is VM specific and
another implementation might as well
load eagerly.
--Hardy