Pricing

jSparrow Pricing

jSparrow Product

jSparrow Images

Shown thumbnail:

jSparrow folder

jSparrow Product information

Automatic Java Code Fixer

Fastest, securest, and easiest way to upgrade

Price: $19.2/month

VAT excluded.

Pick a licence

jSparrow analyses Java files or whole projects for technical problems including security breaches. After finding the issues the developer will be asked to decide which of the multiple errors found across the software should be fixed by jSparrow simultaneously. jSparrow can solve more than 40 % of Sonarqube findings automatically. Additionally, jSparrow has been thoroughly tested to be able to improve across software files and thus not break the in-use software.

  • jSparrow Eclipse IDE Basic licence key include 100 automatic rules i.e. quick fixes. The Rules have these focus areas (tags): IO Operations, Lambda, Logging, Loop, Old Language Constructs, Performance, Readability, Security, String Manipulation, and Testing.

  • Tag example: jSparrow can replace vulnerable code fragments with secure alternatives, see rules tagged “Security” for more information.

  • This product includes 10 Markers to help developers mitigate issues and code smells in real-time.

  • This product allows customization of Logging rules; The location, where logs are written, becomes independent of the code and can be customized at runtime.

  • jSparrow has rules i.e. quick-fixes for Java versions: 1.1, 1.2, 1.3, 1.4, 1.7, 1.8, 5, 6, 7, 8, 9, 10, 11, 16,

  • jSparrow Eclipse IDE Basic licence key will be sent via E-mail. This key can only be used by one computer. For more processes, see jSparrow Eclipse IDE Enterprise.

  • Instructions for how to use jSparrow can be found on the documentation space. If there are any problems, please feel free to contact us.

Buy jSparrow Section

$19.2/month

In Stock.

 Add to basket  Buy now

Sold by jSparrow Distribution GmbH through FastSpring.

Product statistics

Project neo4j-community statistics

neo4j-community logo

Project

neo4j-community

Files: 5,641

jSparrow executed results:
  • Files fixed: 3,541

  • Issues fixed: 81,621

  • Total working hours saved: 5,104 hours, 10 minutes

5,104 hours * 49.95 $/hour = $ 254,944.8 savings

Project dbeaver statistics

dbeaver logo

Project

dbeaver

Files: 4,053

jSparrow executed results:
  • Files fixed: 2,601

  • Issues fixed: 28,463

  • Total working hours saved: 2,329 hours, 49 minutes

2,329 hours * 49.95 $/hour = $ 116,333.55 savings

Project biojava statistics

biojava logo

Project

biojava

Files: 1,321

jSparrow executed results:
  • Files fixed: 1,114

  • Issues fixed: 25,981

  • Total working hours saved: 1,940 hours, 10 minutes

1,940 hours * 49.95 $/hour = $ 96,903 savings

Project orientdb-core statistics

orientdb-core logo

Project

orientdb-core

Files: 2,503

jSparrow executed results:
  • Files fixed: 1,795

  • Issues fixed: 38,067

  • Total working hours saved: 2,438 hours, 10 minutes

2,438 hours * 49.95 $/hour = $ 121,778.1 savings

Product Comparison

Table container

Table

jSparrow sonarlint Snyk Eclipse AutoRefactor IntelliJ
Logo jsparrow logo sonarlint logo snyk logo eclipse logo autorefactor logo intellij logo
Java Code Analyzer Yescheck icon Yescheck icon Nocross icon Yescheck icon Yescheck icon Yescheck icon

Attributes

Open source Nocross icon Yescheck icon Nocross icon Yescheck icon Yescheck icon Nocross icon
Tool improvements releases/per year 12 N/A N/A 4 N/A 2
Documented Rules/inspections Yescheck icon Yescheck icon Yescheck icon Nocross icon Nocross icon Nocross icon

Functionality

Backwards refactoring Nocross icon Nocross icon Nocross icon Nocross icon Nocross icon Yescheck icon
Multiple Cleanups simultaneously Yescheck icon Nocross icon Nocross icon Nocross icon Nocross icon Yescheck icon
Profiles Yescheck icon Yescheck icon Yescheck icon Nocross icon Nocross icon Yescheck icon

UI

Diff View Yescheck icon Nocross icon Nocross icon Nocross icon Nocross icon Nocross icon
Menu Yescheck icon Yescheck icon Yescheck icon Yescheck icon Yescheck icon Yescheck icon
Right click Yescheck icon Yescheck icon N/A Nocross icon Nocross icon Yescheck icon
Short cuts Nocross icon Yescheck icon N/A Yescheck icon Nocross icon Yescheck icon

Environments

Eclipse Yescheck icon Yescheck icon Nocross icon Yescheck icon Yescheck icon Yescheck icon
Github Yescheck icon Yescheck icon Yescheck icon Nocross icon Nocross icon Nocross icon
IntelliJ Nocross icon Yescheck icon Yescheck icon Nocross icon Nocross icon Nocross icon
Maven Yescheck icon Yescheck icon N/A Nocross icon Nocross icon Nocross icon

Upgrade old Java constructs to:

Java 8 Yescheck icon Nocross icon Nocross icon Yescheck icon Yescheck icon Yescheck icon
Java 9 Yescheck icon Nocross icon Nocross icon Yescheck icon Nocross icon Yescheck icon
Java 11 Yescheck icon Nocross icon Nocross icon Yescheck icon Nocross icon Yescheck icon
Java 14 Yescheck icon Nocross icon Nocross icon Nocross icon Nocross icon Yescheck icon
Java 15 Yescheck icon Nocross icon Nocross icon Nocross icon Nocross icon N/A
Java 16 Yescheck icon Nocross icon Nocross icon Nocross icon Nocross icon Nocross icon

Refactoring tags/focus

Formatting Yescheck icon Nocross icon Nocross icon Yescheck icon Yescheck icon Yescheck icon
IO Operations Yescheck icon Nocross icon Nocross icon Nocross icon Nocross icon Nocross icon
Lambda Yescheck icon Nocross icon Nocross icon Yescheck icon Nocross icon Yescheck icon
Logging Yescheck icon Nocross icon Nocross icon Nocross icon Nocross icon Nocross icon
Performance Yescheck icon Nocross icon Nocross icon Yescheck icon Nocross icon Yes(?)
Performance Yescheck icon Nocross icon Nocross icon Nocross icon Nocross icon Yes(?)
Readability Yescheck icon Nocross icon Nocross icon Yescheck icon Yescheck icon Yescheck icon
Reporting Yescheck icon Yescheck icon Yescheck icon Nocross icon Nocross icon Nocross icon
Security Yescheck icon Nocross icon Yescheck icon Nocross icon Nocross icon N/A
Testing Yescheck icon Nocross icon Nocross icon Nocross icon Nocross icon Nocross icon

Product Description

The jSparrow Product

jSparrow is a precision tool that can maintain and fix issues (bugs, flaws, and breaches) across files, but making sure that your software has the exact same functionality and interfaces. This allows your developers to start the next sprint without maintenance work, making sure that they can work faster in their agile environment and allow them to implement and improve new features for your customers.

The biggest difference between jSparrow maintenance and common maintenance tools is that jSparrow finds multitudes of different issues and fixes them automatically.

  • With jSparrow we want to
    • improve software speed and performance for private users,
    • reduce technical debts for upkeep of Java Legacies,
    • help developers write state-of-the-art syntaxes with cleaner, more efficient, and more secure code,
    • and increase internal stability, security, and performance for companies worldwide.

Maintenance needs to be as easy and fast as possible; with jSparrow it easy to integrate software maintenance into day-to-day operations.

License:

jSparrow Eclipse Basic

Product type:

License key (numerical and alphabetical set of string)

Updates:

A new rule is released every month and is automatically added to your license

Floating:

False

Current version:

4.2.0

Rules:

100

Manufacturer:

Splendit IT-Consulting GmbH

Customers questions and answers

FAQ

Ask and questions answered





    What is jSparrow?

    jSparrow is a refactoring tool (Java Code Fixer) for Java developers. Its purpose is to help developers fix and automate maintenance tasks, good code quality, state-of-the-art practices, increased cyber security, platform stability, modernization obligations, and application performance.

    jSparrow is, in a shorter description, an All-in-One Fixing Tool for Java code.

    What is a jSparrow Rule?

    A jSparrow rule is a definition of a granular refactoring performed by jSparrow. The scope of a single rule is very specific. E.g., the ‘Use Functional Interface’ rule transforms anonymous classes to lambda expressions when possible. Rules can be combined to obtain broader refactorings. All jSparrow rules are described and illustrated with code examples in the jSparrow documentation space.

    More questions:

    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?
    Business point of view:

    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.

    Technical point of view:

    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.

    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?
    code process illustration

    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:

    Code example from real world project The purpose of this code is to generate a list of String values from a given input and concatenate them into one single value. A while loop is used to iterate through all elements of the generated list and append them into a StringBuilder. In the end, the StringBuilder is converted into a single String value and returned.

    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();

    Transform the while loop into enhanced for-loop The first improvement we can do to this code, is to eliminate some boilerplate code by transforming the while loop into an enhanced for loop (introduced since Java 5). Internally, the javac compiler converts the enhanced for-loop into a while loop with an iterator. The performance of this code is not going to be affected by this transformation.

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

    Transform the enhanced for-loop into a stream We can continue further and simplify the code by converting the enhanced for-loop into a stream. Arguably, the cost of creating the stream will pay off when working with large collections.

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

    Use method references The lambda expression in the forEach can be further simplified into a method reference.

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

    Using String Joiner The code above, is still using a StringBuilder for the sole purpose of concatenating the values of a list. Since the concatenation of the values does not contain any complex logic, we can simplify the code further by using a StringJoiner:

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