Pricing

What is the jSparrow Eclipse Plugin?

The jSparrow Eclipse Plugin (JEP) is the integration of jSparrow in the Eclipse IDE. JEP has a rich user interface and allows customers to have full control over the refactorings they perform on the source base. JEP is available in Eclipse Marketplace and is compatible with all the latest Eclipse versions starting from Eclipse Photon.

What is jSparrow Maven Plugin?

The jSparrow Maven Plugin (JMP) is a continuous integration tool to apply automatic refactorings. JMP provides a standalone version of jSparrow which contains nearly the same functionalities as the jSparrow Eclipse Plugin but works without user interaction. The necessary configurations can be provided through yml files.

Can I create my own rule?

jSparrow focuses on providing ready to use well-tested refactoring rules. We are open to recommendations. Any customer request is considered and prioritized on our roadmap.

Can I include jSparrow in a Jenkins build?

Yes, you can include the jSparrow Maven Plugin into a Jenkins build process. The configuration is highly customizable and depends very much on the environment. For more information, see Integrating jSparrow Maven Plugin in Jenkins.

Definition of refactoring

Refactoring is a process of restructuring and reordering an existing source code, without affecting its external forms of action and behavior. It usually does so by transforming functions and rethinking algorithms.

In simpler terms, refactoring is changing a software internally (code) without affecting the software externally (software UI, UX etc.)

What is technical debt?

Very often, development teams face challenging deadlines and are pressured by clients or by marketing teams. In such circumstances, the decisions they take tend to favor speedy delivery and fast results over quality code. If such code can perform it could pass as complete, it will require maintenance, updates, bug fixes, or improvements sooner or later. When developers have to deal with it again, they inevitably are forced to invest the time, money, and effort to finish and perfect what was initially a code that was far from perfect.

Just like the concept of borrowed money in the financial industry, technical debt refers to borrowed resources in the future – and especially time & resources to refactor a code to make it easier to read and maintain for other developers.

Why do I need refactoring?

There are many reasons to do refactoring. A few reasons are 1) the size of software grows with time, 2) developers will change, and 3) new developers will join the team, in these situations code maintenance becomes increasingly difficult. Each situation also introduces more complexity, increases the possibility of bugs and redundant code as well as decreases in reliability.

When refactoring is implemented in the original development process, it could also be considered a valuable long-term investment in the longevity and reliability of the software. However, manual rewrites can make developers miss unwanted hidden values in the original code and manual refactoring is almost always costly and time consuming. In such cases automated refactoring could help improve code performance and code security faster – giving more time and freedom to build up software.

What is the purpose of refactoring the code?

Code refactoring is usually used for improving the non-functional attributes of a software system like:

• higher efficiency,
• maintainability,
• security,
• extendability

In addition, it can dramatically reduce costs and improve overall code performance, as refactoring can help find and remove code smells that could otherwise prove to be expensive or be slowing down the software.

What is continuous refactoring?

Also known as Merciless refactoring or the Boy scout rule: a refactoring that is ceaseless and integrated into the work of a developer’s team. The boy scout rule states that you have to leave the playground cleaner than you’ve found it.

In continuous refactoring, you include refactoring as part of your daily tasks, and you keep the balance between it and adding new features. This requires good team communication, good organization, and very often a ‘collective code’, where everybody can improve the work of somebody else. Many teams are worried about that approach because it also includes the risk of failing. It does, however, have the opportunity for continuous improvement, which could return huge benefits, such as high quality and low costs.

What is automatic code refactoring?

Automatic code refactoring is to increase code quality automatically rather than manually. Automatic refactorings usually happens in the IDE environment or in the dev-ops tool chain where a developer can highlight a code. It can also be taken further by replacing old language constructs with new up-to-date alternatives, resolving security issues, eliminating duplicates, eliminating usages of deprecated code, migrating the versions of third-party libraries, changing the name of methods, renaming argument variables, or reducing the number of arguments.

Why Refactor Java software?

As software size grows with time, as developers change, and as new software developers join the team, code maintenance becomes increasingly difficult. Each situation also introduces more complexity, increases the possibility of bugs and redundant code as well as decreases in reliability. Very often, rewriting software completely is not necessary. Manual rewrites can make developers miss unwanted hidden values in the original code. This manual work is almost always costly and time consuming. In such cases refactoring could help improve code performance and code security. When refactoring is implemented in the original development process, it could also be considered a valuable long-term investment in the longevity and reliability of the software.

The new Java 6-month release cadence has shown to be successful at least regarding the introduction of new modern language features to the Java language. For example Java Records, Pattern Matching for Instanceof, Text Blocks, and Switch Expressions are now formalized as standard features. Many more new APIs and internal JDK improvements are released and will continue being released with each semi annual JDK update. By upgrading to the latest JDK, one may immediately get a more efficient, more secure, and lighter JVM. Additionally, this opens the possibility to employ the new language features into the existing source base. For example, by using automated refactoring tools, a fair amount of old language constructs like Anonymous Classes, Switch statements, Try-Catch statements, etc, can be replaced with the more up-to-date alternatives like Lambda Expressions, Switch Expressions, Try-With-Resources, etc. On the other hand, by delaying the upgrade, users would deprive themselves of the important improvements on the late JDK versions. Thus, accumulating more technical debt.

Does refactoring improve performance?

A refactored code is simpler, and it does increase system responsiveness. Users can operate faster and have reduced waiting times and error messages. Another benefit is also reduced power consumption. Many case studies repeatedly prove that refactoring leads to improved performance for systems, with all the added benefits such as higher work efficiency, saved resources, and optimized budgets and costs. Particularly in Java, some new language constructs are more efficient than their outdated alternatives.

• Lambda: A Peek Under The Hood – Brian Goetz
• JDK 8: Lambda Performance study
• Lambda Performance with Sergey Kuksenko

When should refactoring be done in agile?

Nowadays, agile software development is prevalent and dominant, and agile teams are extending their code from one release to another. However, without continuous refactoring, such a process is hard to maintain: it becomes more and more challenging to operate on a code that otherwise could become intensely cluttered, hard to read, and unorganized. It also creates unhealthy, unstructured dependencies from packages and classes, overly significant dependencies on specific classes, and bad allocations of class responsibilities. And these are just some of the most common from hundreds of issues that arise from unclear and disorganized code. The extreme programming (XP) practices, which are part of the Agile frameworks used by the IT companies, also exclusively include the following list of steps, which also involve refactoring:

• Code the unit test first (TDD)
• Pair program
• Setup a dedicated integration computer (build machine)
• Run acceptance tests
• Refactoring

How do I refactor old code?

You can’t always count on code, believing that you will work with fresh and new standards with good readability. The chances are that you have to deal with old code that is outdated or hung up on features that are no longer supported. And usually, it is precisely old code that needs refactoring more than any other. Such codes include unknown risks and dependencies, which are vital but hard to read. Moreover, usually, there are solid reasons for such code to be written in a particular way. This is why the approach must be careful and methodical.

When dealing with old code, your primary choice is to write a new code or refactor it. It depends on what your priorities and resources are when you make this choice. When you rewrite a principle is always more straightforward, as you are in complete control of the process. However, it poses a serious issue, as it requires maintaining two systems simultaneously while you run the old code and write the new one.

Code refactoring allows you to slowly rework the old code by taking a class or a function and slowly working on it in your project’s scope and resources. If all your tests and integrations are in place, you will make sure that everything runs smoothly. However, code refactoring has limitations as you are stuck with the primary code language, and most probably, your core framework will remain the same.

The first important step when dealing with legacy code is to have a deep understanding of the existing code and the problem domain. This may be a real challenge as the code may be hard to read and the documentation may be missing, incomplete, or even incorrect.

Afterwards, it is important to make sure that a suite of tests that you can trust is in place. If the tests are already in, we should make sure that they provide good coverage. Otherwise, we have to come up with a way to add tests that will at least cover the parts of the code that will be affected by the refactoring we are about to make. Writing unit tests in a legacy system may be hard or impossible. Therefore, we may be forced to write other automated tests, e.g., UI tests, integration tests, etc. In such cases, the goal of the refactoring should also include writing unit tests for the refactored code.

The next step would be to define a goal of what we want to achieve with the refactoring. The goal should be cohesive and the outcome should be well defined.

Finally, we may enter a loop of changing the code, running tests, and adding new tests if necessary, until the goal is achieved. In this way we would simultaneously clean up some part of the code and also enrich the test suite.

When to do refactoring?

Key questions your team and the project manager need to answer when dealing with this problem are, for example, if you plan to make significant technological shifts e.g. going to modern cloud-based systems. In such cases, a complete rewrite makes better sense.

Another question is, what is your medium to long-term plans? And do you plan to use this software language, integrate within another framework or stay the same? If this is a core service of your business and something you can shut down or completely change overnight, then refactoring is most certainly a better option.

It also depends on your human capital – if the people who have written the original code are still available to you, it makes sense to continue with the old code rather than switch to a new one.

It also depends entirely on your particular needs, restrictions, and requirements. But careful planning and taking all points of the equation into account are essential. This is not a decision to be taken lightly.

What refactoring is not?

Refactoring, as mentioned in No1, means changing the internal structure of a code, but without affecting the external behavior. Hence a common misconception to refactoring could also include massive changes or a complete overhaul, or a code rewrite to be considered a refactoring. This is wrong, as it violates either the first premise, or the second of the definition.

Fixing software bugs, improving software interface is also not a refactoring. These are both changes, but again, they don’t face the criteria. When software bugs are fixed, these improvements on the code DO change the external behavior. Improving software interface again does not meet the criteria of changing the internal structure of the code.

How can you solve the issue of technical debt?

Most development teams consider a code ready when it’s good to pass the QA stage. For example, software with a hard-to-read code can give the QA stages easily. But as time goes by, it becomes more and more challenging to implement new features and sort out bugs. Hence, one of the essential parts in addressing technical debt is to educate organizations about its overall costs and importance. Implementing and using automatic refactoring like jSparrow also helps prevent technical debt right from the development process. Additionally, a large number of existing quality or security issues have unique resolutions that can be addressed automatically. In such cases, automated refactoring tools are very desirable. Last but not least, implementing refactoring within the agile environment can ensure that your team is indeed doing the best it can to prevent all future problems related to technical debt.

Why refactor Java sources?

The new Java 6-month release cadence has shown to be successful at least regarding the introduction of new modern language features to the Java language. For example Java Records, Pattern Matching for Instanceof, Text Blocks, and Switch Expressions are now formalized as standard features. Many more new APIs and internal JDK improvements are released and will continue being released with each semiannual JDK update. By upgrading to the latest JDK, one may immediately get a more efficient, more secure, and lighter JVM. Additionally, this opens the possibility to employ the new language features into the existing source base. For example, by using automated refactoring tools, a fair amount of old language constructs like Anonymous Classes, Switch statements, Try-Catch statements, etc, can be replaced with the more up-to-date alternatives like Lambda Expressions, Switch Expressions, Try-With-Resources, etc. On the other hand, by delaying the upgrade, users would deprive themselves of the important improvements on the late JDK versions. Thus, accumulating more technical debt.

What is a code refactoring example?

With Java evolution and the new features introduced, coding standards have changed. Lambdas and streams were a game changer in Java 8. Later on, Java 9 brought significant features which not only helped developers to modularize the code, but also improved the performance of the JVM and added more modern language flavors to Java. Let’s take an example from a real world project and see how we can transform it into today’s Java:

StringBuilder sb = new StringBuilder();List<String> list = generateList(input);int i = 0; while (i<list.size()) {String t = list.get(i);sb.append(t); i++; } return sb.toString();

StringBuilder sb = new StringBuilder();List<String> list = generateList(input);for(String t : list) {sb.append(t); } return sb.toString(); 

StringBuilder sb = new StringBuilder();List<String> list = generateList(input);list.forEach(t -> sb.append(t));return sb.toString();  

StringBuilder sb = new StringBuilder();List<String> list = generateList(input);list.forEach(sb::append); return sb.toString();  

List<String> list = generateList(input);return String.join("", list);