GRECLIPSE

Organize Imports does not sort by type name ascending

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.7.0.Release
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

In the following script:

import javax.script.Compilable
import javax.script.Bindings
import javax.script.AbstractScriptEngine

println AbstractScriptEngine
println Bindings
println Compilable

Organize Imports does not sort the import statements by type name ascending.

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. GRECLIPSE-1391 Organize Imports does remove blank lines in import group

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.
relates to

Bug - A problem which impairs or prevents the functions of the product. GRECLIPSE-1219 Annotations on import statements are removed after organize imports is called

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrew Eisenberg added a comment -

Looks like this is a regression that has come from the work on GRECLIPSE-1219.

Show
Andrew Eisenberg added a comment - Looks like this is a regression that has come from the work on GRECLIPSE-1219 .
Hide
Permalink
Andrew Eisenberg added a comment -

Urrrgh...this is going to be messy. In order to ensure that annotations on imports are not removed while still enabled sorting, I must muck around with JDT code so that annotations are remembered for each import statement. When imports are re-organized, the annotations would not be lost.

However, this is a big piece of work. I am leaning towards a simple-half solution:

Before performing the organize, check all import statements for annotations. If they exist, don't reorganize, but just add and remove. If no annotations (the more likely scenario), do a full organize.

This is not the ideal solution, but it is safer, less work, and does not require making the JDT patch any larger.

Show
Andrew Eisenberg added a comment - Urrrgh...this is going to be messy. In order to ensure that annotations on imports are not removed while still enabled sorting, I must muck around with JDT code so that annotations are remembered for each import statement. When imports are re-organized, the annotations would not be lost. However, this is a big piece of work. I am leaning towards a simple-half solution: Before performing the organize, check all import statements for annotations. If they exist, don't reorganize, but just add and remove. If no annotations (the more likely scenario), do a full organize. This is not the ideal solution, but it is safer, less work, and does not require making the JDT patch any larger.
Hide
Permalink
Andrew Eisenberg added a comment -

Fixed as described in the previous comment. This fix is a reasonable compromise since annotations on imports are fairly rare (usually @Grab), but when they do exist we need to make sure that they are not removed during organize imports.

Show
Andrew Eisenberg added a comment - Fixed as described in the previous comment. This fix is a reasonable compromise since annotations on imports are fairly rare (usually @Grab), but when they do exist we need to make sure that they are not removed during organize imports.
Hide
Permalink
Bob Tiernay added a comment - - edited

Very reasonable Andrew. I can live with it Thanks

Show
Bob Tiernay added a comment - - edited Very reasonable Andrew. I can live with it Thanks

People

  • Assignee:
    Andrew Eisenberg
    Reporter:
    Bob Tiernay
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: