The 2D Graphics Group

The 2D Graphics group is centered around people interested in the creation and maintenance of the 2D API and implementation.

Introduction

The Java 2D API and its implementation is often not easily separable from other parts of the Java platform.

Generally it implements geometry, text and image APIs and renders these to screen and printer devices using software, or hardware accelerated means, depending on implementation and/or application or user specified system properties.

Very briefly, the core of the API is the class java.awt.Graphics2D. It provides methods for the rendering operations, as well as controlling the state of the Graphics instance.

There's a large supporting cast of classes in the packages

Image I/O provides the means to load and save sampled images where the in-process image use Java2D's image format.

javax.print is tightly integrated with the java.awt.print package which is the 2D API for rendering to printer graphics devices.

There is a wealth of information on the Java 2D API for application developers. e.g. See:


Group policies.

Source code conventions

All source code should follow the standard Java source code conventions as well as jcheck rules. Some of the most common ones to remember are : Consult Code Conventions for the Java(TM) Programming Language for the full list.

Regression tests

Tests should be provided unless clearly infeasible. Automated tests are desirable. SQE rarely run manual tests. Don't give up easily. There are tests that render to a BufferedImage and analyse the resulting contents to see if they behaved correctly, so writing automated tests is possible in more cases than immediately apparent.

Code Reviews

Code reviews are one of the most important mechanisms we have for integrating and shipping good, solid, compatible code. Reviews are also an invaluable source of education for all of us, and a great mechanism for ensuring consistent code quality, as we all read and learn from reading each other's code.

The standard requirement in Java SE is for one (or more) reviewer prior to code freeze and two (or more) reviewers thereafter. The Java client groups have standardized on two reviewers at all times with few exceptions.

The choice of which people review the code is up to the individual engineer and depends upon each specific situation, but some general guidelines are:

It is the responsibility of the implementing engineer to contact the reviewers, respond to their concerns, and make the final code adhere to changes agreed upon by the engineer and the reviewers.

It is the responsibility of the reviewers to provide timely reviews, and understand (to the extent possible) and agree to the changes that the engineer has implemented; when the code is putback to the workspace, the reviewers are also taking responsibility for these changes. We can only have good reviews, and good resulting code, if the reviewers take their jobs seriously and review the changes thoroughly. Given the costs and hassles of maintaining backward-compatible code indefinitely, we cannot risk code going in that is only cursorily reviewed; it is far easier and cheaper to catch flaws in the review process than it is to fix them in bugs and escalations later on.

The most common exceptions to the two reviewer policy would be for

The general process for reviews is as follows:


Regarding Java 2D's source code.

All of the Java 2D's code is in the "jdk" repository, so all references below are relative to the root of the "jdk" workspace.

Aside from the information below developers may find it useful to consult Distinguishing 2D and AWT source files..

Most of the relevant sources have a java and native component.

The Java 2D-related java code is can be browsed from Netbeans by opening the "awt2d" project. This project also contains the files belonging to AWT - see the README file in the "awt2d" project directory. (note that with some effort the native code can be worked on from Netbeans as well, see the README mentioned above)

All sources are either 'share' or 'windows' or 'solaris', the latter of which in fact includes Linux(TM) and is so named for historical reasons and because in practice the Solaris(TM) code and the Linux code are usually so close that a few ifs or ifdefs suffice to distinguish them. This is partially explained by observing that for 2D, Solaris and Linux are just both platforms for X11.

Most of 2D's code is in 'share'. Even the OpenGL code.There is a still significant but lesser amount of code that is specific to X11 or Win32/GDI.  But here for brevity we just point out the shared locations.

These all are under "src/share". The Java classes are located corresponding to the package hierarchy. E.g. java.awt.Graphics2D is in:

Implementation (non-public) classes are generally in a package starting with "sun.". E.g.:

There are exceptions, notably:

Java 2D also has a substantial amount of native code. This is located in similar manner :

(Note that the platform-specific native code is naturally in the corresponding src/[platform]/native/.. directory)

The shared code location contains essentially complete implementations of everything since 2D has its own code for everything needed to implement the API.

The relevant jdk workspace make files are structured in the following way:

A more fine grained break down of 2D files, particularly versus AWT component files, can be found here.

One can also build the 2d source tree from the "awt2d" Netbeans project (both native and java).


Non-open Java 2D source code.

Some parts of Java 2D were not part of the initial OpenJDK source release, or are different than in the commercial releases from Sun and its licensees. We want to remove these so that the full OpenJDK can be built entirely from sources. We call this "removing encumbrances", a reference to the legal term "encumbered".

Generally the reason for this is that the code was licensed by Sun from a 3rd party.

Here's a summary of the major source code encumbrances that were identified and the current state.

  1. Native code color management system

    The Color Management System - a C library - and several color profile files were licensed for use in JDK 1.2. To replace this "Little CMS" (lcms) was identified as a suitable replacement open source library. There is a pluggable layer, so that for now the commercial version can use the old CMS and OpenJDK can use lcms.

    src/share/classes/sun/java2d/cmm contains the pluggable layer. CMSManager.java is the class called by 2D code that needs to invoke color operations. On first load CMSManager uses the java.util.ServiceLoader class to locate an implementation of the PCMM interface.

    Glue code for LittleCMS that implements that interface is in:

    • src/share/classes/sun/java2d/cmm/lcms

    In turn it loads the native lcms library.

    The source code for OpenJDK's copy of this is in:

    • src/share/native/sun/java2d/cmm/lcms

    Color profiles are located in:

    • src/share/lib/cmm/lcms

    Status : This was resolved before launch. Most bugs were resolved by JDK 7 GA, once we upgraded to LittleCMS 2.0 The only outstanding one is : not in the OpenJDK. These are non-essential because the Sun JRE doesn't require them.

    • 6523402: Some quality problems with GRAY, PYCC and CIEXYZ color spaces with lcms library

  2. Font rasteriser

    The font rasteriser is a native library licensed for use by Java 2D in JDK 1.2. To replace it in the OpenJDK we identified freetype as the most viable cross-platform alternative. It is already used by the native desktops on Linux and OpenSolaris.

    Similarly to the CMS case, there is a pluggable layer so that the commercial JDK can use the licensed rasteriser whilst OpenJDK uses freetype. The file

    • src/share/classes/sun/font/FontScaler.java
    was created as an internal interface to the rasterisers, and OpenJDK hardwires its implementation in
    • src/share/classes/sun/font/FreetypeFontScaler.java

    Status : This work is complete and has been in OpenJDK since Aug. 2007

  3. Antialiasing graphics rasteriser.

    The current default rasteriser is the Marlin rasteriser, developed from the Pisces sources as a more mature and fully featured rasteriser that can compete with Ductus on single-threaded performance and completely obsolete it in multi-threaded performance. This rasteriser completes the open-source work for the Antialiasing graphics rasteriser and will eventually allow us to deprecate and delete the other implementations over time. As well, Marlin resolves the "improvements needed" issues with the Pisces rasteriser noted below.

    The Ductus rasteriser is a small set of Java classes backed by a native library used to perform path stroking and filling. It was licensed for use in JDK 1.2, and needed an open source replacement. It is still shipped in Oracle distributions, but is no longer the default rasteriser in those deployments as of JDK9.

    The Pisces renderer was identified as a replacement early on since it was already open source and it could be adapted to the JDK relatively easily, selecting only the parts needed. The initial Pisces integration resolved the open source conflict but required improvements. Specifically:

    • Performance is not as good as the library it replaces.
    • Fixed point is used with little or no overflow protection
    • Support for the STROKE_CONTROL hint

    src/share/classes/sun/java2d/pipe/RenderingEngine defines the pluggable layer. The class uses reflection and the -Dsun.java2d.renderer=<classname> system property to locate an implementation of this abstract class.

    The complete Marlin sources and the class that implements this interface is in:

    • src/share/classes/sun/java2d/marlin/

    The partial Pisces sources and the class that implements this interface is in:

    • src/share/classes/sun/java2d/pisces/

    Status : This is fully resolved now with the new default Marlin rasteriser, though the proprietary Ductus rasteriser is still shipped with Oracle distributions as an alternative.

Community

Related searches:
source native openjdk library should
gipoco.com is neither affiliated with the authors of this page nor responsible for its contents. This is a safe-cache copy of the original web site.