Была тут недавно темка, где автору очень бы пригодилась такая конструкция языка как Alias для типа(класса), который можно было бы объявить, например, в секции импорта. "А в самом деле, почему нет?" - полезность такой синтаксической конструкции налицо  . "Если нет, но очень хочется, почему бы не сделать самому?" - спросил я себя во второй раз и полез ковыряться в исходниках javac . Как оказалось, чтобы добавить какую нибудь фичу надо менять код, парсера, лексера и т.д. Вот тут показаны несколько примеров сего действа, на примере того как добавить свой оператор. Но это конечно "не наши методы" , код, вобщем-то, - что называется internal.
"Нормальные герои всегда идут в обход©" - подумалось мне - "А почему бы изначально не сделать компилятор расширяемым?" (религиозным фанатикам JLS просьба дальше не читать  ), чтобы любой желающий мог бы легко добавить свою фичу и использовать её в исходном коде. Конечно речь идёт о таких вещах, которые реализуемы на этапе компиляции. В качестве примера, из уже существующих, можно привести boxing/unboxing conversions на этапе компиляции, оператор конкатенации строк и т.п. Идея, наверняка, не нова, но тем не менее почему бы не пообсудить...  
Минус этого дела, конечно, сразу налицо - если каждый начнёт свои фичи придумывать - будет большой бардак. Что же тут можно предложить...?, ну, например, автоматическую конверсию в исходный код, соответствующий текущей JLS.
Немного кухонных сентенций  : в C# синтаксического сахару поболе чем в Java, однако набор, если можно так выразится, - конечен, а эта идея состоит в том, чтобы самим себе и своим коллегам предоставить возможность добавлять в свои блюда не только сахар, но и соль, перец и др. пряности по вкусу, взять так сказать свою кухню под свой контроль, а точнее отдать.   Ну а если быть совсем точным - то, конечно, не всю кухню, это скорее похоже на волшебный сундучок, из которого, поколдовав над ним, можно выудить любую пряность.

Ну хотя бы потому, что - те кому это ну очень надо, так что спать кущать не могу так надо, могут это все реализовать через тот же JavaCC или что им там больше нравится.
А всем остальным не стоит этого делать, ибо:

•  запутывает код, т.е. человек не знакомый с этими расширениями не сможет прочитать этот код
•  усложняет перенос кода
•  вносит дополнительный источник ошибок
  если это широко используемое расширение, то тогда его конечно хорошо задокументируют и протестируют, но вот расширениям которые будут использоваться в узком кругу это не грозит

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

JavaCC позволяет всего лишь разобрать исходный код в Abstract Syntax Tree, ни о каком байт коде или формате .class файла он "не знает", поправьте если не так. Представление исходного кода в AST - это, ну где то процентов 15-20 от общей работы компилятора, ни один "спать, кушать не могущий" здравомыслящий товарищ не станет реализовывать остальную работу. А если для добавления новой "фичи" достаточно будет реализовать пару-тройку классов, и подключив их в CLASSPATH компилятора, начать этой фичей пользоваться - эта возможность мне кажется довольно привлекательной, не?


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


На уровне текста исходного кода - согласен. На уровне проекта целиком - можно расширения включать в состав сборочных файлов проекта, наряду с ant'овскими build-файлами или maven'овскими .pom.


Написание любого нового класса - потенциальный дополнительный источник ошибок. Это, громко говоря  , - часть нашей работы. Поэтому пока мне сложно принять это утверждение как аргумент. В конце концов - "Каждый человек имеет право на немного потупить©" 

LSD, спасибо за комментарий. 

С одной стороны такие фичи это конечно хорошо, а с другой - использование их без документации, а также отсутствие документации - плохо.

Да и прошли времена блокнотов... Если реализовывать кастомное расширение кода, то надо бы и поддержку IDE, хотя-бы Eclipse, Netbeans и IntelliJ IDEA.

По моему операторы можно было бы реализовать через интерфейсы, к примеру Comparable позволял бы сравнивать объекты через < или >, но отсюда выплывает очередная волна вопросов (даже по работе того-же оператора), где не будет единого мнения. Так что, в принципе, можно оставить все как есть. Не такой уж и бедный синтаксис.

После синтаксического разбора, можно породить стандартный Java код, эдакий препроцессор. Есть же SQLJ, причем он даже вроде стандартизован. Кстати неплохой пример, вроде штука хорошая полезная, но почему-то малоиспользуемая.



Все течёт, все меняется. Одни люди уходят из команды, и приходят новички которые незнакомы с этими фишками. И это считай дополнительное время на обучение.


Разовью мысль. Написание подобных плагинов достаточно сложная задача, которая требует хороших познаний в области построения компиляторов. Предусмотреть все подводные камни: чтобы не было неоднозначностей, побочных эффектов, проблем при взаимодействии с другими плагинами, очень и очень трудно. И на мой взгляд оправданность содержания в команде специалистов такого класса - сомнительна. Если язык настолько убог, что его надо дорабатывать напильником, то просто стоит поискать другой ЯП. Иначе небольшие плюсы, не компенсируют затрат на разработку и поддержку этих нововведений. Опять же представь что возникает странный и малопонятный баг. Помимо обычных действий по отладке придётся ещё дезассемблировать байткод, чтобы убедится, что нет ошибок в плагинах.


Плюс как уже заметил SoulKeeper, будут проблемы с поддержкой этих примочек на уровне IDE. Распознавать их синтаксис и не выдавать ошибок IDE ещё можно научить, а вот поддержку во всяких там визардах, генераторах и анализаторах - врядли. Опять же непонятно как там будет выглядеть отладка подобных вещей.


Плюс проблемы с нововведениями в синтаксисе самой Java. Представь, что кто-то вдохновился идеей шаблонов в C++ и перенёс её на JDK 1.4, а потом бац и выходит JDK 1.5 с поддержкой генериков.

Бесспорно.


Хочу подчеркнуть: речь не о том, чтобы вносить изменения в синтаксис языка (пусть этим занимается jcp.org), а о том, чтобы иметь такую возможность.


Почему-то мне кажется, что манипулируя байт-кодом напрямую, возможностей для манёвра будет поболее.


Может потому что имеет узкое применение. Ну а в свете всяких ORM, JPA и т.д. неудивительно.


Но ведь и эффективность работы от использования дополнительных возможностей должна возрасти, иначе какой смысл их использовать. Что перевесит, и какой набор расширений использовать пусть решает для себя каждая конкретная команда. Речь о том, чтобы у этой команды была бы такая возможность.


Соглашусь пожалуй. Хотя, по моему, стоит отметить, что эти сложности в большей степени относятся к дизайну и коду самого расширяемого компилятора, а не к "плагинам".


Ну не такой уж и высший класс, что тут такого особенного? Спецификация JVM? Это скорей относится к базовым знаниям любого Java разработчика. JLS? Аналогично. Байт-код? Формат .class файла? Ну и кроме всего прочего, совсем необязательно держать в команде такого специалиста. Никто у вас в команде ведь не занимается "доработкой напильником" того же Spring'а, Hibernate'а, ну или с чем вы там работаете... Вы просто берёте эти вещи и используете, так же можно взять готовое расширение.


К чему впадать в крайности. Этак можно объявить все синтаксические нововведения пятёрки - никому не нужной ерундой. ЯП - это просто инструмент разработчика, и что плохого в том, что вместо хорошего японского набора гаечных ключей у меня будет один разводной ключ. Он и легче и таскать удобнее  


Баг багу рознь. Я могу придумать ещё более запутанную ситуацию: Взять к примеру итерцепторы. Перехват вызовов методов используется практически повсеместно - AOP, Spring, Hibernate, практически любой J2EE контейнер. А принцип работы этих вещей прост - либо модификация байт-кода, либо генерация proxy, причём в рантайме. Если во внедряемом/генерируемом байт-коде будет баг, как его отлавливать? Что тут дизассемблируешь? Но ничего, живут эти штуки, используются и работают довольно успешно.


Возможно, но опять вопрос дизайна, хотя пожалуй можно согласиться.


так же как выглядит отладка уже существующих фич.


Естественно поддержка текущей JLS ложится на плечи разработчиков подобного компилятора. Если имеются ввиду конфликты между текущей реализацией поддержки JLS и расширениями работающими с той же синтаксической конструкцией - ну тоже вобщем то вопрос дизайна - допустим, например, можно разрешать настройкой приоритетов. 
Кстати на одном только синтаксисе реализация идеи шаблонов в 1.4 врядли возможна. С введением generics были внесены изменения в саму JVM, формат .class файла, и набор базовых классов JRE для их поддержки.

ну не сильно больше.  явовский верификатор не позволяет делать многие вольности. 
Ну разве что swap удастся реализовать для int'ов . для double'ов не удастся.





именно. Есть такой с++ ный компилятор -  OpenC++ compiler кажется, где подобные вольности (расширения) допустимы. Первые впечатления от него - очень частые segfault'ы при использовании расширений. 


и ещё не совсем понятно что делать если несколько пакетов решили изменить синтаксис в одинаковом месте.



не малая часть уже реализована. здесь  где-то был топик посвященный либе для генерации .class файлов

Это сообщение отредактировал(а) Mayk - 28.10.2008, 06:58

Для generics поддержка на уровне самой JVM минимальна, и даже особо не нужна. Код с generics спокойно переноситься на 1.4 и прекрасно работает. Вот для реализации generics как в C# - нужна поддержка со стороны JVM.



Они появились раньше, но популярности все равно не снискали. И между прочим многие до сих пор используют JDBC и пишут огромные запросы, потому как это более эффективно с точки зрения производительности. Но вот SQLJ все равно не используют. Хотя тут он был бы весьма кстати.



Сколько у тебя есть знакомых которые бы реально занимались разработкой компиляторов? Только не в институте писали курсовую на эту тему, а занимались коммерческим написанием компиляторов. У меня всего один такой знакомый и тот мой преподаватель по ЯП  
Тут помнится девушка искала кто бы ей мог помочь с грамматиками для JavaCC, так среди Java-истов никого не нашлось. Так что по моему, это весьма показательно сколько таких специалистов существует (и соответственно как просто будет его найти).



ЯП это не просто набор ключевых слов, операторов и синтаксических конструкций. Это некий баланс между возможностями, гибкостью, удобством использования и т.п.
Возможность же менять этот баланс принесет больше проблем чем пользы. Конечно хорошие дополнения к языку будут возникать, но количество синтаксических уродцев будет значительно больше.



Этими вещами пользуются тысячи разработчиков по всему миру, и потому баги там достаточно быстро отлавливаются. Ты же предлагал написать команде разработчиков маленькую синтаксическую приблуду для ЯП. А это уже совсем другое дело.
Да и область действия интерцепторов более узкая (или перед вызовом метода или после, сам метод не трогается), так что баги в них проще отлавливать.

С каких пор? 

Ну, в начале было слово...
И было это слово - Java, а потом слово за слово...., так и появилась The Java™ Virtual Machine Specification

Нет, вы не поняли. Как показывает практика, упомянутые спецификации в базовые знания какого-либо java-разработчика не входят. Не знаю уж, к сожалению или к счастью.