We welcome all contributions! Please open a pull request. Common contributions may include:
- Adding support for a new DBMS.
- Adding more tests of existing benchmarks.
- Fixing any bugs or known issues.
Although you can use any IDE you prefer, there are some configurations for VSCode that you may find useful included in the repository, including Github Codespaces and VSCode devcontainer support to automatically handle dependencies, environment setup, code formatting, and more.
Please see the existing MySQL and PostgreSQL code for an example.
To allow reviewers to focus more on code content and not style nits, PR #416 added support for auto formatting code at compile time according to Google Java Style using google-java-format and fmt-maven-plugin Maven plugins.
Be sure to commit and include these changes in your PRs when submitting them so that the CI pipeline passes.
Additionally, this formatting style is included in the VSCode settings files for this repo.
In an effort to enforce clean, safe, maintainable code, PR #413 enabled the -Werror
and -Xlint:all
options for the javac
compiler.
This means that any compiler warnings will cause the build to fail.
If you are seeing a build failure due to a compiler warning, please fix the warning or (on rare occassions) add an exception to the line causing the issue.
In general, we prefer to avoid the var
keyword in favor of explicit types.
Per the Java Language Specification, arrays of generic types are not allowed and will cause compiler warnings (e.g., unchecked cast
)
In some cases, you can extend a generic type to create a non-generic type that can be used in an array.
For instance,
// Simple generic class overload to avoid some cast warnings.
class SomeTypeList extends LinkedList<SomeType> {}
SomeTypeList[] someTypeLists = new SomeTypeList[] {
new SomeTypeList(),
new SomeTypeList(),
new SomeTypeList(),
};
possible 'this' escape before subclass is fully initialized
The this-escape
warning above is caused by passing using this.someOverridableMethod()
in a constructor.
This could in theory cause problems with a subclass not being fully initialized when the method is called.
Since many of our classes are not designed to be subclassed, we can safely ignore this warning by marking the class as final
rather than completely rewrite the class initialization.