On 31 juil. 2013, at 13:14, Hardy Ferentschik wrote: > > 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. >
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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
