[Kotlin metadata] IntelliJ is very picky about extra modifiers [158400283]

Fixed

Bug

Status Update

No update yet.

Description

mk...@google.com

created issue #1

Jun 7, 2020 06:15PM

Turns out IntelliJ is very picky about package name or/and extra modifiers in the metadata, resulting in very poor developer experience. Basically, the error is that we would produce:

    kotlin.Metadata(
      mv=[1,1,15]
      bv=[1,0,3]
      k=1
      d1=["\u0000\f\n\u0002\u0018\u0002\n\u0002\u0010\u0000\n\u0002\b\u0003\b\u0016\u0018\u00002\u00020\u0001B\u0007¢\u0006\u0004\b\u0002\u0010\u0003¨\u0006\u0004"]
      d2=["Lcom/example/mylibrary/BaseCommand;","","<init>","()V","mylibrary_debug"],
      pn="",
      xs="",
      xi=0
    )

where the kotlinc generated one would be:

    kotlin.Metadata(
      mv=[1,1,15]
      bv=[1,0,3]
      k=1
      d1=["\u0000\f\n\u0002\u0018\u0002\n\u0002\u0010\u0000\n\u0002\b\u0003\b\u0016\u0018\u00002\u00020\u0001B\u0007¢\u0006\u0004\b\u0002\u0010\u0003¨\u0006\u0004"]
      d2=["Lcom/example/mylibrary/BaseCommand;","","<init>","()V","mylibrary_debug"]
    )

If the data is not present, the kotlin.Metadata will print default values, where we then end up emitting those:

    /**
     * An extra string field for the metadata.
     *
     * @see Metadata.extraString
     */
    val extraString: String = extraString ?: ""

    /**
     * Fully qualified name of the Kotlin package of the corresponding class, in case [JvmPackageName] was used.
     *
     * @see Metadata.packageName
     */
    val packageName: String = packageName ?: ""

    /**
     * An extra int field for the metadata.
     *
     * @see Metadata.extraInt
     */
    val extraInt: Int = extraInt ?: 0

That also means we cannot distinguish between a null value or a default value. We should file an issue on jetbrains to figure out if this is intended behavior.

Comments

mk...@google.com <mk...@google.com> #2Jun 8, 2020 07:25AM

Hi,

Thank you for taking the time to improve libphonenumber!

We are looking into this and will respond as soon as possible.

mk...@google.com <mk...@google.com> #3Jun 8, 2020 07:27AM

Hi,

Thanks much for raising this issue. This is one of our known issue, which is not documented. Having phone numbers of this long are very rare. libphonenumber cannot do anything better here.

Reasons:

JavaScript Number type has limitation of 2^53 (9007199254740992) as the max literal it can hold. When provided more than that like "90018408059449376"(17 digit), JS starts rounding the value. Unfortunately this is within the range of possible phone number length i.e 17 digit.
Both the alternatives leads to backward-incompatible changes as the type of the field '''national_number''' has to be changed; thus leading to client-side compile issue . Eg: setNationalNumber(1234) / conversions to payloads like JSON.

Marking the field as [jstype = JS_STRING]
Or using new JS data type BigInt.

We will update FAQ at GitHub stating some of these points. Maybe you can compare with Number.MAX_VALUE and avoid such cases. Or post request to a Java/CPP/PY libphonenumber clients, as these langs have much more matured data type systems.

mk...@google.com <mk...@google.com> #4Jun 8, 2020 10:33PM

Added to client FAQ as known issue. https://github.com/google/libphonenumber/pull/2674

ap...@google.com <ap...@google.com> #5Jun 9, 2020 09:17AM

+923146233552

wk...@google.com <wk...@google.com> #6Jun 10, 2020 11:23AM

Hey, yesteday I said everything is working with that fix, but today I opened the same project in Android Studio 4.0 (I was trying with 4.1 previously) and it seems like there are some differences, as on 4.0 autocomplete still doesn't work :(

mk...@google.com <mk...@google.com> #7Jun 10, 2020 12:55PM

Can you share the updated project, then I will take a look.

wk...@google.com <wk...@google.com> #8Jun 16, 2020 09:50AM

huh, I must have had Studio in some weird state, but I did try to clean everything multiple times. Today I updated R8, recompiled everything again, and everything shows up in autocomplete in the same AS4.0 version. Might have been something wrong on my end

mk...@google.com <mk...@google.com> #9Jun 16, 2020 10:41AM

Marked as fixed.

Thank you for trying out again Wojtek. Do not hesitate to reach out if the problem resurfaces.