On 31 Jan 2013, at 10:41 AM, Gunnar Morling <gun...@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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
