Community
Participate
Working Groups
Hello, Let's take an example, the aim is to be able to refactor and change between 1/ and 2/ : 1/ super class public class A extends B { public int foo() { // super is here only for explanation return super.bar() + 1; } } 2/ field to delegate public class A { protected B b = new B(); public int foo() { return b.bar() + 1; } } I hope you like the idea, and that it's not too hard to do :)
ok, I see. That would be nice to have. But we will have to see if we find time for new refactorings. Help is always welcome!
I just stumbled across a paper by Hannes Kegel and Friedrich Steimann. They created a eclipse-based plugin for this refactoring (see http://www.fernuni-hagen.de/ps/prjs/RIWD/ ) I just added them to CC so maybe they can give a little feedback if it would be possible to contribute their work to JDT. From the source files I can't see any license of the tools so maybe they can elaborate on that too. I would be really interested to see this refactoring to be part of JDT itself.
There are no licensing problems, just the usual obstacles of making it a contribution (Junit tests etc.). If the UI team can compile a list of TODOs, I can find someone to do it. Ideally, the list would be exhaustive and its processing sufficient for inclusion. The refactoring is already in resonable shape; it can be dowloaded from http://www.fernuni-hagen.de/ps/prjs/RIWD/#Installation PS: IntelliJ IDEA also offers RIWD, but our implementation is far better ;)
>If the UI team can compile a list of TODOs There's no complete list. Important is to provide the work as CVS patch(es) using the projects code styles (formatter, naming conventions etc) and make sure the UI fits into the other existing refactorings. Besides that, tests need to be provided (org.eclipse.jdt.ui.tests.refactoring project). Also, each new file needs to get your copyright header and touched files need to get an entry about your work.
*** Bug 111810 has been marked as a duplicate of this bug. ***
Friedrich, is there some chance that you might contribute this?
Not currently, unfortunately. Hannes had looked into it when he was doing his thesis work, and the hurdles were too high, then. I'd be happy to provide you with the sources, though (Adam Kiezun looked into them at that time and said they were OK), perhaps it still works? What is the general Eclipse development policy regarding refactorings, anyway? Are there any resources attached to improving the current state of implementations? I am only asking since we are still working on refactorings for Eclipse (see, eg, http://doi.acm.org/10.1145/1985793.1985854), but implementing correct refactorings remains difficult. One technical problem is the API -- necessary program analyses are often difficult to implement using the Java Model and Search function.
(In reply to comment #7) > Not currently, unfortunately. Hannes had looked into it when he was doing his > thesis work, and the hurdles were too high, then. > > I'd be happy to provide you with the sources, though (Adam Kiezun looked into > them at that time and said they were OK), perhaps it still works? > > What is the general Eclipse development policy regarding refactorings, anyway? > Are there any resources attached to improving the current state of > implementations? Yes, if we already own it. If a new refactoring gets contributed we prefer contributors who are also willing own/maintain the code later and not just throw it over the fence. In such cases we would also offer help to some extent.
