Skip to content

Missing ParameterizedType for Option in LTS 3.3 #20263

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jchyb opened this issue Apr 25, 2024 · 0 comments
Open

Missing ParameterizedType for Option in LTS 3.3 #20263

jchyb opened this issue Apr 25, 2024 · 0 comments
Labels
area:backend area:erasure itype:bug stat:fixed in next The issue was fixed in Next and only still applies to LTS.

Comments

@jchyb
Copy link
Contributor

jchyb commented Apr 25, 2024

Compiler version

3.3.0, 3.3.1, 3.3.3 (works correctly in 3.4.0 and 3.4.1)

Minimized code

class ClassWithOption {
  val a: Option[Int] = None
}

object Test {
  def main(args: Array[String]) =
    classOf[ClassWithOption].getDeclaredFields.foreach { field =>
      println(field.toString + " parametrised " + field.getGenericType.isInstanceOf[java.lang.reflect.ParameterizedType])
    }
}

Output

In LTS:

private final scala.Option ClassWithOption.a parametrised false

In 3.4.0 and 3.4.1:

private final scala.Option ClassWithOption.a parametrised true

When using the CFR decompiler on ClassWIthOption I get:
In LTS:

/*
 * Decompiled with CFR 0.152.
 * 
 * Could not load the following classes:
 *  scala.None$
 *  scala.Option
 */
import scala.None$;
import scala.Option;

public class ClassWithOption {
    private final Option a = None$.MODULE$;

    public Option<Object> a() {
        return this.a;
    }
}

In 3.4:

/*
 * Decompiled with CFR 0.152.
 * 
 * Could not load the following classes:
 *  scala.None$
 *  scala.Option
 */
import scala.None$;
import scala.Option;

public class ClassWithOption {
    private final Option<Object> a = None$.MODULE$;

    public Option<Object> a() {
        return this.a;
    }
}

Expectation

I expect the behavior in 3.4.
Some libraries may use java reflection features which depend on the erased type parameter being there. I suspect overeager type parameter erasure was not intentional, which is why it came back in 3.4.

@jchyb jchyb added itype:bug area:backend area:erasure stat:needs triage Every issue needs to have an "area" and "itype" label labels Apr 25, 2024
@Gedochao Gedochao added stat:fixed in next The issue was fixed in Next and only still applies to LTS. and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Apr 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:backend area:erasure itype:bug stat:fixed in next The issue was fixed in Next and only still applies to LTS.
Projects
None yet
Development

No branches or pull requests

2 participants