New `RuleId` value class mangled, preventing use in Java

[magneticflux-]

Expected Behavior

I should be able to reference, use, and construct RuleIds from Java code.

Observed Behavior

I cannot access the third property of LintError (a RuleId). The generated bytecode shows that the name is mangled, per the docs:

  // access flags 0x11
  public final getRuleId-6XN97os()Ljava/lang/String;
  @Lorg/jetbrains/annotations/NotNull;() // invisible
   L0
    LINENUMBER 17 L0
    ALOAD 0
    GETFIELD com/pinterest/ktlint/rule/engine/api/LintError.ruleId : Ljava/lang/String;
    ARETURN
   L1
    LOCALVARIABLE this Lcom/pinterest/ktlint/rule/engine/api/LintError; L0 L1 0
    MAXSTACK = 1
    MAXLOCALS = 1

This can be fixed by explicitly specifying the name with @JvmName.

Your Environment

• Version of ktlint used: 0.49.1

[magneticflux-]

A similar issue occurs for the extension properties on RuleSetId and RuleId. createRuleSetExecutionEditorConfigProperty becomes createRuleSetExecutionEditorConfigProperty-fqiwTpU and createRuleExecutionEditorConfigProperty becomes createRuleExecutionEditorConfigProperty-U7AdEiY.

[paul-dingemans]

I didn't know about interoperability issues with value classes. After some googling around, I get the feeling that those issues are known for a long time and are not very likely to be fixed:

• https://youtrack.jetbrains.com/issue/KT-50473/Unable-to-instantiate-class-with-value-class-parameter-from-Java
• https://youtrack.jetbrains.com/issue/KTIJ-19428/Inline-Value-classes-Java-interop-Unable-to-access-fields-methods-constructor-of-Value-class-from-Java
• https://youtrack.jetbrains.com/issue/KT-23338/Inline-classes

[paul-dingemans]

Can you validate with the latest snapshot build whether the problem is solved? Technically, this is a breaking change and I will have to release it as 0.50.x.

[shashachu]

@magneticflux- can you elaborate what your use case is for accessing these values from Java?

[shashachu]

Nevermind; heard from Paul that it's for Spotless

[magneticflux-]

@paul-dingemans Yep, everything seems fine here, thanks for the quick turnaround! I tested in Spotless using this patch: diffplug/spotless#1706 (comment), which I'll use as a base for the full 0.50.0 update.

My Spotless PR already supports 0.49.0 using a reflection workaround, so we're not desperate for a 0.50.0 release.

[paul-dingemans]

Tnx for confirming that the problem is solved. Also, I am grateful that you mentioned explicitly that for now you have worked around it with reflection. Releasing 0.50.0 without improvements for 'normal' (e.g. non API consumers) does not feel ok.