Sorry to say that, but our analysis of gains/losses of using imports
and FQNs say something else. We didn't base the functions of IMT on
our feelings; rather we tried to weight out readability of the code
against redundancy of imports which have only a few uses and are
"alien" for the most of class' code.
The IMT suggests to create import (by default) when a symbol is used 4
or more times, which we consider a reasonable indication for that the
symbol is intrinsic to the coded problem and symbol's references
should be kept simple.
On the contrary by introducing simple names which are used at only a
few places, the boundary between external symbols and those inherited
or defined locally in the file will vanish, confusing the user.

Note that the reasons may not entirely cover your working style; we
have to account for different working styles and choose a suitable
compromise.

If you think that it is not accurate, please conduct the analysis
again and present its results on nbdev@.

We are talking about style here, we are not talking
about correctness, so feelings/opinions are all we have
to go on.

Can you point me to the analysis that was done that
concluded 4 is the proper threshold?  Without some
hard data, then all we have is the feelings of the
development team.

I'd like to see if there is a general consensus emerging
on this topic.  I've noticed that I rarely see FQNs
in the JDK sources.  I'm curious if their style guide
mentions this topic.  Is there a consensus emerging in
Java books?  Clearly there will be individual differences
of opinion, just as there are with wildcard imports, but,
do we see a consensus emerging? 

Regarding

    On the contrary by introducing simple names which are used at only a
    few places, the boundary between external symbols and those inherited
    or defined locally in the file will vanish, confusing the user.

again, is there any data to support these conclusions?  They 
definitely don't agree with my experiences, but we may have
different perspectives.

A significant problem I have with a threshold is the "creep factor".
Say you start with just two refernces and make them FQNs.  Over time
more references are added but just one or two at a time.  Evenutally
you have 8 or 10 and they are all FQNs.  The threshold notion requires
the developer to keep a mental count and then change the style when
the threshold is crossed.  Of course, the problem does not apply to
the user who uses IMT, but does for the co-worker who is doing the
work manually.

Can you please supply the data of your analysis
that concluded that a threshold value of 4 is 
correct?

Meanwhile, I'll reopen the bug.

> again, is there any data to support these conclusions?  They 
> definitely don't agree with my experiences, but we may have
> different perspectives.
Evan, we definitely have different perspectives. I use the IDE to
write production code, every day; since I don't believe (from my past
experiences) that a moderately advanced (in the terms of today's
market) GUI application's or a client/server one's code is less
complex than that of a single NetBeans module, I think I can well
approximate needs of a programmer in an average software company. 
On the other hand, I don't expect you to write java code daily in such
amounts and with the same expectations.

> the threshold is crossed.  Of course, the problem does not apply 
> to the user who uses IMT, but does for the co-worker who is doing
> the work manually.
This is actually why should we have the IMT, IMHO. At the time the
user *feels* that he wrote too much referencies to an item, the IMT
will straight the code for her. Sure that the user can use FastImport
feature at all times she writes a new identifier. I assumed that she
will then change the default in IMT if that is the preferred working
style.

BTW -- we COULD do something for the user (but that would need to be
carefully though out): if the user gives us a bunch of code, we could
be able to autoconfigure code generation tools, indentation, ...
according to the patterns found in there. This has one interesting
advantage: the user will *tell* the IDE what she believes is good and
what to learn from. But it may be too much of work for only a little
benefit (one-time setup of the IDE).

It seems that we need more solid (and accurate) data or explanation in
order to persuade you - and I simply do not have so much time as you
seem to have for this issue.
If you feel your experience is sufficient to create a styleguide,
let's do it that way - at your discretion of course and with possible
subsequent fixes to the style being your responsibility.

Note [off topic to the actual discussion]:
I ask you to re-evaluate the type of the issue. It is not a defect
according to the current plans or intentions of what the IMT should
do. Your point of view (re. what is a defect or enhancement) seem a
way different from those of other java module issue reporters judging
from other issues filed for us; filing the issue as DEFECT leads
people to a conclusion that the functionality is broken rather than
you don't agree with the way how the tool functionality was designed.

There seems to be four points:

1) You are a programmer and I'm a manager, therefore,
   my experience is not as important.

2) How was the current threshold determined -- feelings or
   data?

3) Is this a bug or an enhancement request?

4) What is the proper default for the threshold?


The fourth one is main point of this issue, but we need to
discuss all of them.

1) You are a programmer and I'm a manager.
I don't like making issues personal and will try to
avoid doing so with this issue.

This point is irrelevant to the issue at hand.
Clearly, you program on a daily basis and I no longer
do.  However, I been in the business for 24 years,
21 of them as an implementor, 4 years in Java.  My
entire career has been spent in tools, writing programs
for programmers.  It is very likely that I have written
as much or more production Java code as you have.  This
is irrelevant, but those are the facts.

2) How was the current threshold determined -- feelings or
   data?
You stated very clearly that the decision to set the threshold
to 4 was NOT based on your feelings, yet, despite two requests
in this issue, you have not provided any concrete data to support
that conclusion.  Given your assertion that you can approximate
the needs of the average developer, I can only conclude that the
threshold is set to 4 because Svata "feels" that is the right
value. 

I have asked a small number of other programmers (daily programmers)
and so far no one has agreed with this setting.  This is
not conclusive data.

If you have data to support this conclusion, please provide it.

3) Is this a bug or an enhancement request?
Svato, we've had this debate in other forums.  I file bugs
like these because my goal is to make the IDE as usable and
powerful as possible for our users.  Implementing the functionality
is only part of the overall picture.  Making the functionality
usable, setting the proper defaults, exposing the right amount
of information and hiding the right amount of information are
all essential to the overall success of the IDE and the functionality.

The import management tool contains some very good functionality,
however, it is much too hard to use.  That's why filed ~10
bugs against it.

Please don't take these bugs personally.  They are not a 
reflection on your abilities as a programmer.  If the UI spec
has been faithfully implemented then that's a Good Thing.
If the result is not usable, then we have a bug in the UI
spec.  Rather than being concerned with bug vs enhancement
we should be concerned with making the functionality usable
for a large set of our users.  Proper defaults are crucial.

I know the game that is played with Bugs vs Enhancements.
We track Bugs and work to lower bug counts.  We don't track
enhancments.  By changing an issue to an enhancment it often
goes to the graveyard, never to be heard of again.  My goal
is to make the functionality useful, make the IDE more useful,
and to provide our users with a better product.  Merely implementing
functionality is not enough -- its needs to be usable.

4) What is the proper default for the threshold?
This is the primary point of the issue.  I believe (one of
those words you don't like) that more programmers would 
be happy with an IMT that eliminated all FQNs.  Therefore,
I believe that is the proper default.  I'm still looking
for hard data that demonstrates that programmers want some
FQNs and that 4 is the appropriate value.  I'm asking
again for you to provide the data that determined the
default value.

I feel that FQNs make code harder to read, harder to maintain,
add visual clutter, make the lines longer, etc.  In conclusion
they are less desirable than import statements.

I'll be happy to start a discussion about this on nbdev,
no nbusers is the right place, however, I don't believe 
that voting on the aliases is the right way to make decisions.
The discussion will give us data.


A final meta comment.  I filed issue 23886 because I think
the overall UI of IMT is too complex.  It shows me more information
that I need/want and gives me too many choices.  I find it
hard to imagine that developers want to make the decisions
on a per-class basis.  However, this is an categorized as
an enhancement, so I have little hope for its future.

Reopening to set resolution to FIXED.

I am sorry, last comment was added by mistake.

Evan, I have few comments.
1) IMT is designed to work on long files, which are at least few
hundreds lines long. From your comments and others issues you reported
I guess that you are using it on small files. For such files you don't
need IMT. As Svata already told you with your setting ( eliminate all
FQN ) you will get lots of imports and this is not good. 
2) AFAIK There is no style guide how to use FQN/imports. 
3) Default was selected based on the NetBeans code. As you can check
there NetBeans code uses FQN relatively often.
4) We do not take this personally. If we did, we will change the
default without complaint, since you are _manager_.
5) I worry about one thing. Suppose that we will change the default to
0 and someone reports issue that he do not like this new default. What
will we do? 
6) I guess that it is mainly your responsibly to convince us that
current default is wrong no that we should prove that your is right. 
7) Majority of your bugs filled against IMT are in fact not bugs in
IMT, but bugs in code IMT uses. I do not want to say that these should
not be fixed, but I just want to get this right.
8) I also feel this is not a bug - definitely not P3 bug, but
enhancement, especially considering the fact that there is not hard
evidence for either solution. 
9) I think that this issue is not so important. It is just default. If
you don't like it change it.
10) IMT and its default value for FQN is there almost a year and a
half and no one complained, so I guess again it is not so important.

To be a little positive I offer you compromise solution to lower the
default from 4 to 2.

Tomas,
(I know that being a manager myself I am stepping on a thin ice if I dare to comment here :-)

I wander if you read the comments that Evan made before writting your replay. Evan explains why he thinks 
that this IS a bug and not an enhancement. He explains that he sees this being important  since users do 
not find is useful with the current default. You are saying: this is an enhancement, this is _just_ a 
default, you have to convince us that we should change it.

I think that we should be thankful to our users for reporting bugs, not ask them to provide evidence for 
a different design in return for it. I agree with Evan that a poor usability or UI design is at a bug. 
I understand that it is hard to tell what poor means in this area, there are no Exceptions, no deadlocks, 
etc. But removing exceptions and deadlocks is not the only measure of quality.

I see at least some progress: you are saying that the data you use is the NetBeans code. Then run the 
analyses and prepare the data about NetBeans code. Do the same for JDK soucres. Do it on an "average" 
application written in Java if you have some. Or prepare the tests and ask people at nbusers to run them 
on their apps. I believe that this is pretty straightforward to implement such a test. Then you will have 
the data and you do not have to fear about what you have described in your point #5.

On your last comment: The goal is not to make Evan happy by making a compromise, the goal is to make this 
feature more useful.

Svata has requested a style guide.  This is a good request.  I propose that
the style guide for the default behaviour of the NetBeans IDE is to follow
the JDK style guide (see http://java.sun.com/docs/codeconv/).  This was done
when we first open sourced the NetBeans sources.  Originally, the NetBeans
sources were written with 2-space indentation and this was changed to 4-space 
indentation to match the JDK coding style.

Pavel makes a very good suggestion to analyze the JDK and NetBeans sources
as a way of gathering information.  I quickly searched through the JDK
style guide and found no mention of imports and fully-qualified names, so
I don't think the style guide takes a position on this issue.  However, 
the body of code can tell us plenty.  

Now to reply to Tomas's comments:

>    1) IMT is designed to work on long files, which are at least few
>    hundreds lines long. From your comments and others issues you reported
>    I guess that you are using it on small files. For such files you don't
>    need IMT. As Svata already told you with your setting ( eliminate all
>    FQN ) you will get lots of imports and this is not good. 

I don't think that the length of the file is an issue here.

The basic disagreement is over the comment "you will get lots of imports 
and this is not good".  I've worked on files with 40 or more imports.
They don't cause a problem as they are all grouped at the top of the
file.  Specifying them all can be a hassle and is one of the reasons
some people prefer wildcard imports (not my preference, but that's a
different topic).  Specifying is where IMT can provide real value.
Also, I expect that code folding will be able to hide the import statements,
further making the total number irrelevant. 

Why are lots of imports not good?  What problems do they cause?

I don't buy the argument that imports should indicate symbols that
are intrinsic to the coded problem or that 4 uses indicate that 
symbols are intrinsic.  If a class extends another, then the base
class is intrinic to the coded problem, however, it is likely that
the only mention of the base class name is after "extends", for example,
JButton extends AbstractButton and AbstractButton is mentioned just
once, and AbstractButton extends JComponent and JComponent is mentioned
just twice.  Neither of these files use FQNs for the base class.

Similarly, Collection and IO classes are more utility class than intrinsic
yet they are often frequently used, thereby, justifying import statements under
the current defaults.

Finally, I find code such as:

    javax.swing.JButton btn = new javax.swing.JButton("OK");

not as easy to work with as:

    import javax.swing.JButton;
    ...
    JButton btn = new JButton("OK");

Generally, I don't spend time reading the import statements,
so I place a higher value on the readability of the code.

>    2) AFAIK There is no style guide how to use FQN/imports. 

Agreed.  I did not find it in the JDK style guide.  Pavel's
suggestion to analyze the JDK code is a good one.  In my 
travel through the JDK code I don't recall seeing very much
use of FQNs.

>     3) Default was selected based on the NetBeans code. As you can check
>    there NetBeans code uses FQN relatively often.

I think the JDK code should be our guide, not the NetBeans code.

>    4) We do not take this personally. If we did, we will change the
>    default without complaint, since you are _manager_.

:-)  I'm filing these issues as a user, not a manager. 

>    5) I worry about one thing. Suppose that we will change the default to
>    0 and someone reports issue that he do not like this new default. What
>    will we do? 

This is not unique to IMT, this applies to every property setting in
the IDE.  And you have this problem right now.  

The answer is quite simple:  explain to the user how the setting
was chosen, the research that was done and the motivation for the
default setting.

If you tell a user that the defaults are set to follow the JDK
coding style and that the JDK sources were analyzed to see how
imports and FQNs are used, then that will be a fairly compelling
answer.  If you tell the user that feelings were not used, but
you can't (or won't) explain how the default was chosen, then you'll
have an unhappy user (personal experience).

>    6) I guess that it is mainly your responsibly to convince us that
>    current default is wrong no that we should prove that your is right. 

I've been explaining why I think FQNs are not a good thing.  They add
clutter to the code, making it less readable and less maintainable, and
make lines longer.  Do you think that:

    javax.swing.JButton btn = new javax.swing.JButton("OK");

is more readable and understandable than:

    JButton btn = new JButton("OK");

When I'm reading code and I come to a variable declaration I don't
(usually) care which package the variable is from, I care about its
type.  If I need to know the package, I'll look at the imports.

>    7) Majority of your bugs filled against IMT are in fact not bugs in
>    IMT, but bugs in code IMT uses. I do not want to say that these should
>    not be fixed, but I just want to get this right.

No problem, I understand.  As a user of IMT, I can't easily tell
where the underlying problems are.  I care about how the problems
affect our users and I want the IDE to be more useful and usable than
our competitors.

>    8) I also feel this is not a bug - definitely not P3 bug, but
>    enhancement, especially considering the fact that there is not hard
>    evidence for either solution. 

Producing code that is harder to read is a bug.
I believe the JDK sources will show hard evidence.

>    9) I think that this issue is not so important. It is just default. If
>    you don't like it change it.

"It is just default" is a very disturbing attitude.  Getting defaults
correct is *extremely* important.  Believe it or not, most users will
never change any defaults, they use a product as it is delivered.  Expert
users will change some, often lots of them.  Defaults need to be choosen
taking this into consideration and ensuring that "common things are easy
and that other things are possible".  A poor default sends a bad message
to a new user about the overall product.

This is an important issue if you want to make the functionality more
usable.  Remember the "I" in IDE.  There is some very nice functionality
in the IMT, but it is not integrated very well.  Some of the user interface
suggests that "ease of implemention" rather than "ease of use" was the primary
goal (values being displayed in buttons that didn't do anything [23895], column
titles being truncated [23894], equal width columns when the data is not
equal-width data [23894 again], etc.).

>    10) IMT and its default value for FQN is there almost a year and a
>    half and no one complained, so I guess again it is not so important.

Not a good argument.  I strongly suspect the IMT functionality is not
very well known.

>    To be a little positive I offer you compromise solution to lower the
>    default from 4 to 2.

I agree with Pavel, the goal is not to make me happy with a compromise,
rather to make the functionality more useful.

Set target milestone to TBD

I started a discussion about this topic on nbusers.
There were a small number of replies, 5, and the
unanimously in favor of using FQNs only in the case
of conflicts. 

My summary post to nbusers is at
http://www.netbeans.org/servlets/ReadMsg?msgId=353651&listName=nbusers

From that post here's what the respondents had to say:
Pascal Fleury:
    So use of FQN should be only when there are conflicts
    (very rare). The code becomes much less verbose, and
    decreases the horizontal scrolling quite a bit. Code
    becomes clearer, that's what matters to me.

John Richardson:
    Like everyone else so far, I've never seen fully qualified
    names used, except for conflicts.

David Smith:
    ... and only use a fully qualified name (FQN) in the code
    to resolve ambiguities. In practice ambiguities rarely
    happen and can be removed with a little refactoring.
    The problem (IMHO) with using a FQN is that it stands out
    and makes that piece of code look special in some way.

Peter Kelley:
    ... is that we never use fully qualified names in the code
    if we can avoid it. [...] Adding the package name just
    clutters up the code with information that you could easily
    determine otherwise. 

Done in trunk. Default value changed to zero.

i, personally, preferred the old method.

Verified in 200210090100