This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 237248 - Refactoring inserts code in incorrect places
Summary: Refactoring inserts code in incorrect places
Status: RESOLVED DUPLICATE of bug 243751
Alias: None
Product: java
Classification: Unclassified
Component: Refactoring (show other bugs)
Version: 8.0
Hardware: PC Windows 7
: P3 normal (vote)
Assignee: Ralph Ruijs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-17 11:33 UTC by tnleeuw
Modified: 2015-03-09 10:22 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tnleeuw 2013-10-17 11:33:15 UTC
NetBeans Dev 201310170001

I tried refactoring a Java interface method, with one implementation, to add a method parameter.

After refactoring the interface method was correctly updated.

The implementation however looked like this after the refactoring:

----------------
    @Autowired
    private FundSharingRepository f     * @param contributionType the value of contributionType
undSharingRepository;

    /**
     * {@inheritDoc}
     */
   ContributionType contributionType @Transactional(readOnly = true)
    public SignOffCompletenessReportBuilder getSignOffCompletenessReportBuilder() {
------------------

The original code was:

------------------
    @Autowired
    private FundSharingRepository fundSharingRepository;

    /**
     * {@inheritDoc}
     */
    @Transactional(readOnly = true)
    public SignOffCompletenessReportBuilder getSignOffCompletenessReportBuilder() {
------------------

I had the option enabled to also update JavaDoc, and there was JavaDoc on the interface method and on the implementation.

The original method had no method parameters.

Just before I had done a similar refactoring on another method, however that method:
1. Didn't have JavaDoc on the implementation
2. Did already have another method parameter before the refactoring.

I don't know if either of these differences are the reason why the first refactoring was OK and the second just garbled the code but it's all I can think of at the moment.
Comment 1 tnleeuw 2013-10-17 11:45:20 UTC
NB: In both refactorings, the successful and the unsuccessful one, the parameter added was of a class not yet imported, so in both cases code shifted downward because of the added import statement.

In the case where refactoring was successful there were no class instance variables in the imlpementation class, in the case which broke, there were class instance variable declarations right above the method to be changed.

I don't know if any of this will have a relevance on the defect but I thought it might be helpful for the investigation.
Comment 2 Jiri Prox 2013-10-17 13:38:31 UTC
I cannot reproduce it, can you please provide the whole project? (at least the relevant parts)
Comment 3 tnleeuw 2013-10-17 13:49:02 UTC
I will try to add a project that can be used to reproduce this.

I've had this happening a few times, seemingly randomly in various builds over the last months and now finally decided to log an issue for it so it might be hard to reproduce with a fixed set of steps but it seems something persistent.
Comment 4 Jiri Prox 2013-10-22 12:27:22 UTC
This seems related to issue 237102
Comment 5 tnleeuw 2013-10-22 12:30:43 UTC
I agree with assessment of Jiri Prox and have indeed also occasionally seen the behaviour which was described in issue 237102 when renaming classes.

Not yet been able to find a guaranteed reproduction path for either problem in refactoring.
Comment 6 Ralph Ruijs 2015-03-09 10:22:35 UTC

*** This bug has been marked as a duplicate of bug 243751 ***