<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    I do see some case when default is being returned.<br>
    <span style="display: inline !important; float: none; background-color: rgb(238, 238, 238); font-family: Consolas; font-size: 13.33px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: pre; word-spacing: 0px;"></span><br>
    <pre style="background-color: rgb(255, 255, 255); font-family: "JetBrains Mono", monospace; font-size: 9.8pt;">subsetEncodingMap.put("alphabetic", "default");
</pre>
    <span style="display: inline !important; float: none; background-color: rgb(238, 238, 238); font-family: Consolas; font-size: 13.33px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: pre; word-spacing: 0px;">which then needs an alphabetic font as part of the core script sequence.</span><br>
    <span style="display: inline !important; float: none; background-color: rgb(238, 238, 238); font-family: Consolas; font-size: 13.33px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: pre; word-spacing: 0px;">
Now looking at
desc.isDefaultFont() && charset.equals("DEFAULT_CHARSET")

Perhaps that could change the answer in some cases you don't intend.

For these UTF 8 locales there is nothing in the fontconfig that identifies
the right font.
The "ja" in UTF-8.ja is not connected to "japanese" in the fontconfig file.
Something like that may be the right fix but it would be a bigger change.

I am not sure how much it matters either.
There just needs to be a font. In the win9x days and when AWT was an "A" lib
not using unicode maybe.

Or maybe there's still some benefit to the right font for the language still being set
as the text component font but it is not happening anyway in this case and your
fix won't solve that. All roads lead to the latin/alphabetic font here.

My thinking right now is to just make </span>changes in
    getTextComponentFontName<span style="display: inline !important; float: none; background-color: rgb(238, 238, 238); font-family: Consolas; font-size: 13.33px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: pre; word-spacing: 0px;">
so it always returns something but only after the current code fails.
</span><br>
    So instead of your fix, just add this there :<br>
    <pre style="background-color:#ffffff;color:#080808;font-family:'JetBrains Mono',monospace;font-size:9.8pt;"><span style="color:#0033b3;">if </span>(fontName == <span style="color:#0033b3;">null</span>) {
    <span style="color:#0033b3;">if </span>(fontDescriptors.length > <span style="color:#1750eb;">0</span>) {
      <span style="color:#0033b3;">return </span>fontDescriptors[<span style="color:#1750eb;">0</span>].getNativeName();
    } <span style="color:#0033b3;">else </span>{
        fontName = <span style="color:#067d17;">"Arial,ANSI_CHARSET"</span>;
   }
}</pre>
    <span style="display: inline !important; float: none; background-color: rgb(238, 238, 238); font-family: Consolas; font-size: 13.33px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: pre; word-spacing: 0px;">Not very satisfactory but then we can remove the comment about maybe returning NULL.

-phil.

</span>
    <div class="moz-cite-prefix">On 7/27/2020 5:34 PM, Philip Race
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:a090bca1-5009-925f-9b99-3a139a982b27@oracle.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      This did start when we updated the fontconfiguration file but I
      think there was nothing wrong with the update<br>
      and I found it could happen with the previous  version if we just
      remove "devanagari" from this line in the OLD version.<br>
      <br>
sequence.allfonts.UTF-8.ja=alphabetic,japanese,devanagari,dingbats,symbol<br>
      <br>
      Removing that mimics what happened in the new version and is the
      first piece of the puzzle.<br>
      <br>
      I don't know why devanagari is even there. Possibly it is because
      that line was derived from this one :-<br>
sequence.allfonts.UTF-8.hi=alphabetic/1252,devanagari,dingbats,symbol<br>
      since hindi was the first UTF-8 locale that was supported and
      someone just edited it to create the JA entry.<br>
      <br>
      But it indicates to me that this is quite fragile and could easily
      have crashed a long time ago if Devanagari were<br>
      not there as one of the "core fonts" for UTF-8.ja<br>
      <br>
      Then in WFontConfiguration.initTables() a few things happen<br>
      <br>
      first this <br>
      <pre style="background-color:#ffffff;color:#080808;font-family:'JetBrains Mono',monospace;font-size:9.8pt;">subsetCharsetMap.put(<span style="color:#067d17;">"devanagari"</span>, <span style="color:#067d17;">"DEFAULT_CHARSET"</span>);
subsetCharsetMap.put(<span style="color:#067d17;">"japanese"</span>, <span style="color:#067d17;">"SHIFTJIS_CHARSET"</span>);

[for devanagari JDK specifies the Mangal font.]

the subsetEncodinging map has this for Japanese
 subsetEncodingMap.put("japanese", "windows-31j");

then this for UTF-8 for textInputCharset
} <span style="color:#0033b3;">else if </span>(<span style="color:#067d17;">"UTF-8"</span>.equals(defaultEncoding)) {
    textInputCharset = <span style="color:#067d17;">"DEFAULT_CHARSET"</span>;

whereas for the old ms932/windows-31j code page we would have had this

} <span style="color:#0033b3;">else if </span>(<span style="color:#067d17;">"windows-31j"</span>.equals(defaultEncoding)) {
    textInputCharset = <span style="color:#067d17;">"SHIFTJIS_CHARSET"</span>;

it then calls makeAWTFontName("MS Gothic", "japanese");
which looks like this :

WFontConfiguration.makeAWTFontName(String platformFontName, String characterSubsetName) {
    String windowsCharset = subsetCharsetMap.get(characterSubsetName);
    <span style="color:#0033b3;">if </span>(windowsCharset == <span style="color:#0033b3;">null</span>) {
        windowsCharset = <span style="color:#067d17;">"DEFAULT_CHARSET"</span>;
    }
    <span style="color:#0033b3;">return </span>platformFontName + <span style="color:#067d17;">"," </span>+ windowsCharset;
}

For "japanese", the result of 
subsetCharsetMap.get(characterSubsetName);

will always be <span style="color:#067d17;">"SHIFTJIS_CHARSET"</span>

So the method will return "MS Gothic,SHIFTJIS_CHARSET"
and this will get stored in the FontDescriptor

The other core entries for Japanese map to ANSI_CHARSET and SYMBOL_CHARSET.

When in the old fontconfig file  is called for "devanagari", it will return "Mangal,DEFAULT_CHARSET".

Without that, there is no DEFAULT_CHARSET mapped for any font in the core Japanese fonts.

This all becomes important when WFontConfiguration.getTextComponentFontName() is called from native code.

It has this line
String fontName = findFontWithCharset(fontDescriptors, textInputCharset);

from above we know that for UTF-8 :
    textInputCharset = <span style="color:#067d17;">"DEFAULT_CHARSET"</span>;

but as just noted above there are NO fonts tagged with that 

So the look up fails. The code retries : -
<span style="color:#0033b3;">if </span>(fontName == <span style="color:#0033b3;">null</span>) {
    fontName = findFontWithCharset(fontDescriptors, <span style="color:#067d17;">"DEFAULT_CHARSET"</span>);
}
 
but that was pointless since DEFAULT_CHARSET is what was already tried.

Now back to the windows-31j locale, there we had 

    textInputCharset = <span style="color:#067d17;">"SHIFTJIS_CHARSET"</span>;

so that finds the match "MS Gothic,SHIFTJIS_CHARSET".

 getTextComponentFontName() has the comment "<span style="color:#8c8c8c;font-style:italic;">May return null."

</span><span style="color:#8c8c8c;font-style:italic;"></span>which is true, but not very helpful to the native caller, which bails out, leaving the
native font structs uninitialised and ready to cause a crash.

That's the kind of analysis I was hoping for !

Now, the question is, is what you propose the right fix for this ?
But I am not sure it can even work.

<span style="display: inline !important; float: none; background-color: rgb(238, 238, 238); color: blue; font-family: Consolas; font-size: 13.33px; font-style: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space: pre; word-spacing: 0px;"> 931             descriptors[i] = new FontDescriptor(awtFontName, enc, exclusionRanges, encoding.equals("default"));

<font color="#000000">seems like it will never pass true in my testing. Then the whole fix falls apart.

Can you show some evidence ?

-phil</font></span></pre>
      <br>
      <br>
      <div class="moz-cite-prefix">On 7/27/2020 3:50 PM, Yasumasa
        Suenaga wrote:<br>
      </div>
      <blockquote type="cite"
        cite="mid:8a5a1d0f-7396-b086-b97d-1eafb251600a@oss.nttdata.com">Hi
        Phil, <br>
        <br>
        I confirmed WFontConfiguration::findFontWithCharset cannot find
        if -Dfile.encoding=UTF-8 is passed. <br>
        I guess one of the cause is the definitions in
        make/data/fontconfig/windows.fontconfig.properties, but also
        DEFAULT_CHARSET does not work at this point. <br>
        <br>
        If we do not pass -Dfile.encoding=UTF-8, `charset` in
        WFontConfiguration::findFontWithCharset is set to "windows-31j"
        and it can find out valid font when Windows is set to Japanese
        locale. <br>
        <br>
        I can share minidump for further investigation. What should I do
        / share? <br>
        <br>
        <br>
        Thanks, <br>
        <br>
        Yasumasa <br>
        <br>
        <br>
        On 2020/07/28 0:02, Philip Race wrote: <br>
        <blockquote type="cite">Hi, <br>
          <br>
          You're avoiding a crash but I don't yet know what *exactly*
          caused the crash. <br>
          Some Java code not handling DEFAULT_CHARSET is obviously not
          the exact cause. <br>
          This just starts it and something bad presumably happens later
          in native code. <br>
          <br>
          And I don't yet understand why (we think) this started
          happening when some <br>
          additional fonts were added to the file. <br>
          <br>
          Knowing exactly what is wrong will help decide if this is the
          right fix. <br>
          <br>
          -phil <br>
          <br>
          On 7/24/20, 5:59 AM, Yasumasa Suenaga wrote: <br>
          <blockquote type="cite">Hi Jay, <br>
            <br>
            I share you hs_err log of this issue. <br>
            `chcp` on my console shows "932" (MS932). It is Japanese
            locale. <br>
            <br>
            I can share you if you want to know. <br>
            <br>
            <br>
            Thanks, <br>
            <br>
            Yasumasa <br>
            <br>
            <br>
            On 2020/07/24 20:59, Jayathirth D V wrote: <br>
            <blockquote type="cite">Hi Yasumasa, <br>
              <br>
              I tried after changing the locale to Japanese but I don’t
              see the issue. <br>
              <br>
              Also tried to reproduce the issue by enabling/disabling
              setting "Beta:Use Unicode UTF-8 for worldwide language
              support" in my locale setting. <br>
              <br>
              @Others : Can somebody else try to reproduce this issue? <br>
              <br>
              Thanks, <br>
              Jay <br>
              <br>
              -----Original Message----- <br>
              From: Yasumasa Suenaga <a class="moz-txt-link-rfc2396E"
                href="mailto:suenaga@oss.nttdata.com"
                moz-do-not-send="true"><suenaga@oss.nttdata.com></a>
              <br>
              Sent: Thursday, July 23, 2020 5:41 PM <br>
              To: Jayathirth D v <a class="moz-txt-link-rfc2396E"
                href="mailto:jayathirth.d.v@oracle.com"
                moz-do-not-send="true"><jayathirth.d.v@oracle.com></a>
              <br>
              Cc: 2d-dev <a class="moz-txt-link-rfc2396E"
                href="mailto:2d-dev@openjdk.java.net"
                moz-do-not-send="true"><2d-dev@openjdk.java.net></a>;
              <a class="moz-txt-link-abbreviated"
                href="mailto:awt-dev@openjdk.java.net"
                moz-do-not-send="true">awt-dev@openjdk.java.net</a> <br>
              Subject: Re: [OpenJDK 2D-Dev] PING: RFR: 8249215:
              JFrame::setVisible crashed with -Dfile.encoding=UTF-8 <br>
              <br>
              Hi Jay, <br>
              <br>
              On 2020/07/23 19:09, Jayathirth D v wrote: <br>
              <blockquote type="cite">Hi, <br>
                <br>
                I tried reproducing the issue in my Windows 10 machine
                with UTF-8 encoding and test file mentioned in the bug,
                I don’t see any crash. <br>
                Am I missing something? <br>
              </blockquote>
              <br>
              OS locale may be affecting. <br>
              <br>
              My laptop has been set Japanese (CP932 / Windows-31J), so
              WFontConfiguration attempt to find Japanese font by
              default. <br>
              However WFontConfiguration cannot find out the font of
              "DEFAULT_CHARSET" when -Dfile.encoding=UTF-8 is passed. <br>
              <br>
              <br>
              Thanks, <br>
              <br>
              Yasumasa <br>
              <br>
              <br>
              <blockquote type="cite">Also I think this should be in
                awt-dev so adding the mailing list. <br>
                <br>
                Thanks, <br>
                Jay <br>
                <br>
                <blockquote type="cite">On 20-Jul-2020, at 12:59 PM,
                  Yasumasa Suenaga <a class="moz-txt-link-rfc2396E"
                    href="mailto:suenaga@oss.nttdata.com"
                    moz-do-not-send="true"><suenaga@oss.nttdata.com></a>
                  wrote: <br>
                  <br>
                  PING: could you review it? <br>
                  <br>
                  <blockquote type="cite">    JBS: <a
                      class="moz-txt-link-freetext"
                      href="https://bugs.openjdk.java.net/browse/JDK-8249215"
                      moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8249215</a>
                    <br>
                        webrev: <a class="moz-txt-link-freetext"
                      href="http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.00/"
                      moz-do-not-send="true">http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.00/</a>
                    <br>
                  </blockquote>
                  <br>
                  Yasumasa <br>
                  <br>
                  On 2020/07/11 17:39, Yasumasa Suenaga wrote: <br>
                  <blockquote type="cite">Hi all, <br>
                    Please review this change: <br>
                        JBS: <a class="moz-txt-link-freetext"
                      href="https://bugs.openjdk.java.net/browse/JDK-8249215"
                      moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8249215</a>
                    <br>
                        webrev: <a class="moz-txt-link-freetext"
                      href="http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.00/"
                      moz-do-not-send="true">http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.00/</a>
                    <br>
                    I tried to run Sample.java in JDK-8236161 with
                    -Dfile.encoding=UTF-8, but JVM crashed due to
                    internal error on fastdebug VM. I saw same call
                    stack with JDK-8236161 in hs_err log. <br>
                    I investigated it, then I found out current
                    implementation cannot handle default charset. <br>
                    If charset is set to UTF-8, it would be handled as
                    "DEFAULT_CHARSET" in WFontConfiguration::initTables.
                    However it does not affect native font name, so we
                    cannot find valid font. <br>
                    This change has passed all tests on submit repo
                    (mach5-one-ysuenaga-JDK-8249215-20200711-0655-12566039)
                    <br>
                    Thanks, <br>
                    Yasumasa <br>
                  </blockquote>
                </blockquote>
                <br>
              </blockquote>
            </blockquote>
          </blockquote>
        </blockquote>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>