United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6940890 : Java doesn't pick up the correct fontconfig files in latest Solaris Next builds.

Details
Type:
Enhancement
Submit Date:
2010-04-05
Status:
Resolved
Updated Date:
2010-12-06
Project Name:
JDK
Resolved Date:
2010-05-03
Component:
client-libs
OS:
open_solaris
Sub-Component:
2d
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
osol_2010.05
Fixed Versions:
6u21 (b04)

Related Reports
Backport:
Relates:

Sub Tasks

Description
I trying dbxtool on build #136 of Solaris Next (was OpenSolaris), it was
discovered that the "monospaced" font in the window in the bottom left of
the tool, was displaying ugly text (poor spacing).

This was discussed on the dbx-interest list, and it was found that instead
of using /usr/jdk/instances/jdk1.6.0/jre/lib/fontconfig.OpenSolaris.bfc
Java was now just using /usr/jdk/instances/jdk1.6.0/jre/lib/fontconfig.bfc.

Specifically, (by running truss), it was found to be tring the following:

7877/14:        access("/usr/jdk/instances/jdk1.6.0/jre/lib/fontconfig.5.11.properties", R_OK) Err#2 ENOENT
7877/14:        access("/usr/jdk/instances/jdk1.6.0/jre/lib/fontconfig.5.11.bfc", R_OK) Err#2 ENOENT
7877/14:        access("/usr/jdk/instances/jdk1.6.0/jre/lib/fontconfig.properties", R_OK) Err#2 ENOENT
7877/14:        access("/usr/jdk/instances/jdk1.6.0/jre/lib/fontconfig.bfc", R_OK) = 0
7877/14:        stat64("/usr/jdk/instances/jdk1.6.0/jre/lib/fonts/fallback", 0xCD3FE980) Err#2 ENOENT
7877/14:        open64("/usr/jdk/instances/jdk1.6.0/jre/lib/fontconfig.bfc", O_RDONLY) = 50

Java is looking for "OpenSolaris" in the /etc/release file, to determine
whether it should be using .../fontconfig.OpenSolaris.bfc The /etc/release
file for build #136 now contains:

$ cat /etc/release
                       Solaris Next Development snv_136 X86
       Copyright 2010, Oracle and/or its affiliates.  All rights reserved.
                             Assembled 26 March 2010

There has been more discussion on the dbx-interest list, and I'll leave it
to Phil and David to determine the best solution going forward.

                                    

Comments
EVALUATION

It's too risky to make any drastic changes to the fontconfig area in 6u21.
                                     
2010-04-15
EVALUATION

JDK is accommodating the case where OpenSolaris lacks the commercial fonts
available on every release of Solaris since the 1990's.

After the update to /etc/release, JDK no longer can distinguish OpenSolaris from "Nevada"
(aka Solaris Next), so falls back to the default assumption of a commercial Solaris.
Unfortunately that no longer includes the fonts. They have to be obtained separately.

Even if Solaris makes it more difficult for users to have high quality fonts,
by making them have to go install them from a download repository (assuming
they know to go look), we should not preclude users who do so from using them
as their JDK fonts. 

JDK 7 will also misidentify the version because of /etc/release, but I
believe should survive because it also checks for the presence of the font
which is in the first slot of the first logical font, and falls back to
using /usr/lib/libfontconfig (a new JDK 7 capability).
However for JDK 7 we should look again at that mis-identification
as its going to cause extra work

original webrev for that fix is here: http://sa.sfbay.sun.com/projects/java2d_data/7/6378099.3/

In addition we should test that JDK 7 will transition from that synthesised
fontconfig, to the hand-tuned one, if the fonts are installed. I think it will
but its worth making sure. JDK 7 should then be in good shape.

This can't help 6u18, as shipped on Solaris Next, or 6u19, but we can try to do
something simple for 6u20.

So the best I have here is to maintain both files, and decide which to use
by keying on the presence of one or more (not too many) of the high quality fonts.
                                     
2010-04-05
EVALUATION

Could the bug submitter please provide the PSARC references for all the incompatible changes?
                                     
2010-04-05



Hardware and Software, Engineered to Work Together