RFR: 8257733: Move module-specific data from make to respective module [v5]
Magnus Ihse Bursie
ihse at openjdk.java.net
Tue Mar 15 23:50:22 UTC 2022
On Mon, 18 Jan 2021 13:47:20 GMT, Magnus Ihse Bursie <ihse at 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.
>>
>> ### Modules reviewed
>>
>> - [x] java.base
>> - [x] java.desktop
>> - [x] jdk.compiler
>> - [x] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>
> Move characterdata templates to share/classes/java/lang.
This PR was almost ready to merge, but unfortunately got closed about a year ago when I disappeared on medical leave. :-( I've been putting off coming back to to this, worried that the merge conflicts would be bad. But no! Git handled the merge fantastically well; the default merge mode even realized that new files in a directory which had been moved elsewhere should probably also be moved to the same place. I was pleasantly surprised how easy this was.
Nevertheless, I have carefully studied the automatic merge for any signs or mistakes. I only found one: a single renamed file (blacklist -> blocked) that it failed to match.
So I believe this PR is back in the same integrateable state that it was when I left it.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1611
More information about the security-dev
mailing list