HS Logo HS Codex Tech Debt News Pricing Issues Accounts Contact Us Careers FAQ navbar-icon

Frequently Asked Questions

No. The Codex looks at the output from the SCAs.

The Codex has been integrated to run with the Java Deprecation Scanner and the SonarSource SonarQube scanner. If you would like us to look at integrating with a different SCA please let us know through our Contact Us page.

The Codex is currently programmed to migrate Java source code projects. However, multiple issues that are picked up through the SonarQube SCA from a non-Java project can be fixed by the Codex. Additional languages are on the Roadmap. Contact us if you need a language sooner than we are currently planning.

Yes!

This depends on how large your project file is. Remember that the running is not just the Codex. The process when integrated with an SCM such as GitHub is Checkout, Build, Verify Build, Run SCAs, Codex, Verify Update, Publish. We have seen times from 30 minutes to 5 hours so far for all steps.

If your code fails to compile the Codex will not run. We recommend automated testing (aka Unit Testing).

Two reasons:

  1. (Primary) Some of the SCAs measure Test Coverage. Access to this report is available to the project owners.
  2. On occasion, a project's tests are failing prior to being accessed by the Codex. When a test fails in the Verify Update stage we check the cause to verify if there is something that needs to be fixed in the Codex. A test failing before the Codex runs should therefore not be checked after the Codex has run.

Your choice. We are setup to run as either a SaaS service or a PaaS service.

  • If you have an SCA setup, you may choose to use our (less expensive) SaaS offering. In this case, you would download some lightweight plugins that would access your SCA to determine what would need to be addressed.
  • If you want to free up some engineering time, you might find our PaaS offering to be a cost-effective solution for your needs.

No. If you want us to run a third-party library you will need to talk to us about it. Note that we are already supporting several Opensource projects.

We follow precise steps in the development of our Solution Templates. First the problem is identified by an SCA. We label and categorize the problem based on our own assessment of difficulty. Second, we refer to industry recommendations and solutions for best application of a solution, ie. how to use or implement a new API. The industry recommendations are broken into three categories for us and we refer to specific sources for each category:

  • Deprecated APIs -> Oracle & JCP documentation
  • Performance, code smell (maintainability), stability -> SonarSource, Joshua Block, et al
  • Vulnerabilities & bugs -> SonarSource, Cert, OWASP, MITRE, and other appropriate sources

The code is tested after a thorough review period before being used as a complete solution.
There are outlying solutions that a customer may be using that we cannot catch. We always recommend that the customer vet all migrations and updates that are submitted by our service. We do not actually read the customer code. Since we do not keep a copy of the customers code we cannot see if an outlier occurs.

We do not store any customer files without explicit customer permission.

We refer to a Solution Template as the blueprint applied to a specific code segment to fix a problem – whether the problem is a deprecated API, a code smell, a vulnerability, or something else.

  • In-depth analysis of migration compatibility
  • Analysis of deleted, deprecated, and/or moved APIs
    • Deleted means completely removed from Java 11 (or other targeted Java version)
    • Deprecated means should not be in active use and marked (most likely) for future deletion
    • Moved means that the API has been moved from one library and/or package to another
  • Analysis of third-party dependencies (libraries)
  • Analyze the tools being used
    • Continuous Integration
    • Deployment servers
    • Code analysis
  • Post-analysis
    • Prepare and present the migration plan
    • Explain benefits and processes
  • Non-regression tests, change jdk on development platforms, QA platforms, and production platforms

Most analysis steps begin by inspecting the results from an SCA. Our services run instantly after an SCA scan completes. If you want to run an analysis you will need to run the SCA before using the Codex. If you want help with this let us know and we can discuss what can be done. If an individual analysis is needed special consulting work may be required.

You will need a build platform that is running, at minimum, Java 11. Significant changes happened between Java 8 and Java 11. We suggest that you create a new branch in your repository and create a Java 11 build on it to run the new Codex output. Note that multiple versions of Java can co-exist simultaneously. As a result, if your project will not compile, run tests under the current version of Java, you can still build with the appropriate version of Java, then run our plugins.

No. We can "inject" into your build via CLI options to your build command. No changes to your build configurations are required.