Qute message bundle using enum uppercase with words separated by underscores

[ercalamar]

Describe the bug

This works:

public enum Exceptions {
    ConditionalCheckFailed,
    VersionMismatch;
}

@MessageBundle("LocalizedMessages")
public interface LocalizedMessages {
    @Message String user_title(Exceptions e);
    @Message String user_message(Exceptions e);
}

LocalizedMessages.properties

user_title_ConditionalCheckFailed=Hola
user_message_ConditionalCheckFailed=Hola
user_title_VersionMismatch=Hola
user_message_VersionMismatch=Hola

This does not:

public enum Exceptions {
    CONDITIONAL_CHECK_FAILED,
    VERSION_MISMATCH;
}

@MessageBundle("LocalizedMessages")
public interface LocalizedMessages {
    @Message String user_title(Exceptions e);
    @Message String user_message(Exceptions e);
}

LocalizedMessages.properties

user_title_CONDITIONAL_CHECK_FAILED=Hola
user_message_CONDITIONAL_CHECK_FAILED=Hola
user_title_VERSION_MISMATCH=Hola
user_message_VERSION_MISMATCH=Hola

Expected behavior

Get messages

Actual behavior

Does not build:

Caused by: io.quarkus.qute.deployment.MessageBundleException: Message bundle method user_title_CONDITIONAL_CHECK_FAILED() not found on: xxxxxxxx.LocalizedMessages
- file: xxxxxxxx\LocalizedMessages.properties
- line 0
at io.quarkus.qute.deployment.MessageBundleProcessor.parseKeyToTemplateFromLocalizedFile(MessageBundleProcessor.java:848)
at io.quarkus.qute.deployment.MessageBundleProcessor.getLocalizedFileKeyToTemplate(MessageBundleProcessor.java:792)
at io.quarkus.qute.deployment.MessageBundleProcessor.generateImplementations(MessageBundleProcessor.java:737)
at io.quarkus.qute.deployment.MessageBundleProcessor.processBundles(MessageBundleProcessor.java:275)
at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:733)
at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:856)
at io.quarkus.builder.BuildContext.run(BuildContext.java:256)
at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
at org.jboss.threads.EnhancedQueueExecutor$Task.doRunWith(EnhancedQueueExecutor.java:2675)
at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2654)
at org.jboss.threads.EnhancedQueueExecutor.runThreadBody(EnhancedQueueExecutor.java:1627)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1594)
at java.base/java.lang.Thread.run(Thread.java:1570)
at org.jboss.threads.JBossThread.run(JBossThread.java:499)

How to Reproduce?

No response

Output of uname -a or ver

Microsoft Windows [Versión 10.0.22631.4460]

Output of java -version

openjdk 21 2023-09-19 OpenJDK Runtime Environment GraalVM CE 21+35.1 (build 21+35-jvmci-23.1-b15) OpenJDK 64-Bit Server VM GraalVM CE 21+35.1 (build 21+35-jvmci-23.1-b15, mixed mode, sharing)

Quarkus version or git rev

3.17.0

Build tool (ie. output of mvnw --version or gradlew --version)

gradle-8.11.1

Additional information

No response

[quarkus-bot]

/cc @mkouba (qute)

[mkouba]

Hi @ercalamar and thanks for the report. You're right - Qute incorrectly detects an enum constant message key if a enum constant contains an underscore. We should have used a different separator for method names and enum constants 😦 .

So far the only fix I can think of is to come with a different separator for cases where an enum constant contains _.

[ercalamar]

Hi @mkouba, sky is the limit:

user_title:CONDITIONAL_CHECK_FAILED=Hola
user_title::CONDITIONAL_CHECK_FAILED=Hola
user_title-CONDITIONAL_CHECK_FAILED=Hola
user_title->CONDITIONAL_CHECK_FAILED=Hola
user_title->(CONDITIONAL_CHECK_FAILED)=Hola
user_title(CONDITIONAL_CHECK_FAILED)=Hola
...

The thing is that this pattern is very common in enums. If fixing the issue is out of scope it should at least be warned in the documentation.

[mkouba]

The thing is that this pattern is very common in enums.

I completely agree.

If fixing the issue is out of scope it should at least be warned in the documentation.

This needs to be fixed!

[mkouba]

Hi @mkouba, sky is the limit:

user_title:CONDITIONAL_CHECK_FAILED=Hola
user_title::CONDITIONAL_CHECK_FAILED=Hola
user_title-CONDITIONAL_CHECK_FAILED=Hola
user_title->CONDITIONAL_CHECK_FAILED=Hola
user_title->(CONDITIONAL_CHECK_FAILED)=Hola
user_title(CONDITIONAL_CHECK_FAILED)=Hola
...

Hm, so the problem is that we currently use the key as a part of the name of a generated method. In other words, it should be a valid Java identifier. Otherwise, we would have to reimplement more stuff (not sure how much actually). So maybe just use the $; i.e. something like user_title$CONDITIONAL_CHECK_FAILED=Hola. It's not 100% unambiguous - you can still use $ in a method name but it's not very common.

[mkouba]

So I think that we should take a different path. Different in the sense that we don't want to break existing apps.

The separator could be derived from the set of constant enums:

• By default, the message key consists of the method name followed by the _ separator and the constant name (current behavior).
• If any constant name of a particular enum contains the _ or the $ character then the _$ separator must be used for all message keys for this enum instead. For example, methodName_$CONSTANT_1=Value 1 or methodName_$CONSTANT$1=Value 1.

The downside of this approach is that you can't stick with a single separator for everything, i.e. it always depends on the enum constants 🤷. OTOH the backward compatibility has the priority.