Information for new developers

So you want to start contributing to Derby... We welcome your contributions! This page lists information to help a developer to get started contributing to Derby.

Ongoing Projects

Below are some ongoing projects, which are great starting places and always available.

Test the Documentation

Pick a manual, review it carefully and test all the examples. If you find something that looks wrong post a question to If the community confirms it as a documentation bug, file a Jira entry.

Answer User Questions

Answer user questions as they come in to Make sure bugs get filed properly when they come up. File bugs for documentation corrections and update FAQ's.

Check Out, Build the Code and run the Tests

% mkdir derby ; svn co derby

Read the how to build derby section of the downloads page and the building hints.

Before making any changes to Derby, running the tests will ensure that your build was successful. See also the testing wiki page for information on the recent push toward JUnit tests.

Having problems? Ask the derby-dev list and/or provide feedback on how the setup or instructions could be improved.

Add Functional Tests

Until we have 100% code coverage we know there are still opportunities to enhance functional testing. See testing/README.htm for information on writing tests. Write the tests and if you hit something that doesn't work, post a question to for confirmation. If the community confirms it as a bug, file a Jira entry.

Add More Existing Tests To the Network Server Suite

This is entered as DERBY-209. Choosing this as an initial task will help you come up to speed on the test harness and network server.

Add Stress and Scalability Tests

Choose something that Derby does and push it to the limit. Some of these kinds of tests can be incorporated into the functional test framework. For example DERBY-216 is a task to expand on the test case for DERBY-176 related to cases where large amounts of byte code are generated.

Provide Benchmark / Performance Examples

Derby could use some contributions in the benchmark/performance example area. This is a good area for someone who wants to learn any of java, jdbc, sql and/or derby. It would be nice to have some public examples applications/code which runs well in the derby embedded server domain. Extra credit:

  • Compare/Contrast performance of same application with other dbs.
  • Implement public domain standard benchmark.

Derby integration with other technologies

Integrating Derby with other technologies will be a good start for experts in those areas. This will open up interesting uses for Derby and will be a valuable contribution. You can mail to and if you find any issues doing this. The results can be added to Derby website or to Derby Wiki. Some ideas suggested on mailing lists are web-based APIs for Derby and telnet access to Derby databases.

Write Tests for an Upcoming Feature

You may ask how you can do this, but because Derby is standards based, you can often install your second favorite relational database software, one that has the feature already implemented and run your tests against that. Then you can post your test to the Jira entry. This will facilitate implementation and improve quality.

Apply, Test and Review Patches

Apply, review and test patches that have been posted for review. Really make a careful detailed review, try to understand all the code and if you don't, ask questions about it. Look at the functional tests supplied and see if you can think of additional cases that could be added. This is a highly valuable task. If the committers don't have community members doing this, they spend all their time reviewing and committing and never contributing themselves. This task will help preserve the quality of Derby. For more information see PatchAdvice and PatchListMaintenance.

Cleanup and Expand Javadoc

Much of the javadoc could be expanded and improved upon. package.html files can be created to give a package overview. Committers are always happy to assist, review and expedite these kinds of contributions because they enhance the overall competency of the community.

Write a design document for an area which interests you

As a part of learning process, it would be good to write a design document or document explaining the internals for an area of Derby. The document can be a formal paper or a page added to this Wiki. This would help other new developers.

Find differences between embedded and network client driver

File JIRA entries and document incompatibilities between Derby client and embedded driver. These could be indicated in the documentation as areas that may change, so we don't get locked into any incompatibilities. This task could be done in conjunction with DERBY-209.

First Code Changes

For your first code change choose something that looks really easy. Something you can do and do well. This will be something different for different people. The point of your first change should be to go through the whole process and be comfortable with it before taking on major coding projects.

A "Do no harm" mantra is always important if you are considering changing Derby. Your first priority in introducing any new functionality should be to not introduce a regression in functionality or performance.

To select an issue to work on, you may search for a JIRA issue with "Newcomer" component.

Take a look at DerbyContributorChecklist

See how a change is committed to the code line, understand what committers are looking for in a patch: DerbyCommitProcess

Working in the Derby Core Systems

It is relatively easy to work on the "outskirts" of Derby such as tools, documentation, QA, and some runtime services. But what if there's something you would really like to add or fix in the core of Derby, and none of the existing contributors are touching the bugs you have logged.

One of the challenges of contributing to a database system is that the core of the system involves algorithms, designs and architectures that are well known to those who know them, but are a bit of a mystery to those who are new to them. It can seem daunting to venture into these waters. We would very much like to have contributions in these areas, and probably the best way to do this is to enroll a guide or mentor to help you get introduced into this area. Here is a suggested approach:

  • Indicate your interest - send an email to derby-dev saying you would like to work on this code, indicate you are a newbie, and ask if any of the old hands would like to guide you through the waters
  • If you get a volunteer, work with this person to vet your ideas and get suggestions. They can help you understand the code and algorithms and make your experience much more enjoyable.
  • If you don't get a volunteer, start poking around and sending emails about what you're thinking of doing, and even submit an initial patch. It is more than likely that you will enroll a mentor fairly quickly this way; in general someone who likes to code can't help but get involved when someone is working on code that is familiar to them.

The main point here is, don't let the inherent complexity of the Derby core system code be a block to your contribution. As a community we welcome your contributions, and want to help you get involved.

Reference Materials

For general process and guidelines:

For the mechanics of building Derby and submitting a patch:

For Derby Internals:

Read the javadoc:

List of standards/specifications used by Derby




JDBC 2.0


JDBC 3.0 (JSR-53)


JDBC 4.0 (JSR-221)


JDBC Optional Package for CDC/Foundation Profile (JSR -169)


Java Transaction API (JTA) (JSR-907)








DRDA Version 3

Used by Derby Network Server

DRDA Version 4

Used by Derby Network Server

The XA+ Specification Version 2


Java Virtual Machine Specification

relevant to byte code generation

  • No labels