| Re: [jdt-ui-dev] UseSupertypeWherePossible released |
Adam, I've attached a draft (unpublished) paper that describes the algorithm in detail. It appears you would be most interested in section 2 which we call "Overspecific variable declarations." This portion goes through the assurance algorithm--I believe it would be pretty much the same for a refactoring. You're interest probably doesn't run toward academic publication but we would ask normal academic citation practice for the paper (for anyone who's interest does run along those lines)...now about the code! I have also attached the current plug-in described in the paper (.classpath is for Linux/Motif 2.0.1, but "Update classpath..." right-click menu item should convert it to any Eclipse OS/Window system combination). A few notes: (1) Reset the Java perspective to have the "Code Quality Advice" window show up alongside the "Tasks" window. (2) The prototype is not "incremental" you have to "trigger" it by pressing the "flashlight" toolbar icon or selecting a menu choice. (3) It only suggests changes--it won't touch your source code. Ideally it would "hook" into refactorings and smoothly transition the user from describing it's suggestion to actually implementing the suggestion (if the programmer approves) -- this is not hard to envision from the current prototype, but it is not implemented yet. (3) Once analysis of the loaded projects is finished you can drill in to see problems -- any advice with a file/line number allows you to bring up the code at that line via a double-left-click. (4) Three categorizations are allowed via a right click on the results pane. The most useful, sadly not the current default, is "Order results by category and sub-category" the sub-category is the Java the the problem was found for. Try this on some code and look at the problems found for java.util.ArrayList, java.util.LinkedList, etc. (like the paper describes). Just email if you have problems -- This prototype is in rework right now, but the original sort-of gets the idea across (note the large amount of supporting information presented to the programmer, and allowing multiple "categorizations" of the results based upon programmer "role" or "interest within the project). The code is very crusty as this was our first Eclipse work (and jumping from "hello world plug-in" to this was ambitious:->). The biggest problem is the full project compilation unit pass required to resolve all "public" "protected" and "package" visible fields -- this is being fixed at CMU. Lots of other issues as well, but it might be useful to look over. This is a research project, obviously, but I think Models of Thumb is a nice "helper" toward directing programmer attention to what refactoring they should consider--it is a synergistic technique not a competing one. Our research group is very interesting in "concrete" approaches to improving software quality so obviously we want to contribute to Eclipse in any way we can (see my paper on open source quality at http://opensource.ucc.ie/icse2002/ if this is of general interest). So... (1) I'd be glad to look at the current code toward the refactoring and help out. My work so far has generated several bugs in the JDT core that Oliver Thomann fixed, and a few suggestions for API enhancement. (2) If there's a more general interest in Models of Thumb, I'd love to figure out how to get it "properly" into the Eclipse framework. For example, currently the "Tasks" viewer is unable to allow the rich descriptions we create (hence our need for another window) -- this could probably be addressed without too much work and would benefit any non-error producing tool. We are investigating how to get "light-bulbs" and trigger refactorings as well. Thoughts? Take Care, Tim Halloran Carnegie Mellon University On Wed, 2002-09-25 at 18:41, Adam Kiezun wrote: > >I'm interested in a code pointer to this feature and perhaps > >an email from someone who worked on this to compare notes on the > >soundness of the analysis. > > that someone would be me. :-) > (i guess in open source projects you normally don't announce stuff you didn't write without pointing to the person) > > > I looked at over 2MLOC to gain an empirical understanding of this change > > to code and implemented the analysis in a Eclipse plug-in. > > wow! > anything we could have a look at? > code or research material? > papers? > > also, please bear in mind that the current implementation is by no means complete and will be subject to constant improvements over > the next couple of months (naturally, going pararelly with development of new features and improvement in other areas) > > (plus, the code needs cleanup - you might want to wait until it happens before you try to read it <g>). > > needless to say, your feedback or/and any other input will be more than welcome. > > thanks for your interest, Tim > a. > > > _______________________________________________ > jdt-ui-dev mailing list > jdt-ui-dev@xxxxxxxxxxx > http://dev.eclipse.org/mailman/listinfo/jdt-ui-dev
Attachment:
mot.pdf
Description: Adobe PDF document
Attachment:
tallyho27Sep02.tgz
Description: GNU Zip compressed data