Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 575758

Summary: [refactoring] "Extract Superclass" fails for class with a method accessing a private final field
Product: [Eclipse Project] JDT Reporter: Holger Voormann <eclipse>
Component: UIAssignee: Jeff Johnston <jjohnstn>
Status: CLOSED WORKSFORME QA Contact:
Severity: normal    
Priority: P3 CC: jjohnstn
Version: 4.21   
Target Milestone: ---   
Hardware: PC   
OS: Windows 10   
Whiteboard: stalebug

Description Holger Voormann CLA 2021-09-02 05:29:09 EDT 
In 4.21 (tested with 4.21RC1a) the "Extract Superclass" refactoring was improved (see bug 573884), but it might fail and errors will be logged when in the "Extract Superclass" dialog in the "Specify actions for members:" section a method is selected that accesses a private final field.

Steps to reproduce:

1. In the following code in line 2 right-click "ExtractSuperclass" and choose "Refactor > Extract Superclass...":
	class ExtractSuperclassBug {}
	class ExtractSuperclass extends ExtractSuperclassBug {
		private final int b;
		public int getB() {
			return b;
		}
		public ExtractSuperclass(int b) {
			this.b = b;
		}
	}

2. In the "Extract Superclass" dialog, enter a name for the superclass and in the "Specify actions for members:" section select both items or at least "getB()"

3. Hit two times "Finish" (after the first "Finish", "The visibility of field 'ExtractSuperclass.b' will be changed to package." will be shown as found problem)

=> Error dialog pops up with the following error message and 3 errors will be logged:

An exception has been caught while processing the refactoring 'Extract Superclass'.
Reason:

null argument:

Click 'Undo' to undo all successfully executed changes of the current refactoring.
Click 'Abort' to abort the current refactoring.
Comment 1 Jeff Johnston CLA 2021-09-02 14:17:30 EDT 
Hi Holger, this might be Windows-only or will be fixed in RC2.

I can't reproduce in my Linux Eclipse with latest plug-ins checked out.  I also tried the latest I-build from:

https://download.eclipse.org/eclipse/downloads/drops4/I20210901-1800/

When I run the given test case, if I choose both field and method, I get working code.  If I just choose the method, I get the warnings and then the refactoring occurs and the code is invalid as per the error message during the refactoring.  I don't see any exception logged.

Could you try the I-build to see if it is fixed and if not, could you check the Error log to see if there is an exception trace that can be included here?

Unfortunately, with the pandemic, I don't have access to a working Windows box as the one at the office has failed and no one is there to get it working again.
Comment 2 Holger Voormann CLA 2021-09-02 17:59:04 EDT 
(In reply to Jeff Johnston from comment #1)
Thanks for looking into it, Jeff.

I can reproduce it also with I20210901-1800.

As I just realized, this issue occurs if and only if the code is in the default package.
Comment 3 Eclipse Genie CLA 2023-08-24 07:46:14 EDT 
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 4 Jeff Johnston CLA 2023-08-28 14:14:42 EDT 
(In reply to Holger Voormann from comment #2)
> (In reply to Jeff Johnston from comment #1)
> Thanks for looking into it, Jeff.
> 
> I can reproduce it also with I20210901-1800.
> 
> As I just realized, this issue occurs if and only if the code is in the
> default package.

Hi Holger, relooking at this.  I am not seeing an error dialog when I do this from the default package.  If I don't move field b as well, an error marker is found in the new superclass, but no error dialog.  If I move b, everything works fine.  I think this can be closed.
Comment 5 Holger Voormann CLA 2023-08-28 15:27:39 EDT 
(In reply to Jeff Johnston from comment #4)
> (In reply to Holger Voormann from comment #2)
> > (In reply to Jeff Johnston from comment #1)
> > Thanks for looking into it, Jeff.
> > 
> > I can reproduce it also with I20210901-1800.
> > 
> > As I just realized, this issue occurs if and only if the code is in the
> > default package.
> 
> Hi Holger, relooking at this.  I am not seeing an error dialog when I do
> this from the default package.  If I don't move field b as well, an error
> marker is found in the new superclass, but no error dialog.  If I move b,
> everything works fine.  I think this can be closed.

Thanks for relooking at this!

In Eclipse 4.29RC1 I still get the error dialog sporadically, but more often gibberish if and only if all of the following conditions are met:
- Compiler Compliance level: 1.8
- Default package
- Superclass name: Foo (curiously it seems to work with "F")
- Select "getB()" only

The error dialog is only shown sometimes, but mostly the Java file becomes gibberish, e.g.:

class ExtractSuperclassBug {}
class ExtractSuperclass extends Foo {
	private final intblic ixtractSuperclass(int b) {
		this.b =super();
		 b;
	}
super();
		}
Comment 6 Jeff Johnston CLA 2023-08-30 16:45:20 EDT 
(In reply to Holger Voormann from comment #5)
> (In reply to Jeff Johnston from comment #4)
> > (In reply to Holger Voormann from comment #2)
> > > (In reply to Jeff Johnston from comment #1)
> > > Thanks for looking into it, Jeff.
> > > 
> > > I can reproduce it also with I20210901-1800.
> > > 
> > > As I just realized, this issue occurs if and only if the code is in the
> > > default package.
> > 
> > Hi Holger, relooking at this.  I am not seeing an error dialog when I do
> > this from the default package.  If I don't move field b as well, an error
> > marker is found in the new superclass, but no error dialog.  If I move b,
> > everything works fine.  I think this can be closed.
> 
> Thanks for relooking at this!
> 
> In Eclipse 4.29RC1 I still get the error dialog sporadically, but more often
> gibberish if and only if all of the following conditions are met:
> - Compiler Compliance level: 1.8
> - Default package
> - Superclass name: Foo (curiously it seems to work with "F")
> - Select "getB()" only
> 
> The error dialog is only shown sometimes, but mostly the Java file becomes
> gibberish, e.g.:
> 
> class ExtractSuperclassBug {}
> class ExtractSuperclass extends Foo {
> 	private final intblic ixtractSuperclass(int b) {
> 		this.b =super();
> 		 b;
> 	}
> super();
> 		}

Hi Holger,

Unfortunately, I'm unable to reproduce on Linux.  I was originally using a child Eclipse with 4.29 latest sources, but I also downloaded the 4.29 RC1 SDK for x86_64 Linux and created a project and specified it use 1.8.  I did the aforementioned tasks and it worked as expected (the final Foo class had an error as it couldn't access b).  Tried it a few times, same result.  No idea why it doesn't work for you other than it looks like a Windows-specific bug.  I don't have access to a Windows box to reproduce.
Comment 7 Holger Voormann CLA 2023-08-31 05:23:51 EDT 
> Hi Holger,
> 
> Unfortunately, I'm unable to reproduce on Linux.  I was originally using a
> child Eclipse with 4.29 latest sources, but I also downloaded the 4.29 RC1
> SDK for x86_64 Linux and created a project and specified it use 1.8.  I did
> the aforementioned tasks and it worked as expected (the final Foo class had
> an error as it couldn't access b).  Tried it a few times, same result.  No
> idea why it doesn't work for you other than it looks like a Windows-specific
> bug.  I don't have access to a Windows box to reproduce.
>

Strange. I tried it more than ten times with eclipse-SDK-4.29RC1-win32-x86_64 and with eclipse-java-2023-09-M3-win32-x86_64 (Build id: 20230825-1258), with the Temurin-17.0.6+10 and with the IBM Semeru Runtime Open Edition 17.0.5.0 JDK and either the error dialog popped up or gibberish was generated.

The gibberish is slightly different each time. So maybe it's a concurrency issue, but limiting the Windows process to a single CPU core didn't fix the problem either.

Whatever. I can only reproduce it in the default package, which is not a real use case. So feel free to close this issue. Thanks for your time.
Comment 8 Jeff Johnston CLA 2023-09-05 11:32:08 EDT 
Ok, will close.  Sorry I couldn't reproduce it.  If it crops up in non-default package usage, just open a new issue.