Apache Harmony is retired at the Apache Software Foundation since Nov 16, 2011.

The information on these pages may be out of date, or may refer to resources that have moved or have been made read-only.
For more information please refer to the Apache Attic

General

• Home
• License
• Contribution Policy
• Downloads
• Bundles
• FAQ
• Security
• Sitemap

Community

• Get Involved
• Who we are
• Mailing Lists
• Bug Tracker
• Other Projects

Development

• Source Code
• Getting Started
• Project Roadmap
• Resolution Guideline
• Performance

Documentation

• API Reference
• Wiki
• DRLVM
• Class Library
• Build-test Framework

Foundation

• ASF
• Sponsorship
• Thanks

Package Naming Conventions Used in the Apache Harmony Class Library

This section is inspired by, and derived from, the Eclipse™ package naming convention documentation.

The Harmony class library code is organized into Java packages comprising the public API (packages such as java.lang, org.omg.CORBA and so on) and internal implementation packages that all begin org.apache.harmony.

The public APIs are defined by the JSE specification, and as such as managed beyond the direct control of the Apache Harmony project. The other packages are managed by the project development team, and as such the project attributes the following meaning to package names.

All Packages Belong to a Specific Module

Each Java package is owned by a specific module of the Harmony class library. The module name immediately follows the org.apache.harmony prefix.

org.apache.harmony.<module>

Example

org.apache.harmony.luni
org.apache.harmony.security

Package Names within a Module

Modules are free to use whatever package names they choose with the prefix org.apache.harmony.<modulename> .

The following package name segments are reserved to indicate the meanings defined below:

org.apache.harmony.<modulename>.internal

Packages with this prefix are implementation packages for use within the given module. Types and fields that are visible within these packages MUST NOT be used outside the module itself. Some runtime environments may enforce this reduced visibility scope.

org.apache.harmony.<modulename>.tests

Packages with this prefix contain test code that is not part of the module API or implementation. Some builds may not include these packages. See Testing conventions in the Apache Harmony Classlib for details.

org.apache.harmony.<modulename>.examples

Packages with this prefix contain example code that is not part of the module API or implementation. Some builds may not include these packages.

org.apache.harmony.<modulename>.<anything_else>

All other packages within a module contain internal APIs that may be referenced from any module.

In practice, this means that module developers are free to change the code within an internal package without expecting any consequences beyond the module itself. However, module developers who modify code that is not in an internal package must do so in a manner that ensures Java binary compatibility .

Back to top