On Fri, 4 Dec 2020 10:29:48 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by >> make for the whole build.) >> >> These data files should move to the module they belong to. The are, after >> all, "source code" for that module that is "compiler" into resulting >> deliverables, for that module. (But the "source code" language is not Java >> or C, but typically a highly domain specific language or data format, and >> the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. >> When such data is changed, most of the time build-dev (or the new build >> label) is involved, even though this has nothing to do with the build. While >> this is annoying, a worse problem is if the actual team that needs to review >> the patch (i.e., the team owning the module) is missed in the review. > > To facilitate review, here is a list on how the different directories under > make/data has moved. > > **To java.base:** > * blacklistedcertsconverter > * cacerts > * characterdata > * charsetmapping > * cldr > * currency > * lsrdata > * publicsuffixlist > * tzdata > * unicodedata > > **To java.desktop:** > * dtdbuilder > * fontconfig > * macosxicons > * x11wrappergen > > **To jdk.compiler:** > * symbols > > **To jdk.jdi:** > * jdwp > > **Remaining in make:** > * bundle > * docs-resources > * macosxsigning > * mainmanifest Are you proposing any text or guidelines to be added to JEP 201 as part of this? I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611
