[jdt-ui-dev] Re: OOPSLA *2001* "Implementing Refactoring Support..." pap

["Adam Kiezun" <Adam_Kiezun@xxxxxxx>]

>Hmmm, at the University of Hamburg in the software engineering department,
>we just started a project in an XP like fashion (a team project...), where
>we will take Eclipse as our underlayed Java IDE for research.

>My part inside this team is actually to prepare a sort of presentation for
>the other team members about the Eclipse Refactoring API. What should I
tell
>them now? Should I tell them that there is actually no Refactoring API
>inside Eclipse?

there's an important difference between external API and internal api -
best described in:
http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html

as of now, the only external API that refactoring provides are actions
(that you can use to perform a given refactoring)

that said, you can use a lot of the same infrastructure that we use:
- SearchEngine (from the jdt.core plugin) to efficiently and accurately
find references and declaration of things
- ASTs (same jdt.core plugin) to analyze and transform programs
(these are official APIs)

our internal infrastucture, like the text manipulation, AST rewriting or
refactoring wizard 'mini-framework'
is, as said, internal but has been stable for months now (AST rewriting is
new but reliable and stable so far)
So, for research purposes you can use any of these.

Apart from the above-mentined external APIs you may want to look at the
following internal classes (and their hierarchies):
 - TextEdit
- Refactoring
 - IChange
- RefactoringStatus
- RefactoringWizard
- ASTRewrite

(all of them are quite stable)

>So how is all the actual Refactoring support inside Eclipse then setup?
The
>OOPSLA 2001 paper somehow suggerated to me a sort of existing API, even
the
>term API hasn't been used inside that paper.
>It would be nice if you could provide me at least with some more details
>about the actual build in Refactoring scheme of Eclipse, so I can write
>something down for my presentation and for our team discussion.

the overal design is a bit similar to Don Roberts' smalltalk refactoring
browser.
the scheme is:
- collect the info from the user
- check preconditions
- create a change object to represent the modifications
- perform the changes

>BTW, where you say there isn't any API actually, how can we then reuse the
>Eclipse refactoring infrastructure for own enhancements or refactoring
>addons? That's what I usually want to do for Eclipse during our University
>project.

I'd start by looking at how the already existing refactorings are
implemented - for simple examples look at:
SelfEncapsulateField or PromoteTempToField

don't  hesitate to ask if you have  more questions
a.