Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 123755

Summary:

[introduce indirection] issues with binary targets

Product:

[Eclipse Project] JDT

Reporter:

Philip Mayer <eclipsetalk2>

Component:

Assignee:

Markus Keller <markus.kell.r>

Status:

CLOSED WONTFIX

QA Contact:

Severity:

normal

Priority:

Version:

3.2

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

stalebug

Attachments:

Description	Flags
unfinished patch	none

Description Philip Mayer

2006-01-13 08:50:17 EST

I20060110-1026 + HEAD of jdt.ui

The Introduce Indirection Refactoring can be invoked on binary target methods, which has an impact the scope of the refactoring that needs to be discussed.

When a binary target *invocation* is selected inside a user project, the scope of the refactoring is restricted to this project (as expected). However, if a binary method *declaration* is selected, the scope is unclear, as a binary method can occur in a library which may be referenced by more than one project. The actual project used is currently an arbitrary project referencing the library.

This has the following implications:
1) Code Completion does not work inside the UI, and browsing for types does not present all types of all projects (as of yet, only the types of an arbitrary project)
2) The project which is used for call updating is also arbitrary.

Possible solutions:
1) Disallow invocation on binary targets - only allow selections on invocations of binary methods, which must be in source
2) Use a workspace scope for the UI and for call updating.
3) Let user decide in UI

Comment 1 Markus Keller

2006-01-13 10:18:51 EST

I changed the search scope to
"all references who can see the declaring class of the indirection method".

Only have to make sure that the user can select all possible declaring classes in the UI.

Comment 2 Markus Keller

2006-01-16 11:53:01 EST

Created attachment 33083 [details]
unfinished patch

Removed the support for starting the refactoring in a ClassFileEditor for now (this is solution 1). The  patch holds the orignal changes, but needs further work if we want the refactoring to be available on binary classes:

- class files may have no source
  -> change in JavaTextSelection#resolvePartialAstAtOffset() is risky
- Refactor menu is class file editor is most often empty
  -> looks strange

Comment 3 Markus Keller

2006-02-09 11:48:19 EST

Defer.

Comment 4 Eclipse Genie

2018-11-25 17:52:30 EST

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.