Eclipse Community Forums: Java Development Tools (JDT) » Calling Refactorings Programmatically

Home » Language IDEs » Java Development Tools (JDT) » Calling Refactorings Programmatically

Calling Refactorings Programmatically [message #245512]

Wed, 11 July 2007 13:43

Eclipse User

I want to use Eclipse refactorings programmatically. As far as I can see
the only way to do this is to use internal classes.

For example to rename a compilation unit I would need to use

org.eclipse.jdt.internal.corext.refactoring.rename.RenameCom pilationUnitProcessor

Is this correct? That I can only use the refactorings that Eclipse ships
by using internal classes?

If so does this break the guidelines for using the Eclipse API as outlined
on this page?

http://www.eclipse.org/articles/article.php?file=Article-API -Use/index.html

If so, does this mean that one cannot safely use Eclipse refactorings
programmatically?

On a related note, with regards developing custom refactorings I see even
Tobias Widmer in his article "Unleashing the Power of Refactoring"

http://www.eclipse.org/articles/article.php?file=Article-Unl eashing-the-Power-of-Refactoring/index.html

uses internal classes (org.eclipse.jdt.internal.corext.dom.NodeFinder) in
order to develop his custom refactoring.

Once again, is this not bad practice at a minimum and unsafe with regards
it breaking when running against future releases of Eclipse due to
dependencies on internal API?

I want to develop some custom refactorings - is it just the case that in
order to develop custom refactorings I will more than likely need to use
some internal classes? And the best I can do is to request any internal
API I use to be put into the published API in the future and fix things
down the line, whilst in the meantime dealing with any breakage in the
code between Eclipse releases due to dependencies on internal API?

Any help greatly appreciated,

Thanks,

Máirtín

Re: Calling Refactorings Programmatically [message #245652 is a reply to message #245512]

Fri, 13 July 2007 04:36

Eclipse User

Originally posted by: jacek.pospychala.pl.ibm.com

Máirtín,
You're right, accessing RenamCompilationUnitProcessor directly from your
code is not a good idea.
Please take a look at org.eclipse.ltk (Refactoring Language Toolkit)
framework. Also this article should give you some hints on how to use
refactorings:
http://www.eclipse.org/articles/article.php?file=Article-Unl eashing-the-Power-of-Refactoring/index.html

Máirtín wrote:
> I want to use Eclipse refactorings programmatically. As far as I can
> see the only way to do this is to use internal classes.
>
> For example to rename a compilation unit I would need to use
>
> org.eclipse.jdt.internal.corext.refactoring.rename.RenameCom pilationUnitProcessor
>
>
> Is this correct? That I can only use the refactorings that Eclipse
> ships by using internal classes?
>
>
> If so does this break the guidelines for using the Eclipse API as
> outlined on this page?
>
> http://www.eclipse.org/articles/article.php?file=Article-API -Use/index.html
>
>
> If so, does this mean that one cannot safely use Eclipse refactorings
> programmatically?
>
>
>
>
>
> On a related note, with regards developing custom refactorings I see
> even Tobias Widmer in his article "Unleashing the Power of Refactoring"
>
> http://www.eclipse.org/articles/article.php?file=Article-Unl eashing-the-Power-of-Refactoring/index.html
>
>
> uses internal classes (org.eclipse.jdt.internal.corext.dom.NodeFinder)
> in order to develop his custom refactoring.
>
> Once again, is this not bad practice at a minimum and unsafe with
> regards it breaking when running against future releases of Eclipse
> due to dependencies on internal API?
> I want to develop some custom refactorings - is it just the case that
> in order to develop custom refactorings I will more than likely need
> to use some internal classes? And the best I can do is to request any
> internal API I use to be put into the published API in the future and
> fix things down the line, whilst in the meantime dealing with any
> breakage in the code between Eclipse releases due to dependencies on
> internal API?
>
>
>
>
> Any help greatly appreciated,
>
> Thanks,
>
> Máirtín
>

Re: Calling Refactorings Programmatically [message #245662 is a reply to message #245652]

Fri, 13 July 2007 05:22

Eclipse User

Jacek Pospychala wrote:

> Also this article should give you some hints on how to use
> refactorings:
>
> http://www.eclipse.org/articles/article.php?file=Article-Unl eashing-the-Power-of-Refactoring/index.html

Yes, I had a look at that article:

> Máirtín wrote:
>> On a related note, with regards developing custom refactorings I see
>> even Tobias Widmer in his article "Unleashing the Power of Refactoring"
>>
>>
http://www.eclipse.org/articles/article.php?file=Article-Unl eashing-the-Power-of-Refactoring/index.html
>>
>>
>> uses internal classes (org.eclipse.jdt.internal.corext.dom.NodeFinder)
>> in order to develop his custom refactoring.
>>
>> Once again, is this not bad practice at a minimum and unsafe with
>> regards it breaking when running against future releases of Eclipse
>> due to dependencies on internal API?
>> I want to develop some custom refactorings - is it just the case that
>> in order to develop custom refactorings I will more than likely need
>> to use some internal classes? And the best I can do is to request any
>> internal API I use to be put into the published API in the future and
>> fix things down the line, whilst in the meantime dealing with any
>> breakage in the code between Eclipse releases due to dependencies on
>> internal API?
>>

And my point was that even in this article Tobias Widmer uses internal
classes - so my question was is it the case that it is virtually
impossible to use refactorings that are provided by Eclipse
programmatically without using internal classes.

Re: Calling Refactorings Programmatically [message #245682 is a reply to message #245662]

Fri, 13 July 2007 06:32

Eclipse User

Originally posted by: jacek.pospychala.pl.ibm.com

Máirtín,

I wonder, if this is the preferred way, but you may try the following
code to create a refactoring through API:

ICompilationUnit cu = ... // an ICompilationUnit to rename

RefactoringContribution contribution =
RefactoringCore.getRefactoringContribution(IJavaRefactorings .RENAME_COMPILATION_UNIT);
RenameJavaElementDescriptor descriptor =
(RenameJavaElementDescriptor) contribution.createDescriptor();
descriptor.setProject(cu.getResource().getProject().getName( ));
descriptor.setNewName("NewClass"); // new name for a Class
descriptor.setJavaElement(cu);

RefactoringStatus status = new RefactoringStatus();
try {
Refactoring refactoring = descriptor.createRefactoring(status);

IProgressMonitor monitor = new NullProgressMonitor();
refactoring.checkInitialConditions(monitor);
refactoring.checkFinalConditions(monitor);
Change change = refactoring.createChange(monitor);
change.perform(monitor);

} catch (CoreException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

Máirtín wrote:
> Jacek Pospychala wrote:
>
>> Also this article should give you some hints on how to use refactorings:
>>
>> http://www.eclipse.org/articles/article.php?file=Article-Unl eashing-the-Power-of-Refactoring/index.html
>>
>
> Yes, I had a look at that article:
>
>> Máirtín wrote:
>>> On a related note, with regards developing custom refactorings I see
>>> even Tobias Widmer in his article "Unleashing the Power of Refactoring"
>>>
>>>
> http://www.eclipse.org/articles/article.php?file=Article-Unl eashing-the-Power-of-Refactoring/index.html
>
>>>
>>>
>>> uses internal classes
>>> (org.eclipse.jdt.internal.corext.dom.NodeFinder) in order to develop
>>> his custom refactoring.
>>>
>>> Once again, is this not bad practice at a minimum and unsafe with
>>> regards it breaking when running against future releases of Eclipse
>>> due to dependencies on internal API?
>>> I want to develop some custom refactorings - is it just the case
>>> that in order to develop custom refactorings I will more than likely
>>> need to use some internal classes? And the best I can do is to
>>> request any internal API I use to be put into the published API in
>>> the future and fix things down the line, whilst in the meantime
>>> dealing with any breakage in the code between Eclipse releases due
>>> to dependencies on internal API?
>>>
>
> And my point was that even in this article Tobias Widmer uses internal
> classes - so my question was is it the case that it is virtually
> impossible to use refactorings that are provided by Eclipse
> programmatically without using internal classes.
>

Re: Calling Refactorings Programmatically [message #245692 is a reply to message #245682]

Fri, 13 July 2007 07:17

Eclipse User

Jacek Pospychala wrote:

> I wonder, if this is the preferred way, but you may try the following
> code to create a refactoring through API:

> ICompilationUnit cu = ... // an ICompilationUnit to rename

> RefactoringContribution contribution =
>
RefactoringCore.getRefactoringContribution(IJavaRefactorings .RENAME_COMPILATION_UNIT);
> RenameJavaElementDescriptor descriptor =
> (RenameJavaElementDescriptor) contribution.createDescriptor();
> descriptor.setProject(cu.getResource().getProject().getName( ));
> descriptor.setNewName("NewClass"); // new name for a Class
> descriptor.setJavaElement(cu);

> RefactoringStatus status = new RefactoringStatus();
> try {
> Refactoring refactoring = descriptor.createRefactoring(status);

> IProgressMonitor monitor = new NullProgressMonitor();
> refactoring.checkInitialConditions(monitor);
> refactoring.checkFinalConditions(monitor);
> Change change = refactoring.createChange(monitor);
> change.perform(monitor);

> } catch (CoreException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }

Thanks, I'll give that a try for using Eclipse's refactorings.

Re: Calling Refactorings Programmatically [message #246998 is a reply to message #245682]

Thu, 23 August 2007 09:31

Eclipse User

Jacek Pospychala wrote:

> Máirtín,

> I wonder, if this is the preferred way, but you may try the following
> code to create a refactoring through API:

> ICompilationUnit cu = ... // an ICompilationUnit to rename

> RefactoringContribution contribution =
>
RefactoringCore.getRefactoringContribution(IJavaRefactorings .RENAME_COMPILATION_UNIT);
> RenameJavaElementDescriptor descriptor =
> (RenameJavaElementDescriptor) contribution.createDescriptor();
> descriptor.setProject(cu.getResource().getProject().getName( ));
> descriptor.setNewName("NewClass"); // new name for a Class
> descriptor.setJavaElement(cu);

> RefactoringStatus status = new RefactoringStatus();
> try {
> Refactoring refactoring = descriptor.createRefactoring(status);

> IProgressMonitor monitor = new NullProgressMonitor();
> refactoring.checkInitialConditions(monitor);
> refactoring.checkFinalConditions(monitor);
> Change change = refactoring.createChange(monitor);
> change.perform(monitor);

> } catch (CoreException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> } catch (Exception e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }

I am using the code above to call the refactoring that Eclipse provides to
rename a compilation unit.

I would like to be able to get a list of the files that the refactoring is
about to modify (before it does so). So, looking at the code above, before
making a call to

change.perform(monitor);

I would like to get a handle to the list of files that are about to be
changed.

Is there a way of getting a hold on this list of files without carrying
out the search again myself?

I see that internally the class

org.eclipse.ltk.core.refactoring.participants.RenameRefactor ing

(which is extended by JavaRenameRefactoring) has a reference to a

org.eclipse.jdt.internal.corext.refactoring.rename.RenameCom pilationUnitProcessor

which has a reference to a

org.eclipse.jdt.internal.corext.refactoring.rename.RenameTyp eProcessor

which contains a field

private SearchResultGroup[] fReferences

that contains the list to all the references to that will be updated by
this refactoring.

The method

initializeReferences

from the class

org.eclipse.jdt.internal.corext.refactoring.rename.RenameTyp eProcessor

contains the code that carries out the search for these references. I
would rather not have to recreate this myself, not only to save on
duplicate code but this code also uses internal classes which I do not
want to use.

Does anyone know if it is possible to get a handle on the list of files
that are about to be modified without carrying out the search myself?

Or is there any way through the public API that I can get the same
functionality as the method initializeReferences?

Thanks,

Máirtín

Re: Calling Refactorings Programmatically [message #749370 is a reply to message #246998]

Tue, 25 October 2011 03:18

Eclipse User

Hi all, Máirtín
As you Máirtín I want to program some custom refactorings.
I read the paper of Tobias Widmer and also the blog from Anulfor Rodriguez.
But I have still some general questions

1) Is there a more recent document on ingineering refactoring in Eclipse ?
(the Java doc is not the best to understand the global process).

2) How to easily reuse and extend or specialise the existing JDT refactoring?
Is there an another way than using org.eclipse.jdt.ui.refactoring.*Descriptors ?

3) I need to pipe several refactoring actions, How to do that efficiently
with the change mechanism ?
(the existing scripting mechanism does not seem adequate)

any help is welcome
regards

Previous Topic:	JadClipse not opening class files
Next Topic:	how to change the line background color when my mouse move it

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Jul 13 17:40:37 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter