Skip to content

source action->override/implement methods does not get correct name of arguments. #967

Open

Description

@simahao
Environment
  • Operating System:windows 10
  • JDK version:1.8.0_101
  • Visual Studio Code version:1.35.1
  • Java extension version:0.46.0
Steps To Reproduce
  1. source action->override/implement Methods
  2. pick one method from list
Current Result

image

Expected Result

Name of arguments are correct,not arg0,arg1,arg2,arg3.
Base class method declare like below:
image

Additional Informations

Activity

  1. fbricon commented on Jul 4, 2019

    @fbricon
    Collaborator

    I can't reproduce that behavior. Can you please provide a sample project?

  2. rgrunber commented on Jan 18, 2024

    @rgrunber
    Member

    This is still an issue. I tried some simpler projects and couldn't get it to reproduce. But was able to with lemminx.

    override-implement-arg

    The declaration is actually public abstract T caseOther(Pattern p);

    Given the original example dealt with a class that was parametrized, I suspect that's the case that misbehaves.

  3. negativems commented on Jan 17, 2026

    @negativems

    Still an issue, the generated override methods always get as parameters "arg0", "arg1", etc

  4. robstryker commented on Oct 29, 2026

    @robstryker
    Contributor

    Very strange behavior here. I made a java interface MyInterface that extends List<String>

    Then I made a class that implements MyInterface and then added all missing methods.

    Some of the methods got their variable name, some got arg0 and arg1.

    Very easy to replicate.

  5. MeherSru commented on Oct 30, 2026

    @MeherSru
    Contributor

    With the bundled JRE (no src.zip), JDT tries to get the parameter names from the online Javadoc. That works for some methods but not others, so you get a mix. With Wi-Fi off, every method gets arg0.

    With a full JDK (has src.zip): all the names are correct.

    Since v1.57.0, when no JDK is configured, new projects use the bundled JRE instead of the JDK from JAVA_HOME. That’s why it’s easy to hit now.

    Would it make sense to go back to using the JAVA_HOME JDK by default? Happy to look into it.

  6. robstryker commented on Nov 2, 2026

    @robstryker
    Contributor

    @datho7561 This one is for you to decide. Is it better to go back to using a jdk? Or to simply instruct users that they need to configure a jdk?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions