Bug 112349 - [extract local] Extract a single null literal
Summary: [extract local] Extract a single null literal
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 enhancement with 2 votes (vote)
Target Milestone: ---   Edit
Assignee: Markus Keller CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 434346 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-10-12 11:31 EDT by David Saff CLA
Modified: 2019-01-10 14:33 EST (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Saff CLA 2005-10-12 11:31:52 EDT 
In M2.

In the statement:

URL url = new URL(null);

Trying to extract a local variable from the "null" expression tells me "Cannot
extract a single null literal".  However, there's no ambiguity in this case: the
only thing I can want is:

String local = null;
URL url = new URL(local);
Comment 1 Markus Keller CLA 2005-10-14 03:52:53 EDT 
We currently determine the type of the new local variable by inspecting the
extracted expression. This does not work for null, so we would have to go up in
the AST and analyze the parent to see what the upper bound of expected types is
in that context. That can be somewhat tricky in the general case, e.g.:

class Break {
    void use() {
        takeT(null, 42);
    }
    
    <T extends Number & Comparable<T>> void takeT(T t, T t2) { }
}
Comment 2 David Saff CLA 2005-10-14 08:55:39 EDT 
Absolutely the general case may be quite difficult.  I'd be happy if simple
cases like the one in the original bug description were handled correctly.
Comment 3 Marko Schulz CLA 2006-02-13 05:00:50 EST 
For me it would be sufficient to make the new parameter/variable of type Object. In most cases this would leave me with a type error that is easily handled using the "Change Typ of XXX to XXX" quick fix. Bonus points for integrating the second step into the refactoring.

Of course without the correct type this would move the extract operation out of the realm of refactorings but for me it would just work (TM) most of the times, which is more important for me.
Comment 4 Tobias Widmer CLA 2006-04-09 19:09:53 EDT 
Moving to correct owner
Comment 5 Dani Megert CLA 2014-05-08 04:15:10 EDT 
*** Bug 434346 has been marked as a duplicate of this bug. ***
Comment 6 Timo Kinnunen CLA 2014-05-11 07:48:29 EDT 
The first part, creating 
		Object x = null;
		Stream<Path> s = Files.walk(x);
from 
		Stream<Path> s = Files.walk(null);

can be done simply by removing the check for NullLiteral in ExtractTempRefactoring.java on line 437:
//			if (selectedExpression instanceof NullLiteral) {
//				return RefactoringStatus.createFatalErrorStatus(RefactoringCoreMessages.ExtractTempRefactoring_null_literals);
//			} else
Comment 7 Timo Kinnunen CLA 2014-05-11 08:08:30 EDT 
The variable created in this manner cannot be inlined again. Just as I suspected Inline Local Variable refactoring contains a similar check and is just as easily fixed. See bug 93850 for details.

This bug has also annoyed me for a long time. Time to fix: 9 years and 10 minutes.
Comment 8 Timo Kinnunen CLA 2014-05-13 03:55:01 EDT 
Link to commit which fixes this bug: https://github.com/Overruler/eclipse.jdt.ui/commit/eeb824de688bf288ed66fcf922ce2c8c38b91c99
Comment 9 Timo Kinnunen CLA 2014-10-12 03:59:29 EDT 
The fix to this bug is included in Evening-IDE, which is available here: http://overruler.github.io/Evening-IDE/