Skip to main content

OpenJDK Mercurial Transition Update 2

Posted by kellyohair on September 12, 2007 at 12:15 PM PDT

Update 2

    The work to create OpenJDK/JDK7 Mercurial repositories is still
    progressing, we had a hickup getting the langtools
    split off from the j2se and it did not make Build 19 as you probably
    well know.
    We integrated the split into Build 20 and have spent the last
    2 weeks adjusting to the change. So
    Build 20 will contain a separate "langtools" (javac, javah, javap, apt, and javadoc) directory in the Build 20 source bundles, which
    will become a standalone Mercurial repository soon.

    Build 20 also includes a great deal of Makefile changes and
    minor changes to many files to remove SCCS keywords in the
    sources and test files. We haven't fixed everything, but we
    are making quite a bit of progress.

    In Build 21 (or Build 22 as a backup) we hope to split
    off corba, jaxp, and jaxws as separate openjdk repositories.
    (At some later date, we may be able to better interface with
    the corba, jaxp, and jaxws teams in terms of how they integrate
    and how we accept changes from these areas into the jdk product,
    so this is just step one).
    Other changes in Build 21 and 22 will be around SCCS keyword
    changes, and of course all the various teams are also integrating
    changes all around us, which is to some degree why this is taking a bit longer.
    Build changes often impact everyone, and we are dealing with a moving target.

    We continue to target Build 22 (Build 23 as a backup) be the last
    promotion built via the TeamWare workspaces, the Build after
    this last TeamWare one would be done via Mercurial repositories.
    Then at some point
    after that, we can start working on providing those same
    OpenJDK repositories on the openjdk website.

    In other areas, we are starting to look at the various conventions
    we want to put in place for things
    like changeset comments, etc. and
    how we will use Mercurial hooks to protect us from mistakes
    and verify the conventions are followed.

Build 20 Issues with regards to the langtools split

  • You need 'ant' to build langtools, and you need to make sure the
    environment variable ANT_HOME is set (especially on Windows).
  • When building from the control/make/Makefile, langtools is built
    first, then the resulting 'dist' directory is supplied to the
    j2se build via the variable ALT_LANGTOOLS_DIST.
    The langtools dist/bootstrap/javac.jar is then run with the BOOT jdk (ALT_BOOTDIR)
    to create all the resulting jdk classes for the build.

    IF langtools is not built or not found, then the javac
    launcher from the ALT_JDK_IMPORT_PATH is run (a partial jdk build).
    This ALT_JDK_IMPORT_PATH is assumed to be a recent jdk7 build,
    or at least recent enough to handle building the jdk7 itself.

    It's acceptable to set ALT_BOOTDIR and ALT_JDK_IMPORT_PATH to
    the same jdk7, and might even work if they both refer to
    the same jdk6, but no guarantees.

    ALT_JDK_IMPORT_PATH continues to be the place to import parts of
    a jdk that a partial build has chosen to not build, but it
    is also now a backup place to get a javac when the langtools
    dist area is not available.
  • Prior to the langtools split, the jdk was built in a somewhat
    bootstrap process, primarily because the javac sources were part
    of the rest of the jdk.
    Now that javac is separate, and can be run with a BOOT jdk,
    the thought was that the entire jdk could be built without actually
    being run during the build process, a great simplification
    and a benefit to anyone doing cross-platform builds.
    Unfortunately, it turns out that the build procedure relied on a few
    tools like rmic, idlj, native2ascii, and javazic be
    run from the freshly built classes of these tools in the jdk source.
    So for the time being, these tools will be run from the BOOT jdk
    or run via the BOOT jdk until we can resolve these issues.
    The actual jdk install image (e.g. rt.jar tools.jar etc.)
    is now created before it is run now,
    although the image is massaged a little after it's initial image
    is created.


Related Topics >>