knut, your sort idea is how we used to sort our imports - core java
first, then other parties, then ours. The current import declaration
sort feature is close to that as is, because java.* sort together,
com.* sort together, etc. Mainly, I had to just move the java.*,
javax.* sections to the top.
Most important is to make them organized (by alphabetizing) for human
factors. White space between sections is good too (compare 1st and
2nd level domain sections). This would be a nice addition to the sort
routine.
I did not see a reply to my question if Paul had wanted/thought of a
config for specifying the type of import declaration
(single-type-import or type-import-on-demand). I was just this
weekend looking into how to add that. I found where, determined how,
started the code, and am currently stuck - my lisp is so
beginner-status that I could not yet figure out how to set the results
of a concat to a variable. This is a good first try for me...will
resolve sometime soon of course (any tips welcome!).
This type of statement: > Global imports really can cause problems and
definatly slow down compiles. is a strong statement and I have yet to
see it justified with Java and find it misleading. This is a first I
have heard that it is slower. Do you have actual test results that
Java compiles slower with type-import-on-demand? I will have to try
an experiment some time.
Some people confuse what import does with what #include does. With
C/C++, #includes actually add code to the source file, and therefore
there is more to compile - can be slower if it is a lot of code. With
Java, import is simply telling the compiler how to resolve class short
name use to the fully qualified name. (<rant>I dislike the name
import; I wish something like "ref" or "refersto" or "link" or "uses"
or something that clearly states what import does was used
instead</rant>).
I did not look at compiler implementations for this - does it take
longer to resolve to the fully qualified name with on-demand?
As a style issue, listing each class is more of a maintenance
nightmare than any benefit (class collisions are very rare; import
statements are not a reliable source of class dependencies). The new
JDE features to clean up the import list goes a long way to help this,
though. Thanks for creating it!
> From: "Schewe, Jon (MN65)" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: RE: A command to kill extra import statements
> Date: Mon, 30 Oct 2000 08:04:46 -0600
>
> Some people really don't like global imports, so if some threshhold was put
> in, make sure there is a setting that allows them to never show up.
>
> Global imports really can cause problems and definatly slow down compiles.
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, October 30, 2000 1:46 AM
> > To: [EMAIL PROTECTED]
> > Subject: RE: A command to kill extra import statements
> >
> >
> > I haven't been able to get the jde-kill-extra-imports to
> > work. Is there
> > anything else besides a load-file? But there is a feature
> > that I would like
> > to suggest: It would be nice if there was a configurable
> > treshold which
> > would limit the number of classes imported from the same
> > package. That is to
> > say, if for instance more than 5 classes are imported from
> > java.util the
> > jde-kill-extra-imports would replace them all with the global
> > package import
> > statement.
> > And as a further feature for jde-sort-imports it would maybe
> > be nice if the
> > classes supplied by the jre (rt.jar) could be listed
> > separately, above other
> > imports. And then maybe even let the user further separate
> > the rest of the
> > imports given some rule. This could be used to separate
> > corporate classes
> > from third party classes. That way the sort would split up
> > the imports into
> > several sorted blocks.
> >
> > --
> > knut
> >
>
