The 2D Graphics Group

ThisGroup wasdissolved and consolidated into theClient Libraries Group.

The 2D Graphicsgroup is centered aroundpeople interested in the creation and maintenance of the 2D API andimplementation.

Introduction

The Java 2D API and its implementation isoften not easily separable from other parts of the Javaplatform.

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

Very briefly, the core of the API is the classjava.awt.Graphics2D. It provides methods for the renderingoperations, as well as controlling the state of the Graphicsinstance.

There's a large supporting cast of classes in thepackages

java.awt
java.awt.color
java.awt.font
java.awt.geom
java.awt.image
java.awt.print (Java 2D printing to a printergraphics)
javax.imageio (aka Image I/O)
javax.print (aka the Java Printing Service, workswith java.awt.print)

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

javax.print is tightly integrated withthe java.awt.print package which is the 2D API for rendering toprinter graphics devices.

Group policies.

Source code conventions

All source code should follow the standard Java source codeconventions as well as jcheck rules. Some of the most common onesto remember are :

All lines <= 80 chars
No tabs, indents are always 4 spaces.
if blocks should use { .. } even for one line

ConsultCodeConventions for the Java(TM) Programming Language for the fulllist.

Regression tests

Tests should be provided unless clearly infeasible. Automatedtests are desirable. SQE rarely run manual tests. Don't give upeasily. There are tests that render to a BufferedImage and analysethe resulting contents to see if they behaved correctly, so writingautomated tests is possible in more cases than immediatelyapparent.

Code Reviews

Code reviews are one of the most important mechanisms we havefor integrating and shipping good, solid, compatible code. Reviewsare also an invaluable source of education for all of us, and agreat mechanism for ensuring consistent code quality, as we allread 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) reviewersthereafter. The Java client groups have standardized on tworeviewers at all times with few exceptions.

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

At least one reviewer should have some familiarity with thistechnology and/or area of the code
Two reviewers should be looking at everything, so if onereviewer is chosen for only a segment of any particular change, youshould get other reviewers to review the sections that are leftwith only one reviewer.

It is the responsibility of the implementing engineer to contactthe reviewers, respond to their concerns, and make the final codeadhere to changes agreed upon by the engineer and thereviewers.

It is the responsibility of the reviewers to provide timelyreviews, and understand (to the extent possible) and agree to thechanges that the engineer has implemented; when the code is putbackto the workspace,the reviewers are also takingresponsibility for these changes. We can only have goodreviews, and good resulting code, if the reviewers take their jobsseriously and review the changes thoroughly. Given the costs andhassles of maintaining backward-compatible code indefinitely, wecannot risk code going in that is only cursorily reviewed; it isfar easier and cheaper to catch flaws in the review process than itis to fix them in bugs and escalations later on.

The most common exceptions to the two reviewer policy would befor

Documentation updates that do not affect the specification
Identical backports previously reviewed by two reviewers
Trivial test only changes.
Time critical, simple changes such as backing out a buildbreakage.

The general process for reviews is as follows:

Webrev: You should run a webrev of your changes against theparent workspace.
Identify reviewers : use the appropriate tool/mailing list tocontact reviewers
Provide a description of the bug, the fix, and what testing hasbeen done.
Respond to reviewers concerns
Push a fix to the appropriate repo, listing all reviewers.

Regarding Java 2D's source code.

All of Java 2D's code is in the "java.desktop"module, so all references below are relative to the root of the"java.desktop" module.

Aside from the information below developers may find it usefulto consultDistinguishing 2D and AWTsource files..

Most of the relevant sources have a java and nativecomponent.

Most of 2D's code is in 'share'. There is a stillsignificant but lesser amount of code that is specific to X11 orWin32/GDI or macOS. But here for brevity we just point out theshared locations.

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

share/classes/java/awt/Graphics2D.java

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

share/classes/sun/awt
share/classes/sun/awt/geom
share/classes/sun/awt/image
share/classes/sun/font
share/classes/sun/java2d
share/classes/sun/print

There are exceptions, notably:

share/classes/com/sun/imageio

Java 2D also has a substantial amount of native code.This is organised by the shared library into which it iscompiled:

share/native/libawt
share/native/libfontmanager
share/native/libfreetype
share/native/libharfbuzz
share/native/libjavajpeg
share/native/liblcms
share/native/libmlib_image

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

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

The relevant java.desktop make files found inmake/modules/java.desktop.

A more fine grained break down of 2D files, particularly versusAWT component files, can be foundhere.

Mailing lists
- 2d-dev - 2DOpenJDK development mailing list