Чому виклик статичного методу через екземпляр не є помилкою для компілятора Java?

Я впевнений, що всі ви знаєте поведінку, яку я маю на увазі - такий код, як:

Thread thread = new Thread();
int activeCount = thread.activeCount();

провокує попередження компілятора. Чому це не помилка?

РЕДАГУВАТИ:

Щоб бути зрозумілим: питання не має нічого спільного з Threads. Я усвідомлюю, що під час обговорення часто наводяться приклади ниток, оскільки вони дійсно можуть зіпсувати щось із ними. Але насправді проблема в тому, що таке використання - це завжди нісенітниця, і ти не можеш (грамотно) написати такий дзвінок і думати про це. Будь-який приклад виклику методу цього типу буде безглуздим. Ось ще:

String hello = "hello";
String number123AsString = hello.valueOf(123);

Це робить його таким, ніби кожен екземпляр рядка має метод "String valueOf (int i)".

В основному я вважаю, що дизайнери Java допустили помилку, коли розробляли мову, і занадто пізно це виправляти через проблеми сумісності. Так, це може призвести до дуже оманливого коду. Так, вам слід уникати цього. Так, вам слід переконатись, що ваша IDE налаштована так, щоб сприймати це як помилку, IMO. Якщо ви коли-небудь розробляли мову самостійно, майте це на увазі як приклад того, чого слід уникати :)

Щоб відповісти на думку DJClayworth, ось що дозволено в C #:

public class Foo
{
    public static void Bar()
    {
    }
}

public class Abc
{
    public void Test()
    {
        // Static methods in the same class and base classes
        // (and outer classes) are available, with no
        // qualification
        Def();

        // Static methods in other classes are available via
        // the class name
        Foo.Bar();

        Abc abc = new Abc();

        // This would *not* be legal. It being legal has no benefit,
        // and just allows misleading code
        // abc.Def();
    }

    public static void Def()
    {
    }
}

Чому, на мою думку, це вводить в оману? Тому що, якщо я розглядаю код, someVariable.SomeMethod()я очікую, що він використовуватиме значенняsomeVariable . Якщо SomeMethod()є статичним методом, це очікування недійсне; код мене обманює. Як це може бути добре ?

Як не дивно, Java не дозволяє використовувати потенційно неініціалізовану змінну для виклику статичного методу, незважаючи на те, що єдиною інформацією, яку вона буде використовувати, є оголошений тип змінної. Це непослідовний і безпомічний безлад. Навіщо це дозволяти?

EDIT: Це редагування є відповіддю на відповідь Клейтона, який стверджує, що дозволяє успадкування для статичних методів. Це не так. Статичні методи просто не є поліморфними. Ось коротка, але повна програма, яка демонструє:

class Base
{
    static void foo()
    {
        System.out.println("Base.foo()");
    }
}

class Derived extends Base
{
    static void foo()
    {
        System.out.println("Derived.foo()");
    }
}

public class Test
{
    public static void main(String[] args)
    {
        Base b = new Derived();
        b.foo(); // Prints "Base.foo()"
        b = null;
        b.foo(); // Still prints "Base.foo()"
    }
}

Як бачите, значення часу виконання bповністю ігнорується.

Чому це помилка? Екземпляр має доступ до всіх статичних методів. Статичні методи не можуть змінити стан екземпляра (спроба - це помилка компіляції).

Проблема з відомим прикладом, який ви даєте, дуже специфічна для потоків , а не статичних викликів методів. Схоже, ви отримуєте activeCount()для потоку, на який посилається thread, але ви дійсно отримуєте рахунок для виклику потоку. Це логічна помилка, яку ви як програміст робите. У цьому випадку компілятор повинен зробити попередження. Ви повинні прислухатися до попередження та виправити свій код.

EDIT: Я розумію, що синтаксис мови - це те, що дозволяє писати оманливий код, але пам’ятайте, що компілятор та його попередження також є частиною мови. Мова дозволяє зробити щось, що компілятор вважає сумнівним, але воно дає вам попередження, щоб переконатися, що ви знаєте, що це може спричинити проблеми.

Вони більше не можуть зробити помилку через весь код, який вже є.

Я з вами, що це повинна бути помилка. Можливо, повинен бути варіант / профіль для компілятора, щоб оновити деякі попередження до помилок.

Оновлення: Коли вони ввели ключове слово assert у 1.4, яке має подібні потенційні проблеми сумісності зі старим кодом, вони зробили його доступним, лише якщо ви явно встановили вихідний режим на "1.4" . Я припускаю, що це може зробити помилку в новому режимі джерела "Java 7". Але я сумніваюся, що вони зробили б це, враховуючи, що всі клопоти це може спричинити. Як зазначали інші, не потрібно суворо заважати вам писати заплутаний код. І мовні зміни в Java повинні обмежуватися строго необхідними на даний момент.

Коротка відповідь - мова це дозволяє, тому це не помилка.

Ймовірно, для того самого логічного, що робить це не помилкою:

public class X
{
    public static void foo()
    {
    }

    public void bar()
    {
        foo(); // no need to do X.foo();
    }
}

Справді важливою річчю, з точки зору компілятора, є можливість розпізнавання символів. У випадку статичного методу він повинен знати, в якому класі шукати його, оскільки він не пов'язаний з яким-небудь конкретним об'єктом. Дизайнери Java, очевидно, вирішили, що оскільки вони можуть визначити клас об'єкта, вони можуть також вирішити клас будь-якого статичного методу для цього об'єкта з будь-якого екземпляра об'єкта. Вони вирішили дозволити цьому - можливо, похитнувшись спостереженням @ TofuBeer - щоб надати програмісту певної зручності. Інші дизайнери мов зробили різний вибір. Можливо, я потрапив би до останнього табору, але для мене це не така вже й велика справа. Можливо, я дозволив би використання, про яке згадує @TofuBeer,

Це не помилка, оскільки це частина специфікації, але ви, очевидно, запитуєте про обґрунтування, про яке ми всі можемо здогадуватися.

Я припускаю, що джерелом цього є насправді дозволити методу в класі викликати статичний метод у тому ж класі без клопоту. Оскільки виклик x () є законним (навіть без імені власного класу), виклик this.x () також повинен бути законним, а отже, виклик через будь-який об'єкт також став законним.

Це також допомагає спонукати користувачів перетворювати приватні функції на статичні, якщо вони не змінюють стан.

Крім того, компілятори зазвичай намагаються уникати оголошення помилок, коли немає можливості, що це може призвести до прямої помилки. Оскільки статичний метод не змінює стан і не турбується про виклик об'єкта, він не викликає фактичної помилки (просто плутанини), щоб дозволити це. Достатньо попередження.

Метою посилання на змінну екземпляра є лише надання типу, який включає статику. Якщо ви подивитесь на байтовий код, що викликає статичний за допомогою instance.staticMethod або EnclosingClass.staticMethod, створюється той самий виклик статичного методу байт-коду. Посилання на екземпляр не відображається.

Відповідь також, чому це все там, ну просто є. Поки ви використовуєте клас. а не через екземпляр ви допоможете уникнути плутанини в майбутньому.

Можливо, ви можете змінити його у своїй IDE (у налаштуваннях Eclipse -> Java -> Компілятор -> Помилки / попередження)

Тут немає варіанту. У Java (як і в багатьох інших lang.) Ви можете отримати доступ до всіх статичних членів класу через його ім'я класу або об'єкт екземпляра цього класу. Це залежить від вас, вашого випадку та програмного рішення, яке з них вам слід використовувати, що забезпечує більшу читабельність.

Це досить стара тема, але все ще актуальна і напрочуд приносить більший вплив у наш час. Як зазначав Джон, це може бути просто помилкою, яку зробили дизайнери Java на самому початку. Але я не уявляю, що це може вплинути на безпеку.

Багато кодерів знають Apache Velocity, гнучкий і потужний механізм шаблонів. Він настільки потужний, що дозволяє подавати шаблон із набором іменованих об'єктів - суворо розглядається як об'єкти з мови програмування (спочатку Java). До цих об’єктів можна отримати доступ із шаблону, як у мові програмування, тому, наприклад, екземпляр Java String може використовуватися з усіма його загальнодоступними полями, властивостями та методами

$input.isEmpty()

де введенням є рядок , проходить безпосередньо через JVM і повертає true або false у вихідні дані синтаксичного аналізатора Velocity). Все йде нормально.

Але в Java всі об'єкти успадковуються від Object, тому наші кінцеві користувачі також можуть помістити це в шаблон

$input.getClass()

отримати екземпляр String Class.

І за допомогою цього посилання вони також можуть викликати статичний метод forName (String) щодо цього

$input.getClass().forName("java.io.FileDescriptor")

використовуйте будь-яке ім'я класу та використовуйте його для будь-якого облікового запису веб-сервера (деформувати, красти вміст БД, перевіряти конфігураційні файли, ...)

Цей подвиг якимось чином (у конкретному контексті) описаний тут: https://github.com/veracode-research/solr-injection#7-cve-2019-17558-rce-via-velocity-template-by-_s00py

Це було б неможливо, якби заборонялося викликати статичні методи з посилання на екземпляр класу.

Я не кажу, що певна програма програмування є кращою за іншу або близько того, але я просто хочу порівняти. Існує порт Apache Velocity для .NET. У C # неможливо викликати статичні методи лише з посилання на екземпляр, що робить експлойт таким чином марним:

$input.GetType().GetType("System.IO.FileStream, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089")

Я просто враховую це:

instanceVar.staticMethod();

щоб бути скороченням для цього:

instanceVar.getClass().staticMethod();

Якщо вам завжди доводилося це робити:

SomeClass.staticMethod();

тоді ви не зможете використовувати успадкування для статичних методів.

Тобто, викликаючи статичний метод через екземпляр, вам не потрібно знати, який конкретний клас є екземпляром під час компіляції, лише те, що він реалізує staticMethod () десь уздовж ланцюжка успадкування.

EDIT: Ця відповідь неправильна. Детальніше див. У коментарях.