Bug 2182696

Summary: msgfmt --java2 option doesn't work with java-17-openjdk
Product: Red Hat Enterprise Linux 9 Reporter: Nikos Moumoulidis <nmoumoul>
Component: gettextAssignee: Jens Petersen <petersen>
Status: CLOSED ERRATA QA Contact: Sanket Saikia <ssaikia>
Severity: high Docs Contact:
Priority: high    
Version: 9.1CC: bbarve, eng-i18n-bugs, jjanco, loganjerry, mtasaka, nphilipp, petersen, praiskup
Target Milestone: rcKeywords: Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: gettext-0.21-8.el9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 2062407 Environment:
Last Closed: 2023-11-07 08:53:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2062407    
Bug Blocks:    
Deadline: 2023-04-17   

Description Nikos Moumoulidis 2023-03-29 12:00:00 UTC
I am cloning this bug because we recently moved our project (Candlepin) to Java17 and we are stuck because we cannot compile our translation classes any more. Can you please include this fix in RHEL9?

+++ This bug was initially created as a clone of Bug #2062407 +++

Description of problem:
I noticed while building jmol that every invocation of msgfmt failed, e.g.:

update-application-catalog-lang:
     [echo] msgfmt Updating messages_ar.class file for Jmol ...
     [exec] msgfmt: Java compiler not found, try installing gcj or set $JAVAC
     [exec] msgfmt: compilation of Java class failed, please try --verbose or set $JAVAC
     [exec] 65 translated messages, 3 fuzzy translations, 380 untranslated messages.
     [exec] Result: 1

Setting JAVAC does *not* help.  I used strace to see how javac is invoked and found the problem: msgfmt passes -target 1.6, and sometimes -source 1.6, to javac.  Now that OpenJDK 17 is the default in Fedora, those arguments are no longer valid.  I don't remember if the minimum allowed is 1.7 or 1.8, but it is one of the two.  Since Fedora doesn't ship a JDK lower than 1.8, then 1.8 might as well be used.

Version-Release number of selected component (if applicable):
gettext-0.21-11.fc37.0.20220228

How reproducible:
Always

Steps to Reproduce:
1. fedpkg clone jmol
2. cd jmol
3. fedpkg srpm
4. mock -r fedora-rawhide-x86_64 --rebuild jmol-14.32.22-1.fc37.src.rpm

Actual results:
The msgfmt invocations all fail.

Expected results:
The msgfmt invocations should succeed.

Additional info:

--- Additional comment from Mamoru TASAKA on 2022-03-20 14:16:57 UTC ---

So the simple reproducer for this is:

$ mock --verbose -r fedora-rawhide-x86_64 --uniqueext gettext-test --init
$ mock --verbose -r fedora-rawhide-x86_64 --uniqueext gettext-test --install java-devel gettext
$ mock --verbose -r fedora-rawhide-x86_64 --uniqueext gettext-test --copyin ./ar.po /builddir/build/BUILD
$ mock --verbose -r fedora-rawhide-x86_64 --uniqueext gettext-test --chroot -- msgfmt  --statistics --java2 -l ar -d /builddir/build/BUILD/TMP -r org.jmol.translation.Jmol.ar.Messages /builddir/build/BUILD/ar.po

Then:
msgfmt: Java compiler not found, try installing gcj or set $JAVAC
msgfmt: compilation of Java class failed, please try --verbose or set $JAVAC
65 translated messages, 3 fuzzy translations, 380 untranslated messages.
DEBUG: Child return code was: 1

--- Additional comment from Mamoru TASAKA on 2022-03-20 14:25:47 UTC ---

So this is actually msgfmt calls javac with "-source 1.5 -target 1.6" explicitly:
 
  see gettext-tools/src/write-java.c "compile_java_class" call in "msgdomain_write_java" and related functions in gettext-tools/gnulib-lib/javacomp.c .

The attached patch is a draft for fixing this issue. Note that get_goodcode_snippet() and get_failcode_snippet() may need more adjustment: I guess get_goodcode_snippet() needs the code which compiles with JDK17 but fails with JDK11, however I don't know such code in detail.

--- Additional comment from Mamoru TASAKA on 2022-03-30 11:50:50 UTC ---

Are there any updates here? I think all needed information is provided.

--- Additional comment from Jens Petersen on 2022-03-31 03:27:32 UTC ---

Thank you very much, Tasaka-san!

Sorry, Sundeep has been away on holiday for two weeks.

I have added your patch to the rawhide branch.

We have one more problem: currently gettext-0.21 FTBFS on F36+.
So we have a git snapshot currently in Rawhide,
but maybe we can use that for F36 now to address this.

--- Additional comment from Jens Petersen on 2022-03-31 03:28:20 UTC ---

Can you try testing gettext-0.21-13.fc37.0.20220203 to see if it works for you?

--- Additional comment from Mamoru TASAKA on 2022-03-31 07:16:05 UTC ---

Yes, gettext-0.21-13.fc37.0.20220203 looks working. Thank you.

Comment 1 Jens Petersen 2023-03-30 02:43:09 UTC
I think this would require rebasing gettext to 0.21.1

Comment 3 Jens Petersen 2023-03-30 05:52:52 UTC
Actually thinking more we probably don't have to rebase just for this:
the patch should work/build in RHEL 9.

Comment 15 Jens Petersen 2023-05-04 09:48:10 UTC
I guess only remaining concern is if this could break any other packages/uses of old Java?

Comment 16 Jens Petersen 2023-05-04 10:11:55 UTC
(In reply to Jens Petersen from comment #15)
> I guess only remaining concern is if this could break any other
> packages/uses of old Java?

Actually I think the patch is supposed to handle both Java 11 and 17,
so it should be okay though the patch is not upstream yet.

Comment 23 errata-xmlrpc 2023-11-07 08:53:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (gettext bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:6629