The 2D Graphics Group
This Group was dissolved and consolidated into the Client Libraries 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
java.awt
java.awt.color
java.awt.font
java.awt.geom
java.awt.image
java.awt.print
(Java 2D printing to a printer graphics)javax.imageio
(aka Image I/O)javax.print
(aka the Java Printing Service, works with java.awt.print)
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.
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 :- All lines <= 80 chars
- No tabs, indents are always 4 spaces.
- if blocks should use { .. } even for one line
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:
- At least one reviewer should have some familiarity with this technology and/or area of the code
- Two reviewers should be looking at everything, so if one reviewer is chosen for only a segment of any particular change, you should get other reviewers to review the sections that are left with only one reviewer.
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
- 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 build breakage.
The general process for reviews is as follows:
- Webrev: You should run a webrev of your changes against the parent workspace.
- Identify reviewers : use the appropriate tool/mailing list to contact reviewers
- Provide a description of the bug, the fix, and what testing has been 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 useful to consult Distinguishing 2D and AWT source files..
Most of the relevant sources have a java and native component.
Most of 2D's code is in 'share'. There is a still significant but lesser amount of code that is specific to X11 or Win32/GDI or macOS. But here for brevity we just point out the shared locations.
These all are under "share"
. The Java
classes 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 in a 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 is compiled:
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 a
corresponding [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 java.desktop make files found in
make/modules/java.desktop
.
A more fine grained break down of 2D files, particularly versus AWT component files, can be found here.
- Mailing lists
- 2d-dev - 2D OpenJDK development mailing list