This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Table of contents

• What types of new features are acceptable
• Can I fix a bug by myself
• Code guidelines
  • Nullability
  • Formatting
  • Conditions
  • Code Quality and Readability
  • Method and Class Design
  • Abstraction and Encapsulation
  • Specific Guidelines
  • Copyright notice
  • Include changes in the product
• Commit message rules
• Create pull request
  • Pull request guidelines
• Can I use AI tools
• Guidelines for tagging reviewers
• Contribution rewards

This document provides guidelines for contributing to the DBeaver repository. It outlines the procedures for creating pull requests, fixing bugs, and maintaining consistency in code style within our codebase.

What types of new features are acceptable

Generally, you can suggest any feature you think is useful for the database management tool. However, we usually do not implement features that are too specific to your development process or specific to your internal company processes.

Good options include:

• Adding new database or driver support.
• Extending database metadata read/modify capabilities (e.g., adding trigger reading for a specific database).
• Adding a new SQL generator.
• Adding a new data export format.
• Localizing the DBeaver interface (extend existing localization or add a new language). For instructions, see Localization article.
• Adding a new database-specific tool (e.g., table analysis for a specific database).

You can find code examples of all these features in our codebase.

Important: When suggesting new features, be aware that if a feature already exists in the Lite, Enterprise, Ultimate, or Team Editions, we may not merge it into the Community Edition.

Can I fix a bug by myself

If you identify a bug on our board that needs fixing, and it is not scheduled for the nearest milestone, you are welcome to attempt fixing it yourself. It is a good idea to ask in the ticket because some issues may not be resolved for specific reasons.

If you decide to fix the bug and submit a pull request (refer to the guidelines), the team will review it and provide feedback if necessary. If the PR is merged, the fix will be included in the next release of the DBeaver Community Edition.

For more information in releases, see DBeaver Release Cycles

Code guidelines

The main rule is to use the same code style that is already applied in a particular source file.

• Historically, several slightly different code styles exist within our codebase. If you are modifying an old file, it is best to adhere to the code style already used in that file.
• Do not reformat code or optimize imports in a file you are changing, as it makes it very difficult to review your commits due to the volume of changes.
• Utilize our automatic code style checks for pull requests. Every PR you submit to the dbeaver/dbeaver repository will be checked, and you will be able to see the report of the checklist.

IntelliJ IDEA code style is generated automatically with workspace generation according to the Develop in IDEA guide .

Nullability

To address nullability issues, we use @org.jkiss.code.NotNull and @org.jkiss.code.Nullable annotations throughout our codebase and annotate all API's return types and parameters with these.

• The usage of these annotations is mandatory.
• Carefully design your APIs to limit the utilization of nullable types.
• When dealing with a nullable type, you must explicitly check if it is null and gracefully handle such situations.

Formatting

• Line length must be 140 characters maximum.
• You must use 4-space for standard and continuation indentation.
• Add space between cast and variable (ex. (String) object).
• Arrays don't have space between brackets and braces (ex. new int[]{0xFF, 0xFE, 0x00, 0x00}).
• Declare each variable or field on its own line.
• Long-method signature formatting looks like this:

void test(
    int a,
    int b
) throws Something {
    ...
}

• Ternary operators formatting, if the whole expression doesn't fit one line, looks like this:

var result = test
    ? opt1
    : opt2;

Conditions

• The number of nested conditions should be limited. Ideally, there should be no more than 3.
• Don't forget about the break keyword in loops if further iteration is unplanned.
• Use the switch format by default in cases where it is convenient.

Code Quality and Readability

• Avoid copy-pasting in all places.
• Do not use busy waiting - not to have 100% CPU workload.
• No magic numbers.
• Don't forget null checks in all places where you can have a null argument.
• Avoid doing major refactoring within a small task because it will be difficult to find important changes in PR.
• Use more common type in declarations if possible, ex. List<Something> name = new ArrayList<Something>() instead of ArrayList<Something> name = new ArrayList<Something>().
• Don't use wrapper classes for primitive data types if possible.
• Don't forget to add localization for strings visible in the UI.
• Pay attention to IDE hints on try-with-resources blocks. Use auto-closable constructions. Also, usually, we don't put more than one declaration to one try-with-resource
• Handle exceptional cases in the UI (throw an exception) when necessary.
• Use CommonUtils methods for basic Java conditions (ex. CommonUtils.isNotEmpty()).
• Use var only if you know the argument type. Use it only for simple types like String and int or for long name complex type. Unless it is not handy for code reading.
• Use records only for data holders (DTO), which will never have any logic inside.
• Avoid using VoidProgressMonitor if possible.
• Use static imports only in test classes.

Method and Class Design

• Carefully change the visibility of methods (private -> public). Do not forget about security levels.
• Naming of classes and methods matters.
• Don't forget about javadocs.
• If you've added extension points, provide clear and concise description for them.

Abstraction and Encapsulation

• Don't forget about abstraction levels. Don't try adding specific implementations at the wrong levels.
• Try not to violate encapsulation principles.
• If you can improve your small task at a more abstract level, and it's not expensive, then do it.

Specific Guidelines

• SWT and UI dependencies cannot be added directly to model bundles.
• Hardcoding colors are not allowed, especially in model plugins.
• //$NON-NLS-1$ - use this for strings that do not require localization.

Copyright notice

Every file you add or modify must include the following copyright header at the top:

/*
 * DBeaver - Universal Database Manager
 * Copyright (C) 2010-2025 DBeaver Corp and others
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

Tip: Ensure the copyright header is present and up to date for each file in your pull request.

Include changes in the product

When adding new plugins or making significant changes, ensure they are included in the product build. To do this, list your plugin in the following files:

• features/org.jkiss.dbeaver.db.feature/feature.xml
• plugins/pom.xml

Note

is functional.

Commit message rules

• You must use the GitHub issue prefix at the start of the commit message (like #12345 Add support for super-duper database).
• Summarize the changes in a clear and concise manner.
• Write your commit message as if you are giving a command. For example, use “Add feature” instead of “Added feature” or “Adding feature”.
• Always capitalize the first word of the commit message.
• Do not end commit message with a period.
• Do not force-push, if possible. Especially after the code review started.
• If your commit is mostly AI-generated (90%+), please include Assisted by: {toolname} in your commit message.

Create pull request

Before creating a pull request, you should first create a ticket in our issue tracker if it doesn't exist yet. Leave a comment indicating that you intend to implement the feature or fix the bug yourself. Once the DBeaver development or QA team has responded to your comment, you may begin your work.

You can follow the standard GitHub instructions for this process. Generally, you will need to:

• Create a fork of the dbeaver/dbeaver repository.
• Create a new branch in your fork.
• Commit your changes to this branch, following the commit message rules.
• Create a pull request to the upstream repository.

Important: When committing changes in your branch, you must include the ticket number in the commit message like this: dbeaver/dbeaver#issue-number Initial commit for my super-duper feature. Othervise, your Pull request can't be merged.

You may make any number of commits. We typically perform a squash merge before integrating changes into the main repository.

Pull request guidelines

• Please avoid creating multiple pull requests for a single issue.
• Provide a detailed description of the affected functionality.
• Avoid force-pushing commits in the PR branch, as this makes reading the commit history more difficult.
• If the UI is affected, it is recommended to provide screenshots or a video demonstrating the changes made.

Can I use AI tools

You can use AI tools just like any other tools that help you write code. However, you must remain the author of the code and take full responsibility for it. If AI generates code for you, you must fully understand it, review it, and verify it yourself before submitting a pull request.

Please follow these guidelines when using AI:

• If AI tools were used to generate code, mention it in the PR description. Example: This PR was generated with AI (GitHub Copilot).
• AI-generated contributions must comply with the project’s contribution guidelines, including commit message conventions.
• Carefully review the code before submitting it to the repository. Treat it the same way you would review code written by a colleague.
• Test the changes in DBeaver. Make sure they work correctly in the product before submitting the PR.
• Try to avoid contributions larger than ~300 new lines of code. Large AI-generated changes are difficult to review. With this in mind, large, mostly AI-generated PRs can be rejected without PR review.
• Consider instructing your AI tool not to perform refactoring, unless it is absolutely necessary for logic-related changes.

If we see that AI is being used without understanding the generated code, we may close such PRs. These contributions are very difficult to review and usually do not bring useful improvements to the product.

Guidelines for tagging reviewers

• It's okay to tag someone if your ticket hasn’t had any progress for about a week.
• Please avoid tagging when a PR is ready for re-review, a regular comment is enough.
• Please don't tag repeatedly (e.g., daily). Reviews will be done as time allows.

Contribution rewards

We appreciate your contributions and offer rewards for accepted pull requests. Keep contributing to improve the project and receive a reward from the team! For more details, visit Help the Beaver.