Re: [hibernate-dev] OGM: CheckStyle and imports due to JavaDoc comments
Does the concept of imports apply at runtime at all, or is this concept not
only present at compile time, making life easier by allowing to refer to
types using their simple name? In [1] it says about type names in class
files:
"Class and interface names that appear in class file structures are always
represented in a fully qualified form known as binary names".
I also can't see any part of the class file structure which would hold
information about imports. So when an imported type is not used in the
actual code, I don't think it will be referenced in the resulting class
file and thus can't cause any issues when not being present.
[1] http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.2.1
2013/8/1 Emmanuel Bernard <emmanuel(a)hibernate.org>
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.