Java неоднозначного типа для метода?
РЕДАКТИРОВАТЬ: Это оказалось не проблема с кодом вообще, но с ошибкой в плагине Groovy Eclipse ( http://jira.codehaus.org/browse/GRECLIPSE-373)
Eclipse дает мне странное сообщение об ошибке о неоднозначных типах в Java-программе, и я действительно не понимаю, почему. У меня есть интерфейс, который принимает универсальный параметр, указывающий, какой тип данных он возвращает.
public interface InterfaceA<T> {
T getData();
}
Одна из реализаций выглядит так:
public class Impl<T extends AnotherClass> implements InterfaceA<Collection<T>> {
public Collection<T> getData() {
// get the data
}
}
Также есть контейнер для интерфейса А
public class Container<T extends InterfaceA>
{
private T a;
public Container(T a) {
this.a = a;
}
public T getA() {
return a;
}
}
Это приводит к ошибке "getData is ambiguous".
Container<Impl<AnotherClass>> c = new Container(new Impl<AnotherClass>());
Collection<AnotherClass> coll = c.getA().getData();
Я поставлен в тупик на этом.
6 ответов
Кажется, есть ошибка, вызывающая это из плагина Groovy. http://jira.codehaus.org/browse/GRECLIPSE-373. Это не проблема Java вообще. Спасибо за помощь и мои извинения.
Collection<T> getData()
определяется в Impl
должен быть обнародован. Если я делаю это, код компилируется для меня чисто.
Ваш отредактированный пример отлично работает для меня (JDK 1.5) за исключением того, что вы должны определить универсальный тип в конструкторе. Вот мой полный рабочий код:
public interface InterfaceA<T> {
T getData();
}
public static class Impl<T extends Date> implements InterfaceA<Collection<T>> {
public Collection<T> getData() {
return null;
}
}
public static class Container<T extends InterfaceA> {
private T a;
public Container(T a) {
this.a = a;
}
public T getA() {
return a;
}
}
public static void main(String[] args) {
Container<Impl<Date>> c = new Container<Impl<Date>>(new Impl<Date>());
Collection<Date> coll = c.getA().getData();
}
Как говорили другие авторы, я не вижу этой проблемы на Eclipse 3.5.0, работающем на JDK 1.6.0.14 (когда исправлялась уменьшенная видимость getData()
метод).
Я предлагаю сделать чистую сборку (Project/Clean в Eclipse). Также может помочь версия Eclipse и Java, которую вы используете.
- Флавиу Кипчиган
[Изменить, чтобы отразить обновленный вопрос]
Это даже не должно компилироваться, так как вы уменьшаете видимость метода из public в область действия пакета:
public class Impl<T extends AnotherClass> implements InterfaceA<Collection<T>> {
Collection<T> getData() {
// get the data
}
}
И это все еще компилируется для меня (Eclispe 3.4, OS X, 1.5), поэтому не знаю, в чем конкретно проблема:
пакет temp.tests;
import java.util.Collection;
public interface InterfaceA <T> {
T getData();
public static final class AnotherClass {}
public static final class Impl<T extends AnotherClass>
implements InterfaceA<Collection<T>>
{
public Collection<T> getData () {
return null;
}
}
public static class Container<T extends InterfaceA>
{
private T a;
public Container(T a) { this.a = a; }
public T getA() { return a; }
}
public static final class Test {
public static void main (String[] args) {
Container<Impl<AnotherClass>> c = new Container(new Impl<AnotherClass>());
Collection<AnotherClass> coll = c.getA().getData();
}
}
}
То, что у вас здесь есть, кажется законным. Возможно, Eclipse показывает ошибку, которой не должно быть.
Перейдите в Windows> "Настройки"> "Java"> "Компилятор"> "Ошибки / предупреждения". В разделе "Общие типы" убедитесь, что Eclipse не сообщает об ошибке ни для одной из перечисленных операций (если только вы этого не хотите). У меня все мое в этом разделе установлено на "Предупреждение". Затем я попытался бы обновить проект и перезапустить Eclipse.
Изменить: После того, как обновленное сообщение было сделано, я получил предупреждение (но не об ошибке) о том, как использовать:"Контейнер необработанный тип. Ссылки на универсальный тип Контейнер должны быть параметризованы:". Это можно исправить с помощью:
Container<Impl<Date>> c = new Container<Impl<Date>>(new Impl<Date>());
(В моем примере я использую java.util.Date вместо "AnotherClass").