Статический импорт с одинаковыми именами статических переменных

Я делаю статический импорт членов классов Long и Integer:

import static java.lang.Integer.MAX_VALUE;
import static java.lang.Long.MAX_VALUE;

Теперь, если я попытаюсь использовать эту переменную MAX_VALUE и распечатать ее, я получу сообщение об ошибке:

import static java.lang.Integer.MAX_VALUE;
import static java.lang.Long.MAX_VALUE;

public class StaticImportDemo2 {
    public static void main(String[] args) {
        //Error :: The field MAX_VALUE is ambiguous 
        System.out.println("Print without static import Integer.MAX_VALUE "+MAX_VALUE);
    }
}

Это отлично. Чтобы удалить ошибку, мне придется удалить один статический импорт, чтобы устранить эту неоднозначность.

Основная проблема, которую я получаю, заключается в том, что если я использую подстановочный знак * с классом Integer статический импорт, класс компилируется без ошибок:

import static java.lang.System.out;
import static java.lang.Integer.*;
import static java.lang.Long.MAX_VALUE;

public class StaticImportDemo2 {
    public static void main(String[] args) {
        System.out.println("Print without static import Integer.MAX_VALUE " + MAX_VALUE);
    }
}

Двусмысленность все еще должна существовать. Почему это компилируется без проблем?

поэтому явно импортированные значения имеют приоритет

Scary Wombat 29.05.2018 03:51

Это то, что вы сделали из приведенного выше кода, но вопрос в том, почему это происходит?

Nishant_Singh 29.05.2018 03:55

Написано здесь плюс еще где-то стоит JLS

Scary Wombat 29.05.2018 04:02

Также написано Рекомендуется не использовать статический импорт вообще или только в очень редких случаях. - это обычное сообщение

Scary Wombat 29.05.2018 04:03
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
8
4
201
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Why does this compile with no issues?

Потому что Спецификация языка Java говорит, что это так. См. Главы 6 и 7, особенно из 6.4.1:

A type-import-on-demand declaration never causes any other declaration to be shadowed.

A static-import-on-demand declaration never causes any other declaration to be shadowed.

И это, вероятно, потому, что очень удобно иметь возможность импортировать целые пакеты с использованием подстановочных знаков, но иногда вам придется разрешать конфликты. Было бы отстойно (особенно в дни, предшествующие IDE), если бы единственной альтернативой был явный импорт каждого элемента. Таким образом, конкретный импорт (без подстановочных знаков) имел приоритет. Таким образом, вы просто указываете, что имеете в виду для неоднозначных элементов, которые хотите использовать.

Другие вопросы по теме