Re: [jdt-ui-dev] UseSupertypeWherePossible released

["Adam Kiezun" <adam.kiezun@xxxxxxx>]

Thank you Tim,
I had a look at your paper and run your tool.
It surely is very interesting stuff that you're working on.
And the tool is really good too - I'm planning to run it on jdt ui to do the analysis
(and fix the problems :-)).

[Btw, compared to other tools - especially competition - Eclipse does not look too bad in yout metrics, eh?]

And your work is somewhat related to our refactorings
(except you only analyze - and our tool also modifies the code)

I see a couple of differences between our approaches:
a. you analyze the whole workspace in a lint-kind of way while we perform our analysis for a selected type
b. (consequence of a. really) your tool opens every file and creates the ast for it.
ours opens only those files that need to be opened.
c. you do not consider method return type and never suggests to update them - our tool does
d. or method parameters - we do
e. the analysis that your tool performs seems to be a bit limited - consider the following:
class A{}
class B extends A{
   void f(B b0){
       b0.f();
       B b1= null;
       B b2= b1;
       B b3= b2;
   }
}
now, eclipse's refactoring will notice that it's ok to update declarations of b1, b2 and b3 to A
(but not b0, naturally)
while i need to run Tallyho 3 times (run, modify, run, modify,  run, modify) to achieve the same effect.
The first time round it thinks that only the declaration of b3 can be modified.

f. having said all that - our tool is, at this point, a bit over-enthusiastic about what can be changed
(whereas i could not find a way to fool yours :-) ).
For now you have avoided it but it gets really interesting when method parameters come into the picture - overloading, overriding
and related problems are not far behind.

Btw, thanks for the insight about Throwable - updating these would trully be a _bad_ idea :-)
(far too much is dependent on run-time types of the exception objects).

So, I think there's room for improvement in both your tool and ours - and we could utilize each other's experience and insights..
Tim, thanks very much again for your interest and sharing your ideas with us.We really, really appreciate it.
Hope you will stay in touch.

Best regards
-adam

ps. Where's the paper going to be published? And when?
pps. In figure 1 'newEntry' is of type Object but then t(newEntry) = {String}. This seems strange.
(the + operator does not imply that the second argument is of type String.
Rather,  string conversion is used, which for reference types means that toString() is called - as spec'd in JLS 15.18.1.1) .
ppps.  The ancestor(ListIterator)  (section 2.1) misses Object, i think
pppps. The ancestor function is defined only for types but then it's also used for sets of types (2.1 also)
(as in 'ancestor(t)')

(i guess everybody will understand it, though)

ppppps. It was good not to see an Eclipse example in the 3.2.1 section on ignored exceptions and interesting comments in empty catch
blocks. Is there none or were they not interesting? Or too embarassing for eclipse developers <g>?