On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> The mapping and nr tables, and the *-X.java.template files in >> make/data/charsetmapping are used to generate source code for the java.base >> and jdk.charsets modules. The stdcs-$OS files configure the package and >> module that each charset go into. If the tables used to generate the source >> files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk >> will probably need a new home too. > >> @AlanBateman The process of modularization was not fully completed with >> Project Jigsaw, and a few ugly warts remained. I was under the impression >> that these should be addressed in follow-up fixes, but this was >> unfortunately never done. Charsets and cldrconverter were both split between >> a core portion in java.base and the rest in jdk.charsets and jdk.localedata, >> respectively, but the split was never handled properly, but just "duct >> taped" in place. > > This is a complicated area of the build, not really a Project Jigsaw issue. > It's complicated because the source code for the charsets is generated at > build time and the set of non-standard charsets included in java.base varies > by platform, e.g. there's are several IBMxxx charsets in java.base when > building on AIX that are not interesting to include in java.base on other > platforms. This means we can't split up the mapping tables in > make/data/charsetmapping and put them in different directories. If you are > moving them into the src tree then src/java.base (as you have it) is best but > will still have the ugly wart that some of these mapping tables will be used > to generate code for the jdk.charsets module. @AlanBateman @mlchung @naotoj I can certainly anticipate follow-up cleanups on this patch. In fact, I think this patch has the potential to be a catalyst for such change, since the data that has been "hidden away" in `make` now becomes more visible to the teams that are capable of doing something about it. (With that said, of course the build team will assist in helping to clear up messy code structure, as we always do.) But I think we should be restrictive in trying too hard to make everything right in this single patch; it's better to get things approximately right and then go through the "warts" one by one and solve them properly. @AlanBateman What I meant by Jigsaw was that when the monolithic source code were modularized, the separation of concern between java.base and jdk.charsets/jdk.localedata was not complete, compared to (more or less) all other modules. It might very well be the case that we will never be able to make such a separation; but, prior to Jigsaw, this was not a "wart". It only became a code hygiene issue when some of the charsets and localedata was extraced from java.base. @mlchung My gut reaction is that we should not change idea.sh. First of all, kind of the purpose of this move is to make it clear to module developers the full set of materials their module consists of. That purpose would be sort of defeated, if we were to hide this in a popular IDE configuration. Secondly, I doubt this will add any performance difference. Listing additional files in the workspace is unlikely to do much, unless you actively open and/or interact with these files. But if you are worried, please fetch the PR (Skara adds instructions in the body) and try it out yourself! ------------- PR: https://git.openjdk.java.net/jdk/pull/1611
