Announcement Announcement Module
Collapse
No announcement yet.
Roo incorrectly regenerates pushed-in methods with the same type-erased signature Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Roo incorrectly regenerates pushed-in methods with the same type-erased signature

    Dear List,

    I'm using Roo 1.2.3.

    Situation: I have an interface Response and a class ResponseImpl that implements interface Response; additionally, I have a class QuestionImpl with a field:

    @OneToMany(mappedBy = "question")
    private Set<ResponseImpl> responses = new HashSet<ResponseImpl>();

    Hence Roo correctly generates the following method in aspect QuestionImpl_Roo_JavaBean:
    public void QuestionImpl.setResponses(Set<ResponseImpl> responses) {
    this.responses = responses;
    }

    I have pushed-in this setResponses method. Everyting works fine, nothing to complain!

    Things go wrong when I change the signature of method setResponses into
    public void setResponses(Set<Response> responses) {...}

    The problem: roo will regenerate the setResponses in QuestionImpl_Roo_JavaBean, but this method has the same type-erased signature with the pushed-in method and thus yielding a:
    java.lang.ClassFormatError: Duplicate method name&signature in class file com/mycompany/product/model/QuestionImpl

    Any ideas how to prevent Roo from regenerating this pushed-in method?

    Thanx in advance!!
    Last edited by HJLebbink; Apr 29th, 2013, 04:45 AM. Reason: typo

  • #2
    Originally posted by HJLebbink View Post
    Any ideas how to prevent Roo from regenerating this pushed-in method?
    In your pushed method, can you change ResponseI with ResponseImpl ?

    Regards !

    Comment


    • #3
      Hi Mmartinez,

      Thanks for answering.

      Originally posted by mmartinez View Post
      In your pushed method, can you change Response with ResponseImpl ?
      Sadly not. Class QuestionImpl has to implement the method setResponses(Set<Response> responses) due to other interfaces, and having the method setResponses(Set<ResponseImpl> responses) in the same class is not allowed because of the aforementioned name clash after erasure.

      This roo behaviour (of regenerating methods that are different before yet equal after erasure) feels like unintended...
      Last edited by HJLebbink; Apr 29th, 2013, 04:56 AM. Reason: typo

      Comment

      Working...
      X