changelog of jSparrow
changelog of jSparrow
Two major releases per year
Monthly Rule releases
If we developed new rules, they will be released on the 21st of each month
(if the 21st isn’t an Austrian working day- the release will be postponed one month)
Weekly Bugfix releases
Bugfixes will be released each Tuesday
Hotfix Releases can be deployed any time (hopefully not necessary)
This release brings substantial performance improvements, one new rule an various small improvements.
License keys have to be added again!
The way license information is stored changed. For this reason, all previously added license keys need to be added again.
The license key can be added as follows: preferences → jSparrow → License → “Update license key”.
We thank you for your understanding!
Applying rules takes only half the time now!
Process improvements to the rule engine led to an overall reduced time for applying all refactorings in the “Select Rules” wizard. Measurements show that running jSparrow on projects only takes a fraction of the time it previously took.
Some java.util.Date constructors like new Date(int year, int month, int day), new Date(int year, int month, int date, int hrs, int min) and new Date(int year, int month, int date, int hrs, int min, int sec) are deprecated and the Calendar should be used instead. This rule searches for deprecated calendar instances, introduces calendar instances and sets the time corresponding to the parameters in the deprecated constructor, and replaces the latter with an invocation of Calendar.getTime(). For instance, the following code:
// Deprecated Date Constructor Date date = new Date(90, 1, 31);
will be replaced with:
// Calendar instead of deprecated constructor Calendar calendar = Calendar.getInstance(); calendar.set(1990, 1, 31); Date date = calendar.getTime();
Note that the date constructor is implicitly adding 1900 to the first argument (i.e. year), whereas Calendar.set is expecting the exact year value. Therefore, the rule takes care of preparing the parameters of the Calendar.set properly.
If the deprecated constructor is used in a field initialization, then an initializer block is introduced for creating the calendar and initalizing the field properly. See the before/after table.
Since the introduction of the “Rename Fields Rule” (Context Menu → jSparrow → Rename Fields Rule), the “Field Naming Convention Rule” became obsolete. The “Rename Fields Rule” offers more options and has better performance.
On the summary page the value of “Time Saved” now uses man-days, meaning eight-hour working days. Man-days are a more management-friendly unit than 24-hour working days and correspond better with current laws about working hours.
This release contains two changes.
Bugfix for ImmutableStaticFinalCollections-Rule
Diamond Operators in Java 7 are not valid within a method parameter because their type cannot be inferred there. This caused a compilation error, when the rule was applied to a Java 7 project. The fix causes the rule to ignore collections in a Java 7 project, which use a Diamond Operator in their initializer.
Bugfix for FieldRenaming-Rule
Solves an issue where the renaming of a field did not change the references to it in anonymous inner classes.
Free licenses have been reworked to no longer require a connection to the licensing server. When using older versions of jSparrow this might start to see warnings. However, jSparrow functionality should not be adversely impacted.
Any warnings should be able to be removed by upgrading to the latest version of jSparrow. If you experience errors that persist after the upgrade please contact us at firstname.lastname@example.org.
This release adds a new semi-automatic rule called “Rename Fields Rule”.
This new rule can be used for finding and renaming the fields that do not comply with the Naming Conventions.
A configuration wizards provides different refactoring options. The user can select fields to be renamed based on the access modifier key (screenshot of the configuration wizard is given below). As soon as a field which doesn’t comply with the naming conventions is found, the rule will search for its references and compute a renaming. The search scope can be set by the user, either to the current project or to the workspace that eclipse is currently using.
The new name is computed based on the existing field’ name and the configuration options that the user can provide on the rule wizard. On the default configuration, the existing field name is converted to camelCase. Furthermore the occurrences of underscores ‘_’ and dollar-signs ‘$’ are removed and the first letter which is following them (if any) is converted to uppercase. Note however, that the user has the possibility to choose in the configuration wizard whether or not to change the first letter after ‘_’/’$’ to uppercase.
Before the renaming is applied to the original sources, a preview wizard will show the changes related to the renaming of each field. Since a non-private field may be accessed in multiple classes, a single renaming may affect more than one file. A tree-style view in the preview wizard will show the the changes to all of the affected files for each renaming. The user has the possibility to ignore a renaming by unchecking the corresponding element in the tree view.
The renaming cannot be performed automatically if: