Home » Language IDEs » Java Development Tools (JDT) » Composing Refactorings... Again
| Composing Refactorings... Again [message #242148] |
Mon, 02 April 2007 05:18  |
 Emerson Murphy-Hill
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Howdy All,
I'm looking for a mechanism to compose refactorings. I have read the
message entitled "Refactoring Composite - Parse Tree Updating" from
2002, and believe I understand Dirk's response.
What I would like to do is perform several refactorings in series. For
example, I might like to write a tool to inline variable a, then inline
variable b in the following:
int foo(){
int a = 1;
int b = 2;
return a+b;
}
Of course, just running the two refactorings after one another doesn't
quite work, because the AST changes after the first refactoring. If I
were writing the refactoring myself, I could of course use a single
ASTRewrite for both refactorings, and it would work out fine. However,
I would like to reuse the existing refactoring framework. I realize
that generally composing refactorings is unsafe (precondition issues,
etc), but in some cases (such as the one above), two refactorings mix
just fine. So... is there a class for composing refactorings that I am
missing?
Thanks in advance,
Emerson
|
|
|
| Re: Composing Refactorings... Again [message #242169 is a reply to message #242148] |
Mon, 02 April 2007 12:50  |
Eclipse User |
|
|
|
Originally posted by: jacek.pospychala.pl.ibm.com
Emerson,
There is a possibility to record refactorings as scripts in JDT.
You may find it's source code very useful.
Emerson Murphy-Hill wrote:
> Howdy All,
>
> I'm looking for a mechanism to compose refactorings. I have read the
> message entitled "Refactoring Composite - Parse Tree Updating" from
> 2002, and believe I understand Dirk's response.
>
> What I would like to do is perform several refactorings in series. For
> example, I might like to write a tool to inline variable a, then inline
> variable b in the following:
>
> int foo(){
> int a = 1;
> int b = 2;
> return a+b;
> }
>
> Of course, just running the two refactorings after one another doesn't
> quite work, because the AST changes after the first refactoring. If I
> were writing the refactoring myself, I could of course use a single
> ASTRewrite for both refactorings, and it would work out fine. However,
> I would like to reuse the existing refactoring framework. I realize
> that generally composing refactorings is unsafe (precondition issues,
> etc), but in some cases (such as the one above), two refactorings mix
> just fine. So... is there a class for composing refactorings that I am
> missing?
>
> Thanks in advance,
>
> Emerson
|
|
|
| Re: Composing Refactorings... Again [message #242217 is a reply to message #242169] |
Mon, 02 April 2007 18:26 |
Emerson Murphy-Hill
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Thanks for the reply, Jacek.
After debugging the scripting system, it doesn't quite do what I need.
In it, a new PerformRefactoringOperation is built and applied for each
refactoring. Instead, I have a list of ASTNodes, can build Refactorings
based on each, then execute all the Refactorings using a
CompositeChange. As I said, Changes interfere with each other.
So I think the answer to my question is that there is no such easy
object to compose refactorings. Instead, I will have to execute
refactorings one-by-one, each time finding new ASTNodes based on my old
ones (probably using ASTMatcher).
Thanks,
e
Jacek Pospychala wrote:
> Emerson,
> There is a possibility to record refactorings as scripts in JDT.
> You may find it's source code very useful.
>
> Emerson Murphy-Hill wrote:
>
>> Howdy All,
>>
>> I'm looking for a mechanism to compose refactorings. I have read the
>> message entitled "Refactoring Composite - Parse Tree Updating" from
>> 2002, and believe I understand Dirk's response.
>>
>> What I would like to do is perform several refactorings in series.
>> For example, I might like to write a tool to inline variable a, then
>> inline variable b in the following:
>>
>> int foo(){
>> int a = 1;
>> int b = 2;
>> return a+b;
>> }
>>
>> Of course, just running the two refactorings after one another doesn't
>> quite work, because the AST changes after the first refactoring. If I
>> were writing the refactoring myself, I could of course use a single
>> ASTRewrite for both refactorings, and it would work out fine.
>> However, I would like to reuse the existing refactoring framework. I
>> realize that generally composing refactorings is unsafe (precondition
>> issues, etc), but in some cases (such as the one above), two
>> refactorings mix just fine. So... is there a class for composing
>> refactorings that I am missing?
>>
>> Thanks in advance,
>>
>> Emerson
>
>
>
|
|
|
| Re: Composing Refactorings... Again [message #242222 is a reply to message #242217] |
Mon, 02 April 2007 18:47 |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Emerson Murphy-Hill" <emerson@cs.pdx.edu> wrote in message
news:eurhta$crv$1@build.eclipse.org...
> Thanks for the reply, Jacek.
>
> After debugging the scripting system, it doesn't quite do what I need. In
> it, a new PerformRefactoringOperation is built and applied for each
> refactoring. Instead, I have a list of ASTNodes, can build Refactorings
> based on each, then execute all the Refactorings using a CompositeChange.
> As I said, Changes interfere with each other.
>
> So I think the answer to my question is that there is no such easy object
> to compose refactorings. Instead, I will have to execute refactorings
> one-by-one, each time finding new ASTNodes based on my old ones (probably
> using ASTMatcher).
Also note the later comments in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=133277 - I don't know if these
are relevant to you.
|
|
|
| Re: Composing Refactorings... Again [message #242334 is a reply to message #242222] |
Wed, 04 April 2007 09:02 |
| Eclipse User |
|
|
|
Originally posted by: benno_baumgartner.ch.ibm.com
Walter Harley wrote:
> "Emerson Murphy-Hill" <emerson@cs.pdx.edu> wrote in message
> news:eurhta$crv$1@build.eclipse.org...
>> Thanks for the reply, Jacek.
>>
>> After debugging the scripting system, it doesn't quite do what I need. In
>> it, a new PerformRefactoringOperation is built and applied for each
>> refactoring. Instead, I have a list of ASTNodes, can build Refactorings
>> based on each, then execute all the Refactorings using a CompositeChange.
>> As I said, Changes interfere with each other.
>>
>> So I think the answer to my question is that there is no such easy object
>> to compose refactorings. Instead, I will have to execute refactorings
>> one-by-one, each time finding new ASTNodes based on my old ones (probably
>> using ASTMatcher).
>
>
> Also note the later comments in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=133277 - I don't know if these
> are relevant to you.
>
>
What we do in Clean Up is:
1. Create AST1 from CU
2. Create change1 based on AST1
3. Apply change1 to a working copy of CU
4. Create AST2 from working copy of CU
5. Create change2 based on AST2
6. Discard working copy
7. Create composite change (or MultiStateCompilationUnitChange)
containing change1 and change2
Hint that clean up is "smart" enough to only create a new AST when
required (when there is a conflict with a previous refactoring)
HTH
Benno
|
|
|
| Re: Composing Refactorings... Again [message #242426 is a reply to message #242334] |
Thu, 05 April 2007 00:23 |
Emerson Murphy-Hill
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Thanks for the tips, Walter and Benno! That was quite helpful, although
I haven't quite been successful yet.
I did these steps as well, until...
> 1. Create AST1 from CU
> 2. Create change1 based on AST1
> 3. Apply change1 to a working copy of CU
> 4. Create AST2 from working copy of CU
> 5. Create change2 based on AST2
Here I apply an ExtractTempRefactoring and call checkAllConditions(...),
calling checkInitialConditions(...), which assigns the refactoring's
CompilationUnit from RefactoringASTParser.parseWithASTProvider(...).
Unfortunately, parseWithASTProvider *sometimes* returns a stale AST, not
the refactored version from step 3. How does one avoid this race
condition? Or is this a bug? I can probably produce a test case, if
I'm not making any sense.
Thanks a bunch,
e
> 6. Discard working copy
> 7. Create composite change (or MultiStateCompilationUnitChange)
> containing change1 and change2
|
|
|
| Re: Composing Refactorings... Again [message #242435 is a reply to message #242426] |
Thu, 05 April 2007 05:16 |
Emerson Murphy-Hill
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Emerson Murphy-Hill wrote:
> Here I apply an ExtractTempRefactoring and call checkAllConditions(...),
> calling checkInitialConditions(...), which assigns the refactoring's
> CompilationUnit from RefactoringASTParser.parseWithASTProvider(...).
> Unfortunately, parseWithASTProvider *sometimes* returns a stale AST, not
> the refactored version from step 3. How does one avoid this race
> condition? Or is this a bug? I can probably produce a test case, if
> I'm not making any sense.
Below is some code that exposes the race. I get a NullPointerException
after 2 or 3 iterations. Is this a bug, or am I missing something?
String testClass =
"class Test{"+
" void method(){"+
" int x = 0+1+2+3+4+5+6+7+8+9;"+
" }"+
"}";
JavaTestProject project = new JavaTestProject();
IPackageFragment fragment = project.createPackage("pkg");
ICompilationUnit cu =
fragment.createCompilationUnit("Test.java", testClass, true, null);
JavaUI.openInEditor(cu);
IProgressMonitor pm = new NullProgressMonitor();
for(int i = 0; i<10; i++){
int varIndex = cu.getSource().indexOf(""+i);
ExtractTempRefactoring refactoring =
new ExtractTempRefactoring(cu,varIndex,1);
refactoring.setTempName("a"+i);
refactoring.checkAllConditions(pm);
refactoring.createChange(pm).perform(pm);
}
|
|
|
| Re: Composing Refactorings... Again [message #242443 is a reply to message #242435] |
Thu, 05 April 2007 08:42 |
| Eclipse User |
|
|
|
Originally posted by: benno_baumgartner.ch.ibm.com
Emerson Murphy-Hill wrote:
> Emerson Murphy-Hill wrote:
>> Here I apply an ExtractTempRefactoring and call
>> checkAllConditions(...), calling checkInitialConditions(...), which
>> assigns the refactoring's CompilationUnit from
>> RefactoringASTParser.parseWithASTProvider(...). Unfortunately,
>> parseWithASTProvider *sometimes* returns a stale AST, not the
>> refactored version from step 3. How does one avoid this race
>> condition? Or is this a bug? I can probably produce a test case, if
>> I'm not making any sense.
>
> Below is some code that exposes the race. I get a NullPointerException
> after 2 or 3 iterations. Is this a bug, or am I missing something?
>
> String testClass =
> "class Test{"+
> " void method(){"+
> " int x = 0+1+2+3+4+5+6+7+8+9;"+
> " }"+
> "}";
>
> JavaTestProject project = new JavaTestProject();
>
> IPackageFragment fragment = project.createPackage("pkg");
> ICompilationUnit cu =
> fragment.createCompilationUnit("Test.java", testClass, true, null);
>
> JavaUI.openInEditor(cu);
>
> IProgressMonitor pm = new NullProgressMonitor();
>
> for(int i = 0; i<10; i++){
>
> int varIndex = cu.getSource().indexOf(""+i);
>
> ExtractTempRefactoring refactoring =
> new ExtractTempRefactoring(cu,varIndex,1);
> refactoring.setTempName("a"+i);
> refactoring.checkAllConditions(pm);
> refactoring.createChange(pm).perform(pm);
> }
Hi Emerson
I can't reproduce that in HEAD on my machine. Which version of eclipse
do you use? What's the NPEs stack trace?
Benno
|
|
|
| Re: Composing Refactorings... Again [message #242468 is a reply to message #242443] |
Thu, 05 April 2007 13:19 |
Emerson Murphy-Hill
Messages: 22
Registered: July 2009 |
Junior Member |
|
|
Benno Baumgartner wrote:
> Emerson Murphy-Hill wrote:
>> Emerson Murphy-Hill wrote:
>>> Here I apply an ExtractTempRefactoring and call
>>> checkAllConditions(...), calling checkInitialConditions(...), which
>>> assigns the refactoring's CompilationUnit from
>>> RefactoringASTParser.parseWithASTProvider(...). Unfortunately,
>>> parseWithASTProvider *sometimes* returns a stale AST, not the
>>> refactored version from step 3. How does one avoid this race
>>> condition? Or is this a bug? I can probably produce a test case, if
>>> I'm not making any sense.
>>
>> Below is some code that exposes the race. I get a
>> NullPointerException after 2 or 3 iterations. Is this a bug, or am I
>> missing something?
>>
>> String testClass =
>> "class Test{"+
>> " void method(){"+
>> " int x = 0+1+2+3+4+5+6+7+8+9;"+
>> " }"+
>> "}";
>>
>> JavaTestProject project = new JavaTestProject();
>>
>> IPackageFragment fragment = project.createPackage("pkg");
>> ICompilationUnit cu =
>> fragment.createCompilationUnit("Test.java", testClass, true, null);
>>
>> JavaUI.openInEditor(cu);
>>
>> IProgressMonitor pm = new NullProgressMonitor();
>>
>> for(int i = 0; i<10; i++){
>> int varIndex = cu.getSource().indexOf(""+i);
>>
>> ExtractTempRefactoring refactoring =
>> new ExtractTempRefactoring(cu,varIndex,1);
>> refactoring.setTempName("a"+i);
>> refactoring.checkAllConditions(pm);
>> refactoring.createChange(pm).perform(pm);
>> }
>
> Hi Emerson
>
> I can't reproduce that in HEAD on my machine. Which version of eclipse
> do you use? What's the NPEs stack trace?
>
> Benno
Version: 3.2.0
Build id: M20060629-1905
java.lang.NullPointerException
at
org.eclipse.jdt.internal.corext.dom.fragments.ASTFragmentFac tory$FragmentFactory.createFragment(ASTFragmentFactory.java: 179)
at
org.eclipse.jdt.internal.corext.dom.fragments.ASTFragmentFac tory$FragmentForSubPartBySourceRangeFactory.createFragment(A STFragmentFactory.java:164)
at
org.eclipse.jdt.internal.corext.dom.fragments.ASTFragmentFac tory$FragmentForSubPartBySourceRangeFactory.createFragmentFo r(ASTFragmentFactory.java:144)
at
org.eclipse.jdt.internal.corext.dom.fragments.ASTFragmentFac tory.createFragmentForSubPartBySourceRange(ASTFragmentFactor y.java:108)
at
org.eclipse.jdt.internal.corext.dom.fragments.ASTFragmentFac tory.createFragmentForSourceRange(ASTFragmentFactory.java:84 )
at
org.eclipse.jdt.internal.corext.refactoring.code.ExtractTemp Refactoring.getSelectedExpression(ExtractTempRefactoring.jav a:774)
at
org.eclipse.jdt.internal.corext.refactoring.code.ExtractTemp Refactoring.checkSelection(ExtractTempRefactoring.java:548)
at
org.eclipse.jdt.internal.corext.refactoring.code.ExtractTemp Refactoring.checkActivationBasics(ExtractTempRefactoring.jav a:508)
at
org.eclipse.jdt.internal.corext.refactoring.code.ExtractTemp Refactoring.checkInitialConditions(ExtractTempRefactoring.ja va:521)
at
org.eclipse.ltk.core.refactoring.Refactoring.checkAllConditi ons(Refactoring.java:156)
at
edu.pdx.cs.multiview.jdt.delta2.RefactoringTest.race(Refacto ringTest.java:56)
at
edu.pdx.cs.multiview.jdt.delta2.RefactoringTest.test1(Refact oringTest.java:19)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:128)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
at
org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunne r.main(RemotePluginTestRunner.java:58)
at
org.eclipse.pde.internal.junit.runtime.UITestApplication$1.r un(UITestApplication.java:105)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:3 5)
at
org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:123)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.jav a:3325)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :2971)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1914)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:419)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplicatio n.java:95)
at
org.eclipse.pde.internal.junit.runtime.UITestApplication.run (UITestApplication.java:45)
at
org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:78)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:92)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:68)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:400)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336 )
at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
at org.eclipse.core.launcher.Main.run(Main.java:977)
at org.eclipse.core.launcher.Main.main(Main.java:952)
|
|
|
| Re: Composing Refactorings... Again [message #242483 is a reply to message #242468] |
Thu, 05 April 2007 15:00 |
| Eclipse User |
|
|
|
Originally posted by: benno_baumgartner.ch.ibm.com
Emerson Murphy-Hill wrote:
> Benno Baumgartner wrote:
>> Emerson Murphy-Hill wrote:
>>> Below is some code that exposes the race. I get a
>>> NullPointerException after 2 or 3 iterations. Is this a bug, or am I
>>> missing something?
>>>
>>> String testClass =
>>> "class Test{"+
>>> " void method(){"+
>>> " int x = 0+1+2+3+4+5+6+7+8+9;"+
>>> " }"+
>>> "}";
>>>
>>> JavaTestProject project = new JavaTestProject();
>>>
>>> IPackageFragment fragment = project.createPackage("pkg");
>>> ICompilationUnit cu =
>>> fragment.createCompilationUnit("Test.java", testClass, true, null);
>>>
>>> JavaUI.openInEditor(cu);
>>>
>>> IProgressMonitor pm = new NullProgressMonitor();
>>>
>>> for(int i = 0; i<10; i++){
>>> int varIndex = cu.getSource().indexOf(""+i);
>>>
>>> ExtractTempRefactoring refactoring =
>>> new ExtractTempRefactoring(cu,varIndex,1);
>>> refactoring.setTempName("a"+i);
>>> refactoring.checkAllConditions(pm);
>>> refactoring.createChange(pm).perform(pm);
>>> }
>>
>> Hi Emerson
>>
>> I can't reproduce that in HEAD on my machine. Which version of eclipse
>> do you use? What's the NPEs stack trace?
>>
>> Benno
>
> Version: 3.2.0
> Build id: M20060629-1905
>
> java.lang.NullPointerException
> at
> org.eclipse.jdt.internal.corext.dom.fragments.ASTFragmentFac tory$FragmentFactory.createFragment(ASTFragmentFactory.java: 179)
>
> at
> org.eclipse.jdt.internal.corext.dom.fragments.ASTFragmentFac tory$FragmentForSubPartBySourceRangeFactory.createFragment(A STFragmentFactory.java:164)
>
> at
> org.eclipse.jdt.internal.corext.dom.fragments.ASTFragmentFac tory$FragmentForSubPartBySourceRangeFactory.createFragmentFo r(ASTFragmentFactory.java:144)
>
> at
> org.eclipse.jdt.internal.corext.dom.fragments.ASTFragmentFac tory.createFragmentForSubPartBySourceRange(ASTFragmentFactor y.java:108)
>
> at
> org.eclipse.jdt.internal.corext.dom.fragments.ASTFragmentFac tory.createFragmentForSourceRange(ASTFragmentFactory.java:84 )
>
> at
> org.eclipse.jdt.internal.corext.refactoring.code.ExtractTemp Refactoring.getSelectedExpression(ExtractTempRefactoring.jav a:774)
>
> at
> org.eclipse.jdt.internal.corext.refactoring.code.ExtractTemp Refactoring.checkSelection(ExtractTempRefactoring.java:548)
>
> at
> org.eclipse.jdt.internal.corext.refactoring.code.ExtractTemp Refactoring.checkActivationBasics(ExtractTempRefactoring.jav a:508)
>
> at
> org.eclipse.jdt.internal.corext.refactoring.code.ExtractTemp Refactoring.checkInitialConditions(ExtractTempRefactoring.ja va:521)
>
> at
> org.eclipse.ltk.core.refactoring.Refactoring.checkAllConditi ons(Refactoring.java:156)
>
> at
> edu.pdx.cs.multiview.jdt.delta2.RefactoringTest.race(Refacto ringTest.java:56)
>
> at
> edu.pdx.cs.multiview.jdt.delta2.RefactoringTest.test1(Refact oringTest.java:19)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestRefer ence.run(JUnit3TestReference.java:128)
>
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(Test Execution.java:38)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:460)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTe sts(RemoteTestRunner.java:673)
>
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(R emoteTestRunner.java:386)
>
> at
> org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunne r.main(RemotePluginTestRunner.java:58)
>
> at
> org.eclipse.pde.internal.junit.runtime.UITestApplication$1.r un(UITestApplication.java:105)
>
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:3 5)
> at
> org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:123)
>
> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.jav a:3325)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :2971)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1914)
> at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
> at
> org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:419)
> at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
> at
> org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplicatio n.java:95)
> at
> org.eclipse.pde.internal.junit.runtime.UITestApplication.run (UITestApplication.java:45)
>
> at
> org.eclipse.core.internal.runtime.PlatformActivator$1.run(Pl atformActivator.java:78)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:92)
>
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:68)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:400)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:177)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336 )
> at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
> at org.eclipse.core.launcher.Main.run(Main.java:977)
> at org.eclipse.core.launcher.Main.main(Main.java:952)
>
Hi Emerson
I still can not reproduce it with 3.2. However, please file a bug
against Eclipse/JDT/UI containing the test case, stack trace and your
eclipse version (https://bugs.eclipse.org/bugs/).
Thanks
Benno
|
|
| |
Goto Forum:
Current Time: Fri Apr 26 14:11:39 GMT 2024
Powered by FUDForum. Page generated in 0.05917 seconds |
] 
Search
Help
Register
Login
Home
