@RequiredArgsConstructor generates parameters like "arg0", "arg1"

289 views
Skip to first unread message

Brian K

unread,
Jun 18, 2018, 4:52:11 PM6/18/18
to Project Lombok

Shows that code like:

@RequiredArgsConstructor(staticName = "of")
@AllArgsConstructor(access = AccessLevel.PROTECTED)
public class ConstructorExample<T> {
  private int x, y;
  @NonNull private T description;
  
  @NoArgsConstructor
  public static class NoArgsExample {
    @NonNull private String field;
  }
}


... would generate code like:

public static <T> ConstructorExample<T> of(T description) {
    return new ConstructorExample<T>(description);
  }

But, I am experiencing this kind of constructor generated:


public static <T> ConstructorExample<T> of(T arg0) {
    return new ConstructorExample<T>(description);
  }

Is there any way to get lombok to generate constructors with the parameter names?

Thanks!

-Brian


p.s.  My precise example is more basic than the docs: 

@RequiredArgsConstructor
public class Term {
   private Long courtCd;
   private Date beginDate;
}

I would expect to have a constructor with the parameters names like:
public Term (Long courtCd, Date beginDate) {...}

But I'm experiencing:
public Term(Long arg0, Date arg1) {...}

Reinier Zwitserloot

unread,
Jun 18, 2018, 4:55:32 PM6/18/18
to Project Lombok
Lombok didn't do that. There's no code in lombok to generate such names. If I had to take a guess... perhaps you compiled it without debug symbols, and then decompiled it. Most decompilers (such as for example most decompilers built into IDEs, as well as for example eclipse showing you autocomplete dialogs on classes which were compiled without debug symbols and for which neither javadoc nor sources are available) will name arguments like this.

To make javac compile with debug symbols: javac -g.

Brian K

unread,
Jun 20, 2018, 1:27:03 PM6/20/18
to project...@googlegroups.com
I'm actually inferring the compiled code from what NetBeans 8.2 is telling me are the parameters of the constructor when I try to use it.  This issue was identified but not filed in this issue:

I attached a screenshot of what NetBeans is showing when I get information on the constructor by holding ctrl while hovering my mouse cursor over the constructor invocation.  In normal use, I'd just press Ctrl-space and get the parameters and fill them in.  It looks like lombok has generated metadata on this method with parameter names, but it is somehow missing what the IDE's content assistance is looking for.  Hand-coded java methods do not have this issue - the parameter names are showing correctly.

Eclipse handle's the names correctly.  This is a maven project using lombok version 1.16.18.

Thanks,
Brian


image.png


--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mat Jaggard

unread,
Jun 21, 2018, 5:28:27 AM6/21/18
to project...@googlegroups.com
Are you *sure* hand-coded java methods don't have the same issue with exactly the same tool chain? Seems unlikely to me. The methods all have correctly named arguments for me when I compile with debug on.

Brian K

unread,
Jun 21, 2018, 3:27:23 PM6/21/18
to project...@googlegroups.com
image.png
yes.  I attached screen shot from invoking the constructor of hand-coded Bar class.

-Brian

Reinier Zwitserloot

unread,
Jul 1, 2018, 3:08:39 PM7/1/18
to Project Lombok
netBeans is able to display the correct signature (in the blueish tinten box above), but not in the list?

Sounds like a netbeans bug to me. It's always tricky to file those; lombok does things that aren't quite standardized API so usually you get 'stop using lombok' in response. We haven't looked at netbeans support in ages and given our limited time I don't think it'd be right to start looking at it again, unfortunately: NetBeans usage seems to falling off a cliff. If this was an easy fix we'd definitely look into it, but:

* NetBeans usage is down
* This feels like NetBeans' fault more than ours.
* My guesstimate is that this will be hard or impossible for lombok to fix. Possibly we can address things by generating javadoc, but there are all sorts of problems associated with trying to do that, it'd be many manhours and a large maintenance burden.

Add it up and we don't have the resources on the project right now to address this one :(
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombok+unsubscribe@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages