On Thu 2013-08-01 11:41, Hardy Ferentschik wrote:
> Why? The few occasions where it happens a fully qualified class name does not
> hurt.
> It is not enough that it is considered bad practise and even Checkstyle for
> that
> reason does not allow it in the UnusedImports check?
I actually do fi
On 1 August 2013 10:41, Hardy Ferentschik wrote:
[...]
>
> So why not be safe than sorry?
>
> --Hardy
That's my same point, I just want to broaden the healthcheck, and am
showing you other practical benefits from it, which happen IMHO to
also have less annoying checks as a side effect, but that d
On 1 Jan 2013, at 10:58 AM, Sanne Grinovero wrote:
> Let's relax this, the likelyhood of this introducing a real problem
> affecting the runtime is extremely low, and there are better ways to
> prevent that. I've reopened the issue.
Why? The few occasions where it happens a fully qualified clas
On 1 Jan 2013, at 8:46 AM, Emmanuel Bernard wrote:
> 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* impor
Let's relax this, the likelyhood of this introducing a real problem
affecting the runtime is extremely low, and there are better ways to
prevent that. I've reopened the issue.
Longer reasoning + better proposal:
- we're arguing only about things used in javadoc but not code, this:
-- makes th
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 al
On 31 juil. 2013, at 13:14, Hardy Ferentschik wrote:
>
> On 31 Jan 2013, at 10:41 AM, Gunnar Morling 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 impo
For the record, I side with Gunnar in relaxing this. I actually did not see
this thread and opened a issue for it this very morning.
In most situations we reference classes local to the module via {@link} and the
fully qualified class name is very annoying and very long.
On 31 juil. 2013, at 09
2013/7/31 Sanne Grinovero
> On 31 July 2013 09:41, Gunnar Morling wrote:
> > 2013/7/31 Hardy Ferentschik
> >
> >> Hi,
> >>
> >> 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 addi
On 31 Jan 2013, at 10:41 AM, Gunnar Morling 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
On 31 July 2013 09:41, Gunnar Morling wrote:
> 2013/7/31 Hardy Ferentschik
>
>> Hi,
>>
>> 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
>> runti
2013/7/31 Hardy Ferentschik
> Hi,
>
> 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 im
I had a very minor preference for declaring the import over writing
verbose javadocs, but Hardy's point on decoupling is very interesting.
+1 to keep the error
On 31 July 2013 09:08, Hardy Ferentschik wrote:
> Hi,
>
> Personally I prefer to include a class via fully qualified name if it is only
Hi,
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 w
14 matches
Mail list logo
