30/08/2014 - revision 732 (functionality added + bug fixes):

- Several fixes in Extract Clone Refactoring.
- Updated the search scope for sub-types using SearchEngine.createStrictHierarchyScope() introduced in JDT 3.6 This update improved significantly the performance of the search for sub-types.
- Added support for the advanced matching of different loop structures and if statements with expressions using the ternary operator.

20/07/2014 - revision 701 (functionality added + bug fixes):

The first stable version of the Clone Visualization and Refactoring feature is released.

06/04/2014 - revision 633 (functionality added):

- Added support for Synchronized and Labeled statements in Extract Clone refactoring.
- Added support for pulling up additional duplicated methods called from the original clones in Extract Clone refactoring.
- Improved the performance of method processPDGNodes in PDGSubTreeMapper by iterating over the elements of the smaller set in the outermost for loop.

29/03/2014 - revision 631 (functionality added):

- Fixed the matching of method invocations with method declarations having varargs parameters.
- Added analysis support for Enum types.
- Added analysis support for Labeled and Synchronized statements.

22/02/2014 - revision 618 (Bug fix):

Fixed the matching of InfixExpressions. Fixed a bug in the highlighting of differences for SimpleTypes.

21/12/2013 - revision 610 (Bug fix):

Improved the matching of method invocations with method declarations to address the cases where 'type parameter names' are replaced with actual types in the method calls.

14/12/2013 - revision 608 (Bug fixes, functionality added):

- Improved the user interface of Extract Clone Refactoring, so that it presents multiple refactoring opportunities from a pair of methods in the same Wizard page (using a combo for allowing the user to select among the different refactoring opportunities).
- Added initial support for the mapping of if/else statements with expression statements containing a conditional expression (i.e., the ternary operator "condition ? true : false").
- Fixed 'Overlapping TextEdits' exception in Replace Type Code with State/Strategy refactoring.
- Added styling of static method calls and non-static field accesses in the Clone Diff viewer.
- Fixed several problems in the application of Replace Type Code with State/Strategy Refactoring:
1) The state named constants may be defined in an inner class/enum
2) There might already exist a method having the name "set" + AbstractStateName
3) The State subclasses introduced may cause a naming conflict even with classes outside the package in which they are created
The test case used is in project jEdit 4.4.1, class BufferSetManager, and methods addBuffer/removeBuffer.
- Static method calls in the type-checking code fragment are called statically after the introduction of polymorphism.
- Extended ASTNodeMatcher to handle ConditionalExpressions (i.e., the ternary operator)

13/10/2013 - revision 591 (Bug fixes):

- Fixed the handling of additional methods moved along with source method in Move Method Refactoring.
- Fixed the processing of if statements within the body of do-while loops in the construction of control flow graphs.

06/10/2013 - revision 587 (functionality added):

- New Clone Visualization and Refactoring (Beta) support.
- All inner types are parsed regardless of their nesting level.
- Method calls with varargs are properly handled in method call analysis.
- Program Dependence Graph generation has been enhanced with a caching mechanism for internal method calls.

02/09/2013 - revision 578 (functionality added):

New Code Smell Package Explorer for Feature Envy and God Class.

02/07/2013 - revision 525 (functionality added):

Code Smell Visualizations have been enhanced with auto scrollbar adjustment, zoom support (from the View menu options or by scrolling the mouse wheel).

21/06/2013 - revision 514 (Bug fix):

The binding returned from SimpleName expressions should be always checked for NullPointer. Many thanks to Wei Wu (École Polytechnique de Montréal) for reporting the problem.

13/06/2013 - revision 512 (General functionality added):

New Code Smell Visualizations for Feature Envy and God Class.

28/02/2013 - revision 448 (Bug fix):

Fixed a bug in the construction of control flow graphs. Many thanks to Danny Verloop (TU Delft) for reporting the problem.
The problem was found in project Sipdroid, class org.sipdroid.media.RtpStreamSender, method run()

06/11/2012 - revision 403 (JLS 4 support):

Updated JDeodorant to support Union Types introduced in Java 7. Union types are mainly used in the new Multicatch feature:

try {
...
} catch( IOException | SQLException e ) {
logger.log(ex);
throw ex;
}

04/11/2012 - revision 402 (JLS 4 support):

Updated JDeodorant to support JLS 4. This affected the construction of Control Flow and Program Dependence graphs, since the new try-with-resources statements may declare resources (i.e., objects that must be closed after the program is finished with them) in Java 7.

26/10/2012 - revision 400 (Long Method bug fix):

Alias analysis could cause in some cases an infinite recursion. The new implementation of alias analysis improves significantly the performance.

09/10/2012 - revision 399 (Bug fix):

The exclusion of classes containing method with @Test annotations from the analysis may cause NullPointer exceptions (such a case was found in JUnit). As a result, test methods are not excluded from the analysis.

28/02/2012 - revision 396 (General functionality added):

Created a Standalone version of JDeodorant for the detection of refactoring opportunities from Eclipse applications.

26/02/2012 - revision 395 (Type Checking bad smell):

The results of Type Checking bad smell are now reported in a tree view and are grouped per inheritance hierarchy or named constants.

21/11/2011 - revision 394 (Feature Envy & God Class bad smell):

Fixed the problem of inherited static fields being accessed by a method to be moved. After the move the inherited static fields should be statically accessed using the name of the class in which they are declared.

16/11/2011 - revision 393 (Feature Envy bad smell):

Added a new precondition for Move Method refactoring. The variable (parameter or field of target class type) through which the moved method will be invoked must not be assigned within the body of the candidate method to be moved.
The reason is that the variable should be replaced with "this" expression in the moved method and "this" expression cannot be assigned with a value.
The problem was reported by Theodore Chaikalis and was found in method calculateRangeAxisSpace(Graphics2D g2, Rectangle2D plotArea, AxisSpace space) of class CategoryPlot (JFreeChart version 1.0.11).

16/11/2011 - revision 393 (Type Checking bad smell):

Fixed a bug in the application of Replace Conditional with Polymorphism refactoring. The context class must be public when the type-checking branches access fields/methods of the context class and the subclasses belong to a different package with respect to the context class.
The problem was reported by Theodore Chaikalis and was found in method updatePlotProperties(Plot plot) of class DefaultPlotEditor (JFreeChart version 1.0.11).

21/10/2011 - revision 392 (Type Checking bad smell):

Fixed a bug in the application of Replace Conditional with Polymorphism refactoring where the cast expression (casting the supertype to the corresponding subtype) should be replaced with "this" expression.
The problem was reported by Theodore Chaikalis and was found in method applyToPlot(Plot plot) of class StandardChartTheme (JFreeChart version 1.0.11).

For example, the following case
if (plot instanceof PiePlot) {
applyToPiePlot((PiePlot) plot);
}
should be transformed in class PiePlot as follows
applyToPiePlot(this);

04/09/2011 - revision 391 (General functionality added):

Fixed the unnecessary importing of nested types in all implemented refactorings.

22/04/2011 - revision 389 (God Class bad smell):

- Added the feature of concept identification. The extractable concepts are labeled with the most frequent term(s) resulting from tokenizing and stemming the names of the extracted members. The concepts/clusters which are created incrementally (i.e., resulting from another cluster by adding only a single class member) are excluded from being suggested.
- The presentation of the results has changed as shown in the screenshot below.
1) At first level, the suggestions are grouped according to the class they belong to.
2) At second level, the suggestions are grouped by 'general concepts'. The general concepts do not have any common class members.
3) Finally, the third level contains the extractable concepts, which may be sub-concepts of their parent general concept (i.e., they represent a subgroup of the class members represented by the general concept) or the general concept itself.

17/04/2011 - revision 387 (God Class bad smell):

Improved the application of Extract Class refactoring in order to properly initialize extracted fields having "this" expressions in their initializer.

11/04/2011 - revision 386 (Long Method bad smell):

The results of Long Method bad smell are now reported in a tree view (the results are grouped per variable). The rename button has been removed and the renaming feature has been embedded in the refactoring wizard as a user input page.

10/04/2011 - revision 385 (God Class bad smell):

Improved the application of Extract Class refactoring in order to properly handle extracted members being static.
Static methods are statically invoked in the source class after their extraction.
For static fields being extracted the getter and setter methods in the extracted class are declared static and are also statically invoked in the source class.

04/04/2011 - revision 384 (God Class bad smell):

- Added a feature in Extract Class refactoring that handles properly the initialization of final fields in the extracted class when they are initialized inside constructors.
- Added a precondition that excludes from suggesting for extraction clusters containing public fields which are accessed from classes other than the source class.
- Added a feature that includes static fields and methods in the formation of entity sets for the God Class design problem.

31/03/2011 - revision 383 (God Class bad smell):

The clustering algorithm was improved so that it no longer requires distance thresholds. Now, it reports the clusters formed at the merging points.

15/03/2011 - revision 382 (User interface improvements):

- Added a user option in the input pages of the Move Method and Extract Class refactorings allowing to keep delegates to the public moved methods.
- The user rating is applied directly by clicking on the rating value without having to get the focus lost from the ComboBoxCellEditor.

12/03/2011 - revision 380 (God Class bad smell):

- Extract Class Refactoring has been implemented from scratch and several bugs have been fixed.
- Added user rating support for the identified Extract Class refactoring opportunities.

09/01/2011 - revision 377 (Long Method bad smell):

The try/catch blocks and throw statements are handled according to the approach proposed by Allen & Horwitz (2003).

M. Allen, and S. Horwitz, "Slicing Java Programs that Throw and Catch Exceptions",
ACM SIGPLAN Workshop on Partial Evaluation and semantics-based Program Manipulation, pp. 44-54, 2003.

31/12/2010 - revision 376 (Long Method bad smell):

Added a rule for the preservation of output dependences.

25/12/2010 - revision 375 (Long Method bad smell):

The unlabeled break and continue statements within the body of loops and the break statements within the body of switch statements are handled according to the augmented program dependence graph (APDG) approach proposed by Ball & Horwitz (1993), Kumar & Horwitz (2002).

T. Ball, and S. Horwitz, "Slicing Programs with Arbitrary Control Flow",
First International Workshop on Automated and Algorithmic Debugging, pp. 206-222, 1993.

S. Kumar, and S. Horwitz, "Better Slicing of Programs with Jumps and Switches",
Fifth International Conference on Fundamental Approaches to Software Engineering, pp. 96-112, 2002.

02/12/2010 - revision 374 (Type Checking bad smell):

- The variables which are declared within expressions are properly handled.
- Added a precondition checking whether existing subclasses are interfaces.
- Added a precondition not allowing the presence of return statements (without a return expression) within the body of the type-checking code fragment.

25/11/2010 - revision 373 (General functionality added):

Added support for the detection of friend classes according to the Law of Demeter.

08/11/2010 - revision 372 (General functionality added):

- Added functionality allowing the user to rate each identified refactoring opportunity with a rating ranging from 0 to 5 stars. The provided ratings will help the JDeodorant team to improve the ranking mechanism that sorts the identified refactoring opportunities.
- Fixed a few bugs in the God Class view. Many thanks to Keith Cassell for pointing them out.

27/08/2010 - revision 370 (Long Method bad smell):

If the declaration statement of variable criterion is nested in a deeper level compared to the insertion point of the extracted method invocation, then the extracted method should be declared with a void return type.

18/08/2010 - revision 368 (General functionality added):

Added support for code smell evolution analysis throughout successive versions of a given Java project.

12/07/2010 - revision 365 (Long Method bad smell):

Throw statements being control dependent on slice statements are properly handled.

11/07/2010 - revision 364 (God Class bad smell):

The tool supports the identification of Extract Class refactoring opportunities for the decomposition of "God" classes.
This feature has been developed by Marios Fokaefs and is the outcome of a joint research effort between the SSRG Lab at the Department of Computing Science, University of Alberta and the CSSE Lab at the Department of Applied Informatics, University of Macedonia.

04/07/2010 - revision 359 (Long Method bad smell):

Program analysis has been extended to handle super method invocations.

01/07/2010 - revision 354 (Long Method bad smell):

The slice profile of a method is composed of complete computation and object state slices instead of traditional slices.

01/07/2010 - revision 353 (Long Method bad smell):

-The case where an argument is passed as parameter to an abstract invoked method is properly analyzed.
-The complete computation and object state slices have been extended to include the object state slice of any object reference which is used in the initial slice.
-The speed of slice computation when constructing unions of slices has been significantly improved.

26/06/2010 - revision 350 (Long Method bad smell):

The performance of program analysis has been improved by indexing the structure of analyzed inheritance hierarchies.

21/06/2010 - revision 346 (Long Method bad smell):

The slice profile of a method includes only the local variables whose scope is the block corresponding to the method body.

20/06/2010 - revision 345 (Long Method bad smell):

An additional slice extraction threshold has been added which is related with the maximum traversal depth of the call graphs corresponding to invoked methods from libraries.

17/06/2010 - revision 344 (Long Method bad smell):

The variables which are not defined within the body of the examined method are automatically excluded from its slice profile.

15/06/2010 - revision 343 (Long Method bad smell):

A calculator for slice-based cohesion metrics has been added.

11/06/2010 - revision 342 (Long Method bad smell):

An additional slice extraction threshold has been added which is related with the size of the methods being examined.

05/06/2010 - revision 340 (Long Method bad smell):

The implementation of program analysis has been improved in terms of design and performance.

26/05/2010 - revision 338 (Feature Envy bad smell):

In the application of Move Method refactoring, the javadoc @param tags are properly updated.

25/05/2010 - revision 337 (Long Method bad smell):

Two Annotation markers have been added in order to highlight the slice statements that will be duplicated in red color and the slice statements that will be removed from the original method in green color.

In the case the Annotation markers do not appear (this may happen if you have already installed a previous version of JDeodorant plug-in), simply remove gr.uom.java.jdeodorant_1.0.0.jar from Eclipse plugins directory, start Eclipse (after removing JDeodorant plug-in from plugins directory), and finally re-extract JDeodorant plug-in in Eclipse plugins directory.

23/05/2010 - revision 336 (Type Checking bad smell):

The prefix expressions having a field as operand and +, -, !, ~ as operator are properly handled.
e.g. !field becomes !sourceClass.getField()

22/05/2010 - revision 334 (Type Checking bad smell):

In the application of Replace Type Code with State/Strategy and Replace Conditional with Polymorphism refactorings, the required import declarations are now added using class ImportRewrite. Moreover, the changes to already existing classes are represented with CompilationUnitChange objects.

20/05/2010 - revision 333 (Feature Envy bad smell):

-Move Method Refactoring preconditions have been updated:
A candidate target class should not be selected as final target class if there exists another candidate target class that inherits it. This means that the method to be moved accesses members from classes having an inheritance relationship and thus can only be moved to the subclass in order to continue having access to the inherited members.

-Move Method Refactoring mechanics have been updated:
The invocations of static methods inside the body of the moved method which are inherited from a superclass of the source class, are replaced with static invocations through source class name after the move to target class.

19/05/2010 - revision 332 (Long Method bad smell):

The resulting slice extraction refactoring opportunities are grouped based on common variables used as slicing criteria and sorted in ascending order according to their average duplication ratio.
In the case where two or more slice groups have an average duplication ratio equal to zero, they are sorted in descending order according to the maximum number of extracted statements of the slices belonging to each group.

06/05/2010 - revision 331 (Type Checking bad smell):

Type Check Elimination preconditions have been updated:
The type-checking code fragment should not contain any super field accesses.

06/05/2010 - revision 330 (Feature Envy bad smell):

Move Method Refactoring preconditions have been updated:
The method to be moved should not contain any super field accesses.

05/05/2010 - revision 329 (Feature Envy bad smell):

In the application of Move Method refactoring, the original method should be turned into a method that delegates to the moved one, in the case where a subclass invokes the method to be moved by means of a super method invocation. Many thanks to Marios Fokaefs for pointing out this issue.

02/05/2010 - revision 328 (Feature Envy bad smell):

In the application of Move Method refactoring, the required import declarations to target class are now added using class ImportRewrite. Moreover, the changes to source and target class are represented with CompilationUnitChange objects.

22/04/2010 - revision 327 (Feature Envy bad smell):

Fixed a problem in the application of Move Method refactoring that appeared when the method to be moved accessed through a reference to the target class a field belonging to the superclass of the target class. In this case the reference from which the superclass field was accessed was not removed from the body of the moved method. The problem was found based on a code example provided by Philipp Marcus.

17/04/2010 - revision 326 (Long Method bad smell):

Fixed a bug in the the application of Extract Method refactoring which is related with the way that the name of the extracted method was obtained.

11/04/2010 - revision 325 (Long Method bad smell):

The CompilationUnits corresponding to analyzed library classes are no longer permanently stored in memory. All references to MethodDeclarations and VariableDeclarations have been replaced with references to the keys of their bindings. A separate caching mechanism is employed that keeps a constant number of CompilationUnits corresponding to library IClassFiles in a queue. The size of the queue can be configured through JDeodorant Preference Page.

05/04/2010 - revision 324 (General functionality added):

Added functionality that enables the comparison of a class instance creation with the signature of a constructor.

29/03/2010 - revision 322 (Long Method bad smell):

An anti-dependence exists from statement p to statement q due to variable x, when there is a control flow path starting from statement p that uses the value of x and ending to statement q that modifies the value of x, regardless of any intermediate statements that may use the value of variable x.

28/03/2010 - revision 321 (Long Method bad smell):

Break and continue statements inside loops are properly handled.

27/03/2010 - revision 320 (Long Method bad smell):

An additional rule has been added regarding slice extraction:
If a return statement is directly or indirectly control dependent on a statement belonging to a given slice, then this slice is rejected from being suggested as a refactoring opportunity.

27/03/2010 - revision 319 (General functionality added):

The size of the CompilationUnit cache can be set by the user in the Preference Page of JDeodorant.

16/03/2010 - revision 318 (Long Method bad smell):

Try/catch blocks are properly copied to the extracted method and removed from the original method if necessary.

11/03/2010 - revision 316 (Major functionality change):

When the identification of code smells is performed on the same project, then only the compilation units that have been changed or added are parsed.

09/03/2010 - revision 315 (Long Method bad smell):

Fixed the handling of blocks that exist within the body of a switch statement in the construction of control flow graph.

08/03/2010 - revision 314 (General functionality added):

- The identification of Feature Envy and Type Checking code smells can now be performed on a whole Java Project, a Package Fragment Root of a project, a Package Fragment of a project, a Compilation Unit, and a Type (along with its nested types) by selecting the appropriate element on the Package Explorer. This feature has been requested/suggested by Prakash Badlani.
- A Progress Monitor has been added for the AST parsing of the selected Java Project.

07/03/2010 - revision 313 (Long Method bad smell):

The analysis of external (library) method invocations also includes the methods which are invoked through parameters that ate passed as arguments in method invocations inside the body of the method under examination.

06/03/2010 - revision 311 (Long Method bad smell):

- The computation of indispensable nodes and passed parameters for the union of static slices has been improved.
- The analysis of external (library) method invocations also includes the methods which are invoked through field references.

04/03/2010 - revision 309 (Long Method bad smell):

In a polymorphic method call, the subtypes belonging to an inheritance depth level which is deeper than first level and whose superclass is an abstract type are also included in the examination for concrete implementations of the polymorphic method.

03/03/2010 - revision 308 (Long Method bad smell):

- Alias Analysis can be enabled/disabled in the Preference Page of JDeodorant.
- Fixed the handling of empty loops in the construction of control flow graph.

03/03/2010 - revision 307 (General functionality added):

The results of the identification process can be saved in a tab delimited text file by clicking on "Save Results" button. This feature has been requested/suggested by Prakash Badlani.

02/03/2010 - revision 305 (Long Method bad smell):

The extraction of object references which are fields, parameters, or local variables whose declaration statement does not belong to slice nodes has been fixed.
In such a case, the extracted method should have a void return type and not return the variable of the slicing criterion.

02/03/2010 - revision 305 (Type Checking bad smell):

A progress bar has been added for the identification process of Type Checking code smells.

17/02/2010 - revision 304 (Long Method bad smell):

The identification of Long Method code smells can now be performed on a whole Java Project, a Package Fragment Root of a project, a Package Fragment of a project, a Compilation Unit, a Type (along with its nested types), and a Method of a Type by selecting the appropriate element on the Package Explorer.

15/02/2010 - revision 301 (Long Method bad smell):

Switch statement is fully supported in the construction of control flow and program dependence graphs.

13/02/2010 - revision 300 (Long Method bad smell):

- Added support for Alias Analysis. An alias relationship exists between two references if they refer to the same object in memory during program execution. For example, in the following code fragment

Buffer a = new Buffer();
Buffer b;
b=a;
a.append("a");
b.append("b");

references a and b refer to the same object in memory (i.e. new Buffer()) and as a result the invocation of method append through either reference a or reference b affects the state of the same object. This information is vital for the formation of correct and precise slices.
- An additional rule has been added regarding slice extraction:
A duplicated node of the slice containing a class instantiation for reference r, should not have a data dependence to a removable node that either affects the state of r or assigns r to another reference.

09/02/2010 - revision 297 (Feature Envy bad smell):

The access modifier of the source class is set to public, when source class type is passed as parameter to the moved method and source class belongs to a different package compared to target class.

05/02/2010 - revision 295 (Type Checking bad smell):

Before the application of Replace Type Code with State/Strategy refactoring, a dialog was added that gives the option to the user to rename the default class names which were automatically generated for the Abstract State/Strategy based on the name of the variable holding the state, and for the Concrete States/Strategies based on the names of the corresponding named constants.
The dialog checks for the validity of the type names and also if a type name already exists in the source code of the project under examination or has the same name with a class belonging to java.lang package.

23/01/2010 - revision 293 (General bug fix):

Fixed a serious bug which caused an exception in the identification process after the application, undo, or redo of a refactoring. This bug was introduced after revision 287 on September 13th 2009 and it is very important to update to the latest build of JDeodorant.
The CompilationUnit caching mechanism should be cleared after any operation that modifies the AST state (i.e. refactoring application, undo, redo operations, or even manual source code modification).

29/12/2009 - revision 289 (Long Method bad smell):

An additional behavior preservation rule has been added: The statements which are duplicated in both the remaining and the extracted method should not contain any class instance creation or array creation.

13/09/2009 - revision 287 (Major functionality change):

AST nodes corresponding to Java elements of the project under examination are no longer permanently stored in memory. Instead, a caching mechanism is employed that enables the recovery and processing of AST information using temporary memory storage. This revision is compatible with Eclipse 3.5 Galileo.

21/04/2009 - revision 283 (Long Method bad smell):

A Preference page that can be used to reduce the number of reported Slice Extraction refactoring suggestions by adjusting various threshold values has been added. The thresholds are related the size of the slice and the degree of statement duplication caused by each suggestion. Many thanks to Eric Bouwers for suggesting this feature.

05/03/2009 - revision 281:

Fixed a bug associated with the import declaration of types which are right operands in instanceof expressions (bug reported by Theodore Chaikalis).

27/02/2009 - revision 280 (Long Method bad smell):

Fixed the problem of leaving empty "if/else" or "if/else if" structures after the extraction of slice unions.

20/02/2009 - revision 279 (Long Method bad smell):

- Fixed a bug concerning the handling of self-associations which caused an infinite loop when a method invoked itself through a self-association field.
- When an abstract method is invoked through a superclass reference and it is not possible to recover the actual subclass type by static analysis, then all the methods of the corresponding subclasses implementing it are included in the Def/Use analysis.
- A progress bar has been added for the identification process of Extract Method refactoring opportunities.

25/01/2009 - revision 278 (Long Method bad smell):

- The fields which are accessed by the slice statements are not passed as parameters to the extracted method.
- The invocation of the extracted method is placed before the first statement of the slice and not before the leader node of the corresponding boundary block.

22/01/2009 - revision 276 (Long Method bad smell):

The data dependency and anti-dependency edges which are carried by a loop node that does not belong to the block-based region are excluded from backward slicing traversal, even if both source and destination nodes belong to the block-based region.

18/01/2009 - revision 275 (Long Method bad smell):

The source code of invoked methods belonging to external library/API classes is analyzed in order to improve the precision of extracted slices. To enable the analysis of methods belonging to Java library classes you should attach the Java API source code by following this guide.

28/12/2008 - revision 274 (Long Method bad smell):

The slice extraction refactoring opportunities are sorted in ascending order according to the ratio of duplicated statements to extracted statements.

27/12/2008 - revision 273 (Long Method bad smell):

The preview of changes in slice extraction refactoring has been improved by employing a tree-like representation of changes as shown below.

21/12/2008 - revision 272 (Long Method bad smell):

After four months of constant research and development, the tool supports the automatic identification of slice extraction refactoring opportunities for the decomposition of complex methods.

10/08/2008 - revision 232 (Type Checking bad smell):

If the field holding the current state is explicitly initialized with the value of a named constant, then it is initialized with an instance creation of the subclass corresponding to the specific named constant after the application of Replace Type Code with State/Strategy refactoring.

If the field holding the current state is implicitly initialized (i.e. its field declaration does not have an initializer), then it is initialized with an instance creation of the subclass corresponding to the named constant which has the zero value after the application of Replace Type Code with State/Strategy refactoring.

08/08/2008 - revision 231 (Type Checking bad smell):

The assignments of fields having +=, -=, *=, /=, %=, &=, |=, ^=, = and >>>>= as operator are properly handled.
e.g. field += variable; becomes sourceClass.setField( sourceClass.getField() + variable );

The prefix and postfix expressions having a field as operand and ++, -- as operator are properly handled.
e.g. field++; becomes sourceClass.setField( sourceClass.getField() + 1 );

03/08/2008 - revision 229 (Feature Envy bad smell):

The classes that directly or indirectly extend "junit.framework.TestCase" (JUnit 3.x) or contain at least one method annotated with @Test annotation (JUnit 4.x) are automatically excluded from the analysis.

02/08/2008 - revision 228 (Feature Envy bad smell):

When the user selects a specific package to be analyzed, its subpackages are also included in the analysis.

21/07/2008 - revision 227 (Feature Envy bad smell):

The calculation of the Entity Placement metric for the suggested Move Method refactorings has been optimized, by recalculating only the minimum required number of distances.

17/07/2008 - revision 226 (Type Checking bad smell):

The handling of accessed static fields inside the type-checking code fragment has been improved (bug fixing).

16/07/2008 - revision 224 (Major functionality change):

All implemented refactorings now extend class "org.eclipse.ltk.core.refactoring.Refactoring" in order to provide undo/redo support in the refactoring history of Eclipse. Moreover, a refactoring wizard has been added that enables the preview of the changes before the application of each refactoring.

06/07/2008 - revision 222 (Feature Envy bad smell):

The tooltip indicating a dependency between two refactoring suggestions has been enhanced. It contains a link that selects the row of the suggestion corresponding to the dependency when it is clicked by the user.

29/06/2008 - revision 221 (Type Checking bad smell):

If fields from the superclass of Context are accessed/assigned inside the type-checking branches, their accesses/assignments are replaced with the corresponding getter/setter method invocations through the Context parameter reference.

27/06/2008 - revision 219 (Type Checking bad smell):

- The plug-in has been tested for compatibility with Eclipse 3.4 (Ganymede).
- The user can also select a specific Java project package from the Package Explorer to be analyzed.
Type Check Elimination preconditions have been updated:
- The type-checking code fragment should not contain super method invocations.
- The named constants that participate in the type-checks should belong to classes of the system and not library or API classes.

26/06/2008 - revision 218 (Type Checking bad smell):

The methodology has been updated to handle if statement expressions that consist of sub-expressions combined with conditional OR operators (||). All sub-expressions should perform type-checking on the same variable holding the current state. In this case an intermediate class is created between the abstract class and the leaf concrete classes corresponding to the named constants that participate in the type-checks. The common behavior (then clause of the if statement) is placed in the overriding method of the intermediate class, while the leaf concrete classes simply inherit the intermediate class without overriding the polymorphic method.

16/06/2008 - revision 216 (Type Checking bad smell):

Type Check Elimination preconditions have been updated:
The type-checking code fragment should not contain break or continue statements that do not belong inside the body of an iteration statement (for, while, do-while, enhanced for).

13/06/2008 - revision 213 (Type Checking bad smell):

The sorting mechanism of the refactoring suggestions has been improved so that the suggestions belonging to the same group appear consecutively.

11/06/2008 - revision 212 (Type Checking bad smell):

The type-check elimination opportunities are sorted according to their impact on the design of the system under study using the following criteria:

1. The number of cases that are going to utilize the same inheritance hierarchy at system level.
2. The number of cases that are going to utilize the same inheritance hierarchy at class level.
3. The average number of statements per state.

10/06/2008 - revision 211 (Type Checking bad smell):

A bug was fixed in the application of Replace Conditional with Polymorphism refactoring.

04/06/2008 - revision 208 (Feature Envy bad smell):

A Progress Monitor has been added to the identification of Feature Envy bad smells. The user can also cancel the process of identification.

16/05/2008 - revision 207 (Type Checking bad smell):

The type-checking code fragments from all system classes are examined in order to identify common static fields representing relevant states. In this way, all the related states are transformed into a single inheritance hierarchy which is employed by all the corresponding type-checking code fragments.

29/04/2008 - revision 201 (Type Checking bad smell):

- Enumerated types are now supported.
- The number of cases/branches in a type-checking code fragment should be more than one, or equal to one provided that a default case/final else branch exists.

23/04/2008 - revision 200 (Type Checking bad smell):

The identification of the returned variable corresponding to a type-checking code fragment has been improved.

15/04/2008 - revision 198 (Feature Envy bad smell):

The identification of Feature Envy bad smells can also be performed on specific packages of a project.
If the user selects a package instead of the project root, then only the compilation units of the selected package will be included in the analysis.

31/03/2008 - revision 195 (Feature Envy bad smell):

Recursive/self method invocations inside the body of the method to be moved are now properly handled.

24/03/2008 - revision 194 (Feature Envy bad smell):

The amount of memory required for the pre-evaluation of the effect of each refactoring suggestion on design quality has been substantially reduced.

24/03/2008 - revision 194 (Type Checking bad smell):

- Runtime Type Identification by comparing the runtime class of an object (using getClass() method) with a Type Literal (Type.class) is supported.
- The switch cases that do not contain break or return statements are properly handled.
- The type-checking branches should not contain assignments of local variables (precondition).

16/03/2008 - revision 187 (Type Checking bad smell):

- The user has the ability to change the default name of the abstract method.
- The case where multiple code fragments of the same method perform type-checking on the same field or local variable holding the state is properly handled.

12/03/2008 - revision 181 (Type Checking bad smell):

- Instanceof expressions are taken into account for the identification of Replace Conditional with Polymorphism refactoring opportunities.
- Replace Type Code with State/Strategy refactoring has been updated to support cases where the state is stored in a local variable or a parameter of a method that performs type-checking.

27/02/2008 - revision 177 (Feature Envy bad smell):

Move Method Refactoring preconditions have been updated:
The method to be moved should not have a one-to-many relationship with the target class. In other words, it should not access a field of the source class that is an array or collection containing objects of target class type.

25/02/2008 - revision 174 (Feature Envy bad smell):

Bug fixed in the application of Move Method Refactoring:
If an inner class of the source class invokes the method to be moved, then the original method should delegate to the moved method.

23/02/2008 - revision 171 (Feature Envy bad smell):

Bug fixed in the application of Move Method Refactoring:
The target object can also be obtained from the invocation of a getter or delegate method.

14/02/2008 - revision 166 (Feature Envy bad smell):

Move Method Refactoring preconditions have been updated:
- The method to be moved should not be synchronized.
- The precondition that examines the existence of a valid target object has been improved.

10/02/2008 - revision 164 (Feature Envy bad smell):

- The selected method to be moved is automatically renamed if another method of the target class has identical signature.
- Special handling is taken when the source and target TypeDeclarations belong to the same CompilationUnit.

06/02/2008 - revision 161 (Feature Envy bad smell):

- Static method invocations are excluded from entity sets.
- The algorithm for the extraction of candidate refactorings has been improved
(all target objects that satisfy the preconditions are examined according to the number of member accesses and the distance from target class).
- The type of the target object can also be a subclass type of the target class.

02/02/2008 - revision 160 (Feature Envy bad smell):

When the user double-clicks on a candidate "Move Method" or "Extract and Move Method" refactoring, a tooltip appears (by hovering over the highlighted method or method fragment) indicating the total number of methods/fields that the highlighted method or method fragment uses for each accessed class.

20/01/2008 - revision 157 (Feature Envy bad smell):

A method is considered as delegate, if it contains only one statement of the following format:
[return] expression.methodInvocation(arguments);
where expression can be:
1) A field access (the field must be a member of the class that the delegate method belongs to)
2) A parameter of the delegate method
3) A getter method invocation (the returned field must be a member of the class that the delegate method belongs to)
4) A "this" expression
The existence of expression is not obligatory. If it does not exist, then the method delegates to another method of the same class.
The arguments of the method invocation do not have any restrictions.

14/01/2008 - revision 156 (Feature Envy bad smell):

- The classes that extend "junit.framework.TestCase" are automatically excluded from the analysis.
- Fields or parameters having an array as type, are not considered as valid target objects.

06/01/2008 - revision 154 (Feature Envy bad smell):

Local variable declarations are not only sought within VariableDeclarationStatements,
but also within VariableDeclarationExpressions (such as the initializer expressions of ForStatements).

30/12/2007 - revision 152 (Feature Envy bad smell):

The calculation of the Entity Placement metric for each candidate refactoring has been optimized.
As a result, the pre-evaluation of the effect of each candidate refactoring on design quality is performed much faster.

25/12/2007 - revision 150 (Type Checking bad smell):

Complex if statement infix expressions (with conditional operators &&, ||) are properly handled.

For example, the following if statement
if (dragMode == DRAG_MOVE && lastSelected instanceof Node) {...}
is handled as a nested if statement where the outer if performs the type-checking, i.e.
if (dragMode == DRAG_MOVE) {
if (lastSelected instanceof Node) {...}
}