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

Phil Race philip.race at oracle.com
Thu Feb 27 21:33:32 UTC 2014


Hi,

Leaving aside jigsaw, and regardless of whether they are modifiable,
the question as to whether at runtime they should live in rt.jar or jre/lib
is a separate question than where they would live in the source tree
and one does not necessarily follow the other.

You seem to be touching on the runtime location, but this change
is only about the source location. Where it lives in the source tree
surely doesn't matter to a user.

At runtime,  a resource file like say a font, really should live in
jre/lib (or the jigsaw equivalent thereof). For starters it needs
to be filesystem accessible so the native platform can see it,
and secondly its used by lots of code.
Also users might want to tweak them.
In the source tree because its not associated with a particular
java class then something like src/share makes sense.

The '*psfont* files by contrast, are parsed once by one class
they live alongside. They aren't a general resource for the
rest of the system. So no matter where they go at runtime
they are better co-located with the source.

Where they go at runtime is something we can discuss later,
when that kind of change is ready. As I hinted I hope we
don't just blithely copy all src/share/lib files regardless of
module, and I do hope the jigsaw teams
will discuss this sort of thing long before we see code reviews ..

Since much of it is passed into distant history, its not easy to
say if particular files in jre/lib were there by design, convenience, or
following existing custom. Same goes for where they originate
in the source tree.

Some of the files you list there - notably fontconfig - may be
both user modifiable and start up sensitive.

Others like the cmm ones are not modifiable, but may be startup
sensitive and you are allowed to do some customisation of which
ones are present.

Then there are the cursors. Potentially start-up sensitive,
probably not intended to be user modifiable/replaceable
but it wouldn't surprise me if people have done it ..

The "psfont" ones are not expected to be user modifiable,
but its a very useful 'just in case', to have them in jre/lib.
Where they live at runtime is likely not a big deal for startup
(time to first print isn't something we ever measured :-)),
but they are useful for users to see sometimes.

-phil.

On 02/27/2014 12:58 PM, Mandy Chung wrote:
> 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