The Security Group

The Security group is comprised of developers who participate in the design, implementation, and maintenance of Java Security components.

The current members of the Security Group are listed in the census.

Submitting Vulnerabilities

If you have any potential vulnerability to report, please see Oracle's Reporting Security Vulnerabilities page or the OpenJDK Vulnerabilities page.


The term "Security" has broad meanings and interpretations. It spans a wide range of areas, including cryptography, public key infrastructure, secure communication, authentication, and access control. The security component thus comprises a large set of APIs, tools, and implementations of commonly-used security algorithms and protocols.

As security concepts such as permissions are tightly interwoven throughout the entire Java source code, these component pages do not address issues in the other primary component areas (language features and virtual machine implementations, core libraries, graphics subsystems, hotspot, serviceability, etc). For a more detailed treatment, please see the corresponding component pages.

The primary emphasis of these pages is to explore the core security components source bases, and hopefully, get developers up to speed quickly.

The Security Source Layout

The Java security components have been developed and expanded over the years, so the hierarchy may seem complicated simply due to the large number of source files and directories. But the files generally follow fairly straightforward patterns.

All of the security component source code is included in the OpenJDK project under the jdk subtree. As there are so many different components, they are split into many subdirectories, generally based on functional area. In most cases, the main API and implementation-independent classes live in the java/* or javax/* hierarchy, and the implementation classes are in the sun/* hierarchy. The makefiles used to build these files are generally found in the make subdirectory of the same name. Like any software projects, there are exceptions to this guidance.

Cryptographic Cautions

Anyone who has worked in cryptography knows the import/export of cryptographic code involves complicated legal issues. The JCE in OpenJDK has an open cryptographic interface, meaning it does not restrict which providers can be used. Compliance with United States export controls and with local law governing the import/export of products incorporating the JCE in the OpenJDK is the responsibility of the licensee.

Building the security components

The workspace distribution MUST ALWAYS BE buildable from scratch. As the security components have interdependencies with other parts of the JDK, you should always do a successful tops-down build on any new workspace BEFORE making any changes. It will be very helpful to keep the build log, so that if any changes are not compiling, you can determine the correct makefile to use.

When you have changes that are almost ready to submit, you should delete your build directories and rebuild everything from scratch one last time, just to ensure you haven't introduced an incompatible build change or unexpected interdependency. If your changes might impact other workspaces (such as control, deploy, or install), you should build those workspaces as well. See the build instructions for more information on building the various workspaces.

As mentioned earlier, the makefiles generally follow the package hierarchy. If you make a change to, you should go to the make/java/security and issue a make command from there.

Testing your changes

As a rule, unit tests for fixes and new functionality are pretty much mandatory. However, before submitting changes, you should run the relevent regression tests to make sure that the existing tests continue to pass. For the security component, at a minimum you should run:

The full suite will be run before your changes are placed into the source tree. However, if your changes break something, it will be a lot more work to diagnose, and then fix or back out. Do as much testing as possible.