Есть ли смысл собирать отзывы для JSR/JEP, прежде чем вводить их в качестве предложения?
Я намерен запустить JEP/JSR, чтобы ввести альтернативный оператор доступа в Спецификацию языка Java. Я выяснил, как могло бы выглядеть предложение, и теперь я хочу собрать отзывы о нем (например, если я 999-й человек, предложивший это). Я хочу сделать это, желательно, прежде чем начать предложение. Однако, похоже, нет ни форума, ни форума, посвященного openJDK или процессу сообщества Java. По крайней мере, я не смог ничего найти. Однако я нашел канал IRC#openjdk, но, кроме людей, входящих и выходящих, там, похоже, нет связи.
Если я хочу пойти наименее инвазивным / навязчивым способом донести свою идею до других людей, какой путь я бы выбрал? Нет ли альтернативы, кроме фактического запуска JSR и ожидания активной обратной связи?
Помимо самого вопроса, потому что его спросили, какова точная идея:
Язык программирования Java позволяет создавать цепочки выражений, чтобы обозначить поток операций внутри более крупного выражения и облегчить доступ к "глубоким" значениям.
String fieldText = tableProvider.getTable(tableKey).getRow(rowKey).getField(columnKey).text;
Однако если
'.'
аксессор пытается получить доступ к нулевому объекту, генерируется исключение NullPointerException, что делает любой неконтролируемый доступ рискованным. Даже если запасной вариант для такого случая простоnull
или статическое примитивное значение, разработчик должен явно обрабатывать каждый возможный сценарий NullPointer. В качестве альтернативы они могут вообще пойматьNullPointerException
, что требует, чтобы возвращаемое значение было сохранено в переменной, определенной в области за пределамиtry-catch
блок, так что позже он может быть доступен за пределамиtry-catch
заявление. Тем не менее, это также ловитNullPointerExceptions
брошенный в любой доступный метод, который не может быть предназначен.Чтобы избежать этого, предлагается новый метод доступа, который прерывает разрешение цепочечного выражения в случае, если метод доступа получит доступ к нулевому объекту, и вместо этого вернется к
null
или указанное значение по умолчанию.
String fieldText = tableProvider.getTable(tableKey)°getRow(rowKey)°getField(columnKey)°text;
int i = tableProvider.getTable(tableKey)°getRow(rowKey)°getField(columnKey)°index ?: (-1);
В этом примере, если какой-либо из методов вызывает (getTable, getRow или getField), возвращает
null
все цепочечное выражение завершится и вернетсяnull
(или же-1
), а не выбрасывать исключение NullPointerException.
Выше приведен раздел "Мотивация" простого JEP/JSR, который я написал. °
это просто заполнитель для любого оператора, который не вызовет произвольной интерпретации. Фактический проект также определяет кучу не- целей, которые, среди прочего,
- Не нужно обращаться
null
в местах, гдеnull
не ожидается- Устаревать исключение NullPointerException.
- Как правило, заменить "." сбруя.
- Поймать уже выброшенные исключения NullPointerException.
- В общем случае замените класс Optional в его функции как тип возвращаемого значения.
Изменить: Похоже, что концепция, которую я предлагаю, уже является частью kotlin (среди прочих), но состоит из двух функций: "оператор безопасной навигации", а также "оператор elvis". На первом я хочу сосредоточиться.
1 ответ
JEP 1 говорит:
Ожидается, что [...] типичное новое предложение начнется с идеи, неофициально изученной и вытесненной в рамках конкретной группы, затем составленной в виде JEP для дальнейшего рассмотрения и комментирования, затем одобренной руководителем этой группы, а затем соответствующей областью. Ведущий, а затем передан для принятия Руководством OpenJDK. Обсуждаемые в ходе обсуждения обсуждения обычно проводятся по электронной почте, но обзорные совещания могут быть полезны для особо крупных или спорных предложений.
Так что в основном идея должна обсуждаться по электронной почте (обычно это означает в списке рассылки). Существует большой список списков рассылки Java по различным темам. Может быть, вы найдете там группу, связанную с вашим предложением.
Я думаю, что большинство языковых изменений спонсируется группой компиляторов, поэтому их список рассылки мог бы послужить хорошей отправной точкой для получения дальнейших указаний о том, где обсуждать, или даже инициировать обсуждение там.