"Import Type" quick-fix missing for types with diamond operator

[ptziegler]

Consider the following snippet:

package test2;

import java.util.ArrayList;
import java.util.List;

public class Main {
	public static void main(String[] args) {
		List<Border> borders = new ArrayList<>();
	}
}

This class produces a compilation error, because the javax.swing.border.Border import is missing. However, this option is missing in the context menu and the quickfix (tested with I20260428-1800). If I change the assignment to List<Border> borders = new ArrayList<Border>();, the type is suggested again.

For comparision, here is how it used to look like (tested with 20240905-0614)

[ptziegler]

The entry is shown up until the 4.34 but not the 4.35. However, it also appears with a JDT Core 4.34 and JDT UI 4.35. So this issue should be moved to https://github.com/eclipse-jdt/eclipse.jdt.core.

[iloveeclipse]

I guess javax.swing is in type filters preference.

[ptziegler]

I guess javax.swing is in type filters preference.

It is not. Otherwise it also wouldn't appear with List<Border> borders = new ArrayList<Border>();. I only picked the Swing Border, because I didn't want to clutter up the example and I've seen exactly the same issue with several other types.

I don't fully understand what this commit has changed exactly, but the editor behaves correctly up until 668fa97 and not anymore with 5f438d7.

[iloveeclipse]

I don't fully understand what this commit has changed exactly, but the editor behaves correctly up until 668fa97 and not anymore with 5f438d7.

Redirecting the question to @stephan-herrmann .

[jjohnstn]

Doing some debugging, I found that for the specified scenario, a guess at the type binding is returning the binding for java.lang.Object instead of null. This messes up the UI algorithm. I have created a patch for JDT UI which ignores a guess of Object and also fixed a relevance setting for when the imported type requires an added module requirement (which in my case was true).

[jjohnstn]

I checked in the UI patch for now. I can easily revert if the compiler ends up modified. The code that returns guessed type binding of Object for the Border type is ASTResolver.guessBindingForTypeReference():

    public static ITypeBinding guessBindingForTypeReference(ASTNode node) {
    	StructuralPropertyDescriptor locationInParent= node.getLocationInParent();
    	if (locationInParent == QualifiedName.QUALIFIER_PROPERTY) {
    		return null; // can't guess type for X.A
    	}
		if (locationInParent == SimpleType.NAME_PROPERTY ||
				locationInParent == NameQualifiedType.NAME_PROPERTY) {
    		node= node.getParent();
    	}
    	ITypeBinding binding= Bindings.normalizeTypeBinding(getPossibleTypeBinding(node));
    	if (binding != null) {
    		if (binding.isWildcardType()) {
    			return normalizeWildcardType(binding, true, node.getAST());
    		}
    	}
    	return binding;
    }

I did not verify if using the old compiler code returned null but I did notice that a reference to a class like Set did return null and like Border, the SimilarElementsRequestor.findSimilarElements() method returns a list including the desired class to import. The current logic in UnresolvedElementsBaseSubProcessor.addSimilarTypeProposals() with Object being returned and the class being in the similar elements array was not causing an import proposal to be created.

[stephan-herrmann]

Doing some debugging, I found that for the specified scenario, a guess at the type binding is returning the binding for java.lang.Object instead of null.

Without having debugged this case, I believe what you are seeing matches the intention behind #3726: make type inference more robust against missing types. I'm not sure were previously the null originated, as in the compiler type bindings should never be null, you'd rather see a problem binding of some kind.

I checked in the UI patch for now. I can easily revert if the compiler ends up modified.

Good, I don't have plans to change this aspect in the compiler.

So, can this issue be closed as fixed in UI?

[jjohnstn]

I checked in the UI patch for now. I can easily revert if the compiler ends up modified.

Good, I don't have plans to change this aspect in the compiler.

So, can this issue be closed as fixed in UI?

I'm fine with that. @ptziegler, do you want to verify it is fixed?

[ptziegler]

I've installed the latest i-build and at a quick glance, everything seems to be working as its supposed to. From my side, this issue can be closed. Many thanks! 😄