JDK-8039273 : Font related files should not be modified in ${java.home}/lib
  • Type: Sub-task
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-04-04
  • Updated: 2019-09-12
  • Resolved: 2016-12-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b151Fixed
Related Reports
Relates :  
JDK-8088325 - FX needs to be aware of JDK module system constraints or layout in locating JDK fonts
Relates :  
JDK-8230889 - Allow a physical font to act as the "final fallback" for any logical font
Relates :  
JDK-8049930 - Move configuration files from ${java.home}/lib directory to ${java.home}/conf
Description
This bug is submitted to explore whether it is really necessary to have font files and font configuration in ${java.home}/lib.

The motive for this bug is the modular JDK where we need the flexibility to put anything that is module-private into a module-private location. In this case we need to understand whether the font files are a "supported interface", same thing for the font configuration. If they are not a supported interface then we need the flexibility to move these to a desktop module specific location, resources files are okay.  If they are a supported interface (say, we support customers/developers changing the font config files) then they are candidates to put into a top-level location for user-editable configuration.

One other thing that is important for font files is to understand whether they are used directly by FX or not and whether this is a critical requirement. If so then it may be necessary to provide a JDK-specific API to provide access to the fonts.
Comments
There is no need for a release note as this is covered in the updated I18N guide
14-04-2017
In 9 we will treat lib as read-only and any font related files in there - including font files themselves, as implementation internal. The majority of what users would do in customising the JRE fonts will be achieved by relocating that functionality to ${java.home}/conf/fonts. That sub-folder won't exist by default. It will only exist if the user (admin) provides that customisation. The updated I18N Guide will specify this. That will be a JDK 9 update of the JDK 8 version: https://docs.oracle.com/javase/8/docs/technotes/guides/intl/ Release Notes should briefly describe this and refer to the I18N guide for more information.
08-12-2016
Corresponding FX bug: https://javafx-jira.kenai.com/browse/RT-37912
11-03-2015
This issue was originally on the list for JEP 220 but has to be timed out and dropped from the list. So for now at least, these means there is no longer any supported means to drop font files into the runtime image, references to the legacy mechanism can be dropped from the documentation as part of the refresh being done for JEP 220.
07-02-2015
I think we have to timeout this issue and conclude that nothing in ${java.home}/lib/fonts/** will be supported in JDK 9. I'll drop the bertha label from this issue on the assumption that there isn't anything to be done for the modular image milestone. When Phil gets cycles to re-examine this area then maybe a supported means to add configuration via properties files in ${java.home}/conf can be added. This might also be the place to configure alternative locations of font files to replace the legacy "fallback" mechanism.
24-10-2014
Phil said on a call today that the psfont* files should not be moved to conf. Instead, the tentative plan is to replace this code at some point and part of that will eliminate these properties files.
20-10-2014
Phil - do you know if psfontj2d.properties and psfont.properties.ja are a supported interface or not? Chris is in the process of doing the lib -> conf move and want to know if these should move. Any CCCs or documentation to help on these two would be useful.
16-10-2014
I think it would be better to just drop support lib/fonts/fallback rather than adding support for conf/fonts/fallback (or better is ${java.home}ext/fonts). I don't have an opinion as to the means by which alternative fonts or locations is configured. System properties or a user editable file in ${java.home}/conf (to configure locations) would be fine and should be easy to do, if such a mechanism does not exist already. For fontconfig.html then it would be good to sort out the ambiguity over what is supported or not. It is very strange to document the means by which the config file is configured but at the same time include statements such as "Note however that this is a modification of the JRE, and Sun does not support modified JREs". In any case, in order to make progress on this issue then we need the exact list of user-editable configuration files that should move to the conf directory. Also if there are any remaining normative or non-normative references to lib in the javadoc then we need to get that list too.
11-10-2014
> This document will need re-worked for JDK 9 you principally mean change references to lib to conf, and make the changes needed to explain the consequences of the bfc files perhaps being hidden out of sight ? As I said, the lib/fonts/fallback was there because a system property wasn't acceptable. I don't see the harm in keeping the same notion under conf. Its the most compatible and least work and doesn't create any problems for jigsaw that I can see. "Some means to configure the JDK" sounds like a lot more work even if we had something that was viable there.
10-10-2014
The lib/fonts/fallback directory sounds like a mis-feature. Can it be dropped in JDK 9? Clearly this would require a CCC and release notes. I can't imagine too many customers copying font files into this directory as they would loose them each time that they upgrade or switch JDKs. The more usual way that this type of things is a system property or some means to configure the JDK as to where additional fonts can be located. For the font configuration then the latest guide seems to be here: http://docs.oracle.com/javase/8/docs/technotes/guides/intl/fontconfig.html This document will need re-worked for JDK 9 (several guides will need to be updated for the same reason). So given the font configuration then which files should move to conf? Are the .src files just template files that should move? The .bfc are binary files so I assume they are not editable and will not be moving.
10-10-2014
Any update on this? Should we just ignore ${java.home}/lib/fonts and assume there isn't anything supported and that nothing should be moved to the conf directory?
04-10-2014
It would be good to get a definite plan together for what is going to happen. So far it seems that there are 3 areas where changes are required: 1. User-editable files that are supported to be edited by customers/developers move to ${java.home}/conf. Phil needs to say what these are, I think it is files such as fontconfig.properties.src. 2. Module-private files (the binary font files) that can't be resources need to move to a module private location. Based on recent discussions this looks like ${java.home}/lib/$MODULE/resources. This is clearly disruptive to FX that might be accessing these font files directly so some coordination is required. It may mean adding a jdk.fonts module that supports a java and/or native API to get the font file locations. 3. The means by which end customers/developers can configure additional fonts (and maybe search order) might need to be looked at. I can't tell from the comments so far what the complete set of configurations options are but we have to get away from asking customers to copy font files into a JDK "fallback" directory in the JDK. If it doesn't exist already then it would be good to investigate a means to support configuring the JDK to find fonts elsewhere.
09-08-2014
In JDK8, a customer can alter the files under ${java.home}/lib/fonts, delete or add binary font files. It can also add a subdirectory called "fallback". One option would be that customer could continue to install their font files in lib/fonts (lib/fonts/fallback) while the JRE doesn't have that directory anymore. However that won't allow deleting JRE font files if it's moved to module-private location. According to Phil, the fonts implementation and JavaFX need a native API to read the binary files if it's moved to module-private location. Such native interface should return the path of the module-private file that the native code can open and read the module-private file. For the font config files, the *.bfc fontconfig files are binary files that are not user editable. A customer can remove the bfc file and drop a properties file in the lib directory. If bfc is present, it will use the .bfc file for configuration; if it's absent, it will use the properties file for configuration.
18-07-2014
Thanks Mandy. So is there any way to configure the fonts without changing anything in the JDK/JRE tree? The long standing feedback from customers and developers has been they don't like having to change things in the JDK image because they loose those changes when they switch JDKs (upgrade, move to another machine, etc.). Maybe this is the opportunity to provide a better solution for cases where the out of the box configuration isn't good enough.
15-07-2014
Thanks Mandy - can we get the description corrected as it's only user editable/configuration files that should be moved to conf. This might include font configuration files (once their supportability is established) but I assume the binary font files should not move to conf but instead be moved to a module-private location.
15-07-2014
Would it be possible to get a full summary as to what is being proposed? (I don't have access to the FX JIRA).
12-07-2014
I submitted FX JIRA bug : https://javafx-jira.kenai.com/browse/RT-37912
11-07-2014
The font file location is something that is used by people customising the JRE and the font configuration file syntax is fully specified and people do add and alter these. Whilst we don't expect to take support calls on people editing these files and making mistakes or make the JRE resilient against their mistakes we do know and expect that people need to do this. Additionally a subdirectory called 'fallback' is also supported Therefore we should make it as easy as possible to transition and this appears to mean that if "lib/fonts" isn't available, instead there will be a top-level "conf/fonts" laid out and supported identically to what there is now. So this bug becomes "font files should be located under conf/fonts as well as lib/fonts" This is for people who customise their JRE implementations A problematic and separate issue is that FX needs to load the font files. It needs direcr access to the standalone on-disk files. The immediate fix in FX will be to look in 'conf' as well as 'lib' However that means 1) FX relies on the desktop module 2) FX relies on the layout of the desktop image - ie where it put the fonts So FX either needs to 1) copy the fonts and we ship and install the copies 2) We need a new font module upon which FX will depend That module could provide a single *private* API like "getFontDir()" FX can then enumerate the fonts therein and not need knowledge of the image. Again, getResourceAsStream() doesn't help as FX needs to access the files from native code - and even platform APIs - that take a filepath,
30-06-2014
If there are issues with the working in the image I/O javadoc then it would be better to move that to a new bug. The long standing wording is really odd anyway because the extensions directory isn't usually on the system class path, instead it's that the system class loader delegates to the extensions class loader that includes the contents of the ext in its search. On the question of the JDK top-level lib directory vs. the JRE lib directory then the distinction between a JRE and JDK just goes away with a module image.
05-04-2014
" Are there normative references to this location? " - I don't know but I am 100% sure that people have been using it for 15 years and that we did document somewhere the usage of it. "In Java SE 8 / JDK 8 then we asked all teams to downgrade normative references to files in ${java.home}" - I never received such a request. "As regards FX" - a private API I hope, not a public one ?
04-04-2014
It's not clear which README you are talking about, I assume the README related to redistribution so I suggest assuming that this will change significantly in JDK 9 as the JDK layout will be very different and there will be different ways to combine applications with runtimes. If I understand the read of your comments then the only supported interface is dropping your own fonts into ${java.home}/lib. Are there normative references to this location? In Java SE 8 / JDK 8 then we asked all teams to downgrade normative references to files in ${java.home} to be non-normative to make it easier to change things in JDK 8. Maybe something was missed here or maybe this is support is JDK-specific? It would be useful to now if adding fonts to the lib directory is the only supported mechanism or whether there are other ways to do this. As regards FX then have it hunt around in the JRE image is a problem, I think this will need to be looked at to see whether an API will be needed to access them.
04-04-2014
We allow people to drop additional fonts into the font directory and have them get appended to the logical fonts and located via API The JDK README also discusses adding in Lucida fonts from the JDK into a JRE distribution if they aren't there - since the Windows JRE did not always include all of them. So bottom line this is completely supported and public. Providing your own fontconfig.properties file isn't something we support, in large measure because the results are unpredictable and its difficult to get right, so we don't want to take calls on that. But distros can & do provide their own and in a pinch a customer could provide their own, but I would not want to give the impression this is customisable. However if the fonts that are used by the fontconfig file need to be placed in jre/lib/fonts it is very awkward to put the fontconfig file in some hidden place .. Also, yes, FX does go and hunt directly for the JRE default font too and it expects to find it in jre/lib/fonts. I would go so far as to say that the location jre/lib/fonts is an 'exported' interface. Now what do I do with this bug?
04-04-2014