hone:optimize

If this is set to true, Docker is used even if phino is available. It is recommended to keep this parameter to false, thus making the build faster if it's possible.

If this is set to true, all our internal bash scripts will start with set -x. This will lead to very verbose output but may help debug internal issues.

An array of patterns to exclude specific .class files from optimization. If not specified, no .class files will be excluded.

Start them with "/target/classes".

Using this regular expression, you can filter in (include) XMIR files that need to be rewritten. It's advised to use this regex to save time. This is a good example to filter in only the files that contain filter() and map() methods:

>(66-69-6C-74-65-72|6D-61-70)<

Here, 66-69-6C-74-65-72 stands for the "filter" and 6D-61-70 for the "map", in hexadecimal format.

To rewrite all files, use the .* pattern

An array of patterns to include specific .class files for optimization. If not specified, all .class files will be included.

Start them with "/target/classes".

The watchdog of rewrite.sh sends TERM to the whole process group once the hone.timeout deadline passes, then gives the tree this grace window to clean up, and finally force-kills whatever survived, so no orphan phino is left burning CPU (see #863).

This number doesn't need to be changed. However, it may be used for debugging. The larger the number, the longer optimization might take. We pass this number to phino as the --max-cycles argument.

This number doesn't need to be changed. However, it may be used for debugging. The larger the number, the longer optimization might take. We pass this number to phino as the --max-depth argument.

For example, "simple,b*,!abc" would include the simple rule, all rules that start with the b character, and exclude the abc rule.

In order to disable them all, simply set this parameter to none.

If you enable them all with "*", your code most definitely will be corrupted, because some rules are for testing purposes only.

Some .class files may all get excluded from the pipeline (for example, the streams/ rules require Java 16 bytecode and exclude every class below it), leaving nothing for the rewrite to work on. If this is set to true, that situation is only logged and the build proceeds; if false, the build fails.

If this is set to true, phino is not executed and no rewriting happens.

After the rewriting, jeo assembles .class files back from XMIR and verifies that each of them conforms to the JVM specification and can be loaded. If this is set to true, that check is not performed: the build is faster, but a broken class reaches the runtime of the user and fails there with a VerifyError.

Turn it on when the verifier stops on a type it can not resolve: jeo knows only the classes it assembles, so a method that touches a type from a dependency fails with ClassNotFoundException instead of a verdict on the bytecode (see jeo#1763).

Small steps mode will apply one rule at a time, producing separate .phi files. This may be useful for debugging the rules. To the contrary, big steps mode will apply all rules at once, which is faster but less transparent for debugging.

By default, it is set to zero, which means the number of threads will be set to the number of CPUs on the machine. This is normally the most efficient choice for large projects. Set it to 1 to disable parallelism, or to any positive value to cap the number of worker threads.

If rewriting for a file takes longer than the timeout, the file remains untouched. The timeout doesn't lead to runtime failure but only to the file processing being skipped.