[OpenJDK 2D-Dev] RFR: JDK-8035821: Move psfont properties files from src/share/classes to src/share/lib

Mandy Chung mandy.chung at oracle.com
Thu Feb 27 20:58:07 UTC 2014


Hi Phil,

Is psfont*.properties* file more of a resource file?  Is there any 
reason (or specification) that psfont*.properties has to be in JRE/lib 
directory? One potential reason might be the startup performance (warm 
start/cold start) to avoid opening a jar file? They don't look like a 
user-editable properties file and that could be the reason why they live 
in src/share/classes.

As part of the modularization effort, we want to separate the 
user-editable configuration file from the non-modifiable resource 
files.   For the non-modifiable resource files, does it make sense to 
move them together with the classes like other java resources?

What Erik is doing to prepare for the source restructuring to enable the 
module build such that we can build one module at a time (i.e. you can 
just build the desktop module + its dependencies and skip the rest of 
JDK build).

Here are the list of files under JRE/lib directory.  Do you see any 
reason any of these can be moved to a different directory e.g. together 
with the classses?

lib/cmm/CIEXYZ.pf
lib/cmm/GRAY.pf
lib/cmm/LINEAR_RGB.pf
lib/cmm/PYCC.pf
lib/cmm/sRGB.pf
lib/content-types.properties
lib/flavormap.properties
lib/fontconfig.bfc
lib/fontconfig.properties.src
lib/images/cursors/cursors.properties
lib/images/cursors/invalid32x32.gif
lib/images/cursors/motif_CopyDrop32x32.gif
lib/images/cursors/motif_CopyNoDrop32x32.gif
lib/images/cursors/motif_LinkDrop32x32.gif
lib/images/cursors/motif_LinkNoDrop32x32.gif
lib/images/cursors/motif_MoveDrop32x32.gif
lib/images/cursors/motif_MoveNoDrop32x32.gif
lib/psfont.properties.ja
lib/psfontj2d.properties
lib/sound.properties

Mandy
[1] 
http://hg.openjdk.java.net/jdk9/dev/jdk/file/tip/src/share/classes/sun/print/PSPrinterJob.java

On 2/27/14 12:32 PM, Phil Race wrote:
> Magnus,
> I completely understand that the content of the files and the runtime
> behaviour aren't affected, but logically you'd want to put things 
> together,
> not spread out across the source tree. Then its much easier for people to
> understand what uses what.
>
> If a jigsaw build somehow can't cope with this, then maybe the problem 
> is there ?
> I'd have to understand that.
> Those files are only relevant to the 'client' module. In a jigsaw 
> world, where will they live ?
> Is there even a concept of an installed jre/lib, or a source tree's 
> src/share/lib ?
>
> And FWIW I presume you need a src/<platform>/lib too .. ?
>
> -phil.
>
> On 2/27/2014 12:03 AM, Magnus Ihse Bursie wrote:
>> Phil,
>>
>> First of all, note that this is a change in build only. This change 
>> will not affect the source code in question, nor how it is executed. 
>> The properties files will end up in the very same location as a 
>> result of the build, wether with or without this patch. Hence, there 
>> is no need to run any printing tests.
>>
>> We can of course just as well integrate this patch using jdk9/client, 
>> if you prefer.
>>
>> Some background here might be useful, so you can understand what Erik 
>> is trying to achieve. Most files are stored in a suitable location: 
>> java files that should be compiled in src/*/classes. Files that 
>> should be copied to the lib directory in the resulting image are in 
>> src/share/lib. However, there are a few files that are stored 
>> elsewhere. This has been handled using hard-coded exception rules in 
>> the build system. Erik has spent some serious effort lately on 
>> cleaning up those idiosyncrasies.
>>
>> That normalization was something that we have been planning to do all 
>> along, but it has become urgent due to the jigsaw project. While we 
>> can handle the exceptions, even if its ugly, it has turned into a 
>> blocker to handle all those misplaced files when we need to reshuffle 
>> all source code.
>>
>> So, to summarize:
>>   * The code using those files will not be affected.
>>   * This is needed for the jigsaw project.
>>
>> With that information, I hope you can reconsider your position.
>>
>> /Magnus
>>
>> 26 feb 2014 kl. 19:48 skrev Phil Race <philip.race at oracle.com>:
>>
>>> PS the same goes for other things like font property changes if you 
>>> have such in mind.
>>> And unless you intend to run the printing test suite before you push,
>>> then changes like this *must* go into jdk9/client. Not jdk9/dev.
>>> Moot however, since I don't agree with the change.
>>>
>>> -phil.
>>>
>>> On 2/26/2014 10:46 AM, Phil Race wrote:
>>>> Adding 2d-dev as 2d owns this file and might like to know where it 
>>>> went.
>>>> My 2p : the files are however interpreted solely by the code with 
>>>> which it is co-located.
>>>> So unless the build will come crashing down around us, I'd very 
>>>> much prefer that these
>>>> files stay exactly where I put them ...
>>>>
>>>>
>>>> -phil.
>>>>
>>>> On 2/26/2014 7:38 AM, Tim Bell wrote:
>>>>> Hi Erik:
>>>>>
>>>>>> Here is another simple file move to bring more order to the 
>>>>>> sources. This time it's the psfont properties files that are 
>>>>>> being moved from src/share/classes to src/share/lib since in the 
>>>>>> build, they are just copied to the lib directory, so should not 
>>>>>> be confused with java resource files.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8035821
>>>>>> Webrev: http://cr.openjdk.java.net/~erikj/8035821/webrev.jdk.01/
>>>>> Looks good to me.
>>>>>
>>>>> Tim
>




More information about the build-dev mailing list