Любой риск с использованием одного знака доллара `$` как имя класса java?

Первоначально я использовал символ подчеркивания _ как имя класса. Новый компилятор Java8 жалуется, что он "может не поддерживаться после Java SE 8". Я изменил это на $, и больше нет предупреждений. Однако я помню, что $ используется Java для указания внутреннего/внедренного класса в байтовый код. Мне интересно, есть ли риск использовать знак доллара $ как имя класса

Некоторые предпосылки к этому вопросу. То, что я хочу сделать, - это преодолеть тот факт, что Java не поддерживает чистую функцию, а _ или $- помещать пространство имен для инкапсуляции некоторого очень общего понятия (классы/статические методы). и у меня нет хорошего имени для этого, и я не хочу, чтобы пользователь lib вводил слишком много вещей, чтобы ссылаться на это пространство имен. Вот код, показывающий, что я делаю в пути: https://github.com/greenlaw110/java-tool/blob/master/src/main/java/org/osgl/_.java

ОТВЕТЫ

Ответ 1

Это плохой стиль и потенциально опасен для использования $ в любом идентификаторе на Java. Причина, по которой это рискованно, заключается в том, что символ $ зарезервирован для использования инструментальной привязки Java и сторонних инструментов языка.

  • Он используется компиляторами Java во внутренних именах классов для внутренних и вложенных классов.
  • Он используется компиляторами Java в именах синтетических атрибутов.
  • Он может использоваться сторонними генераторами кода (например, обработчиками аннотаций) для различных целей.
  • Он может использоваться другими языками, ориентированными на платформу JVM, и которые, возможно, должны сосуществовать с вашим кодом.

У вас, вероятно, не будет технических проблем с простым $ классом на данный момент (по крайней мере, в отношении стандартной Java-привязки). Но всегда есть вероятность, что это изменится в будущем:

  • Они оставили за собой право изменить это.
  • Существует прецедент для этого в примере _.

Если вам действительно нужно односимвольное имя класса, было бы лучше играть в нее безопасно и использовать F или Z или что-то еще, что не зарезервировано.

Но, честно говоря, я думаю, вам было бы лучше попытаться реализовать (или просто использовать) реальный функциональный язык, чем пытаться обучать "функциональную" систему программирования на Java. Или, может быть, просто переключитесь на Java 8 раньше официального релиза. "Потому что я бы отказался читать/поддерживать Java-код, похожий на jquery.

Я не хочу создавать функциональную lib для Java, просто хочу создать lib для поддержки некоторых общих утилит, которые я использовал. Опять же, я сторонник минимализма и чувствую себя сосать такими вещами, как apache commons. Функциональный материал добавлен, чтобы помочь мне легче манипулировать коллекцией.

Если это ваш код, вы можете делать то, что вам нравится. Примите свои собственные решения. Действуйте на свое мнение. Будьте "рискованным"...:-). (Наш совет по $ и т.д.... спорный.)

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

Ответ 2

Да, вы правы, используя $ в работе класса. Eclipse жалуется, что это противоречит конвенции, но, если вы уверены, вы можете это сделать.

Проблема (условно) с использованием $ заключается в том, что $ используется в иерархии классов для указания вложенных классов.... например, файл A.java, содержащий:

class A {
   class SubA {
   }
}

будет скомпилирован в два файла:

  • класс A.class
  • A $SubA.class

Вот почему, несмотря на то, что $ работает, это не рекомендуется, потому что анализ баннеров может быть более сложным... и вы рискуете столкнуться с двумя классами и вызвать другие проблемы.

EDIT, я только что прошел тест со следующими двумя файлами Java (в пакете по умолчанию)

public class A {
    private static final class SubA {
        public String toString() {
            return "I am initializing Nested SUBA";
        }
    }

    private static final SubA sub = new SubA();
    public A() {
        System.out.println("What is " + sub.toString());
    }
}



public class A$SubA {
    @Override
    public String toString() {
        return "I am A$SubA";
    }
}


public class MyMain {
    public static void main(String[] args) {
        System.out.println(new A());
        System.out.println(new A$SubA());
    }
}

И код не будет компилироваться.....

Две проблемы, тип A $SubA уже определен и не может ссылаться на вложенный класс A $SubA своим двоичным именем.

Ответ 3

Да, быть педантичным, чтобы ответить на ваш вопрос, есть риск. Как отмечали некоторые другие люди, это нарушает соглашения об именах java. Таким образом, риск состоит в том, что с будущими версиями JDK это может вызвать проблемы. Но помимо этого, и некоторые проблемы, если вы пытаетесь использовать вложенные классы, вы должны быть в порядке.

Ответ 4

Я думаю, вы пытаетесь избежать уродливых имен, таких как Util.andThen. Рассмотрите возможность использования статического импорта. Это позволяет импортировать все методы в заголовок import static org.ogsl.Util.*, поэтому вы можете просто использовать вас andThen без каких-либо префикса.

Ответ 5

Вы рискуете поймать попку, если кому-либо еще понадобится прочитать или сохранить свой код.