Комментарии 77
@pmcode ломбок — вряд ли, а вот элвис можно и пообсуждать. Только делать это надо вдумчиво. Во-первых, любому очевидно, что подобную фичу уже обсуждали. Надо не полениться, прочитать старые обсуждения и сделать выводы. Вот примерно отсюда надо почитать письма в марте 2009-го, примерно отсюда в июле. В этом письме элвиса отбрили, но, на мой взгляд, отбрили не кардинально, можно и пообсуждать заново. С тех пор я не нашёл серьёзных обсуждений на эту тему.
Даёшь val и var Java-миру!
Вероятно, в десятке всё-таки будет. Текущие обсуждения на эту тему настроены позитивно.
Было бы здорово оптимизацию хвостовой рекурсии
Дело сложное. Тоже уже десять лет как обсуждается. Но можете поднять вопрос :-)
Ну в какой-то мере дело движется, даже кое-что войдёт в девятку. А вообще Excelsior JET вам в помощь.
Ну и для сравнения
https://ru.wikipedia.orgru.wikipedia.org/wiki/Оберон_(язык_программирования)
В 1989 году в Швейцарской высшей технической школе Цюриха (ETH) была выпущена первая реализация Оберона для процессоров семейства NS32000. Он был создан в качестве компонента операционной среды Оберон. Этот компилятор требует менее 50 Кбайт памяти, состоит из 6 модулей общим объёмом около 4000 строк и сам себя компилирует за 15 секунд на компьютере с процессором NS32532 (тактовая частота — 25 МГц).
По утверждению Вирта[9], разработчики языка Java за несколько лет до её создания «изучили исходные коды Оберона и, в частности, исходные коды обероновских сборщиков мусора. Потом они испортили Оберон синтаксисом Си и назвали получившееся словом Java».
Из-за отсутствия встроенной AOT компиляции (с кешированием), существующие среды разработки написанные на java запускаются очень медленно и работают тоже не быстро, замедление работы стало особенно заметно в последних версиях эклипса и сред джетбрэйнса.
Ох, опять оберонофанаты атакуют. Казалось бы при чём он тут. Почитайте комментарии pjBooms на этот счёт. И про ценовую политику у него же можете спросить. Вроде есть возможность и бесплатно взять. А обновления безопасности они индивидуальные. Если HotSpot ломается на каком-то коде, не значит, что Excelsior на том же сломается. Там могут быть свои баги.
Нет также никаких гарантий, что Oracle не прекратит выпускать джаву.
Нет также никаких гарантий, что Oracle не прекратит выпускать джаву.
Sun прекратила.
Но передала в open source.
Java написана на си, а AOT-компиляция в нативный код позволила бы переписать джаву на джаве.
Excelsior JET это проприетарный продукт со своими целями создания.
Тема же статьи про OpenJDK, а не «Оракл JDK».
Про AOT-компиляцию в OpenJDK 9 я знаю.
Но там цели AOT-компиляции отличаются от тех которые предлагаю я.
Я бы хотел, чтобы исходный код на java, сначала преобразовывался в промежуточное представление — Абстрактное синтаксическое дерево (АСД), а затем уже генерировался байткод или нативный код под разные архитектуры процессоров.
Где то читал что байткод легко декомпилируется в исходный код на джаве. Соответственно при изменении в самом языке java, разработчикам языка приходится учитывать обратную совместимость. Таким образом в джаве сохранились его недостатки и невозможно легко улучшить язык не нарушив обратную совместимость.
А при использовании АСД можно было бы улучшать язык не обращая внимания на обратную совместимость (просто выбирается нужная версия компилятора).
По сути, подобную идею реализовали в пятом андроиде. В андроиде с пятой версии при инсталляции программы производится AOT-компиляция.
Компиляция в байткод и компиляция байткода в нативный код — две отдельные задачи. javac (компилятор джавы в байткод) строит промежуточное AST и его даже можно использовать в своих программах при желании.
Где то читал что байткод легко декомпилируется в исходный код на джаве. Соответственно при изменении в самом языке java, разработчикам языка приходится учитывать обратную совместимость.
Не вижу, как из возможности декомпиляции байткода следует необходимость учитывать обратную совместимость. Обратная совместимость требуется совсем не поэтому. Любой язык невозможно легко улучшить, не нарушив обратную совместимость.
А при использовании АСД можно было бы улучшать язык не обращая внимания на обратную совместимость (просто выбирается нужная версия компилятора).
Ну и получится у вас Python 2 и Python 3. Или Perl 5 и Perl 6. Это путь не для джавы. Java-компиляторы предоставляют возможность компилировать в старую версию байткода и воспринимать исходники как написанные на старой версии. В девятой джаве это ещё улучшится. Сломать обратную совместимость для авторов компилятора джавы ничего не стоит. Только джава бы не была настолько популярна, если б в каждой версии ломали обратную совместимость.
Java написана на си, а AOT-компиляция в нативный код позволила бы переписать джаву на джаве.
Ну собственно и сейчас ничто не мешает переписать джаву на джаве кроме того, что это потребует огромных трудозатрат. Проект Graal — важный шаг в этом направлении.
Любой язык невозможно легко улучшить, не нарушив обратную совместимость.
Именно это я и хотел сказать. Невозможно легко улучшить.
Язык java создавался когда только появились 32битные процессоры, а сейчас даже в смартфонах ставят 64битные. Первоначально джава проектировался для интернета, а сейчас сфера его применения значительно расширилась.
Тактовые частоты процессоров почти не растут, а для современных программ требуется всё большее и большее быстродействие. И скорее всего для дальнейшего увеличения быстродействия, потребуется изменение архитектуры процессоров (изменение системы команд).
И какое отношение всё это имеет к языку?
Язык java создавался когда только появились 32битные процессоры, а сейчас даже в смартфонах ставят 64битные.
64-битный long в java был с начала времён.
Первоначально джава проектировался для интернета, а сейчас сфера его применения значительно расширилась.
А язык тут при чём?
Тактовые частоты процессоров почти не растут, а для современных программ требуется всё большее и большее быстродействие.
java.util.concurrent
И скорее всего для дальнейшего увеличения быстродействия, потребуется изменение архитектуры процессоров (изменение системы команд).
Да на здоровье!
Трансляция в систему команд процессора — задача JIT.
И какое отношение всё это имеет к языку?
Что Вы имеете в виду? Язык java как абстрактное понятие или OpenJDK как его реализация?
64-битный long в java был с начала времён.
В 64-битных процессорах «указатели» имеют размер 8 байт, а соответственно массив объектов размером в 1 байт будет занимать в памяти минимум 9 байт на один объект. Получается двоичная не совместимость с 32-битными процессорами при компиляции в нативный код, вместо байткода.
и стоит ещё посмотреть X32_ABI, который вообще не имеет отношение к java — но тоже использует 32бита на 64х битных архитектурах, но при этом используя 64х-битные инструкции.
Основной лозунг джавы — «написано однажды — работает всегда».
Например Вы написали программу для работы с видеофайлами для 32х битных указателей, в этом случае Вам придётся дорабатывать её для работы с большими файлами.
нигде у java наружу не торчат указатели — вообще никакие.
причём тут указатели и как вы обрабатываете данные?
Я знаю что в java вообще нет указателей. Просто предположил что вы имели ввиду ссылки, которые во внутреннем представлении можно считать «указателями».
То есть данные я обрабатываю обычным образом, размещая их в памяти.
Например, максимальный размер файла в ext2fs может быть куда больше 4 Гб — доп. проблема, что некоторые приложения не имели Large File Support — читай — было заимплеменчено криво.
При этом и само ядро, и фс вполне себе нормально работали на 32х битах с такими большими файлами.
Ну и получится у вас Python 2 и Python 3. Или Perl 5 и Perl 6. Это путь не для джавы. Java-компиляторы предоставляют возможность компилировать в старую версию байткода и воспринимать исходники как написанные на старой версии. В девятой джаве это ещё улучшится. Сломать обратную совместимость для авторов компилятора джавы ничего не стоит. Только джава бы не была настолько популярна, если б в каждой версии ломали обратную совместимость.
Python и Perl это изначально интерпретируемые языки и их предназначение скрипты. Быстродействие программ (скриптов) написанных на них не так важно, как скорость написания самих скриптов.
В первых версиях джавы не было JIT-компиляции и скорость программ на джаве была примерно в 10 раз медленнее чем аналогичных программ на С++.
Сейчас типичная программа на джаве примерно в 2-3 раза медленнее аналогичной программы на С++, а по некоторым источникам, в отдельных случаях, джава даже обгоняет С++ по быстродействию.
Фридерик Брукс в своей книге «Мифический человеко-месяц ...» писал что серебрянной пули не существует, сложные программы и в будущем будут сложными и не новый язык программирования ни новые инструменты разработчика, не повысят существенно скорость разработки программного обеспечения.
Стив Макконнелл в книге «Совершенный код» пишет что основная причина популярности джавы — это сборщик мусора. Так как gc позволяет программистам сосредоточиться на алгоритме не отвлекаясь на управлении памятью, что ведёт к повышению быстродействия программистов на джаве по сравнению с программистами на С++.
Обратная совместимость для языка конечно же очень важна, но только в той степени пока она не мешает повышать скорость разработки программ на этом языке.
Раньше тактовые частоты процессоров росли и можно было взять(потратиться на) более быстрое железо вместо того чтобы оптимизировать алгоритм. Сейчас же технологии упёрлись в размеры атомов и вряд ли в ближайшие годы произойдёт значительное увеличение быстродействия процессоров.
Сейчас основной способ значительно увеличить скорость разработки ПО, это использование готовых компонентов (ну и возможно генеративного программирования). А для готовых компонентов важна не обратная совместимость языка программирования, а двоичная совместимость интерфейсов.
Обратная совместимость для языка конечно же очень важна, но только в той степени пока она не мешает повышать скорость разработки программ на этом языке.
Нет, это не так.
А для готовых компонентов важна не обратная совместимость языка программирования, а двоичная совместимость интерфейсов.
И это не так.
Или может быть Вы считаете что двоичная совместимость не важна? Например Вы написали библиотеку и скомпилировали её для 32х битных процессоров, а программу, в которой её (библиотеку) будут подключать, разрабатывается для 64х битного процессора.
То есть Вы думаете что заказчики готовы платить Вам в течении двух лет, за разработку программы, вместо одного года, лишь бы Вам не пришлось учить новый язык программирования?Наивно полагать, что переход на новый волшебный язык вдруг резко ускорит разработку.
Например Вы написали библиотеку и скомпилировали её для 32х битных процессоров, а программу, в которой её (библиотеку) будут подключать, разрабатывается для 64х битного процессора.Если у вас появилось желание использовать 32-битную* библиотеку в 64-битной программе, вы должны перекомпилировать эту библиотеку под 64-битный процессор, получив тем самым 64-битную библиотеку.
Совершенно не ясно, при чём тут java. И java-приложение и используемая им java-библиотека будут исполняться в рамках одной JVM.
Наивно полагать, что переход на новый волшебный язык вдруг резко ускорит разработку.
Согласен. Об этом же писал и Ф.Брукс. Java достаточно зрелый и эффективный язык и улучшить его уже сложно.
Но под платформу джавы разработали ещё и Scala, Kotlin и другие языки.
Совершенно не ясно, при чём тут java.
Для хоть как то заметного улучшения я предложил добавить AOT-компиляцию, похожую на то как это сделано в андроиде, но с дополнительными улучщениями.
Свою позицию я уже описал достаточно подробно, профессионалы остальное могут додумать сами.(автор статьи написал что дальнейшая дискуссия для него бесполезна)
Предлагаю не засорять ветку сообщениями на другую тему.
По вопросам не связанным с AOT-компиляцией предлагаю всем писать в личку.
Java написана на си, а AOT-компиляция в нативный код позволила бы переписать джаву на джаве.
Ну собственно и сейчас ничто не мешает переписать джаву на джаве кроме того, что это потребует огромных трудозатрат. Проект Graal — важный шаг в этом направлении.
Вот нашёл интересную статью
https://habrahabr.ru/company/badoo/blog/317864/
К тому моменту, как мы добрались до PowerPC, добавление в ассемблер поддержки этой новой архитектуры заняло пару часов – настолько это было просто.
Так же как примерно одинаковы все ассемблеры, так же примерно одинаковы похожие программы, написанные на различных языках программирования, представленные в виде АСД.
Excelsior JET это проприетарный продукт со своими целями создания
Sun JRE/JDK до передачи в Open source тоже был проприетарный продукт, но ничего все пользовались.
Sun прекратила.
Но передала в open source.
Если мы прекратим, то нам тоже ничего не будет мешать передать проект в open source. Но пока не похоже — еще много не окученных грядок и продажи пока позволяют развивать проект дальше.
Java написана на си,.
Java не написана на Си. Java — это набор спецификаций. OpenJDK — лишь одна из реализаций и чуть ли не единственная из таких реализаций, где AOT до недавнего времени не было.
IBM сейчас выкладывает в Open source свой J9 и у Java появляется как минимум две реализации в открытом доступе, реализующие в полном объеме спецификацию. И то, и другое — Java. Говорить, что в Java нет AOT — это неверно, начиная с как минимум 2005 года.
а AOT-компиляция в нативный код позволила бы переписать джаву на джаве
Не все можно переписать на чистой Java. К примеру кто будет собирать мусор за GC, если он написан на Java. У того же IBM была JVM, существенная часть которой написана на Java. У JRockit тоже была реализация аллокаторов на Java. Ну и у нас большая часть JVM написана на Java.
vasiliysenin как в воду глядел.
pjBooms, скажите, пожалуйста, неужели это правда, что Excelsior JET все?
включая обновления безопасности
Обновления безопасности в Oracle JRE чаще всего относятся к браузерному плагину для Java апплетов и Java Web Start. Обе технологии у нас в продукте не поддерживаются. Тем не менее мы стараемся апдейты для PSU выпускать и два раза в год гарантируем (против четырех у Oracle).
Из-за отсутствия встроенной AOT компиляции (с кешированием), существующие среды разработки написанные на java запускаются очень медленно и работают тоже не быстро
Oracle HotSpot AOT, как раз направлен на борьбу с медленным запуском. Скорость работы сейчас гораздо меньше связана с наличием/отсутствием AOT, она больше связана с ростом объема кода самих программ и связанным с этим уровнем вложенности абстракций. MS Visual Studio тоже работает не быстро, хоть и скомпилирована AOT компилятором.
Вообще Eclispe/JetBrains мы давно умеем компилировать статически и даже у нас на сайте можно найти их (несколько устаревших версий) в скомпилированном виде и скачать абсолютно бесплатно. Мы с JetBrains довольно давно ведем переговоры, чтобы они выкладывали JET-скомпилированные версии своих продуктов на сайт, но переговоры двигаются не очень быстро (а сами мы не находим ресурсов обновлять их).
Oracle HotSpot AOT, как раз направлен на борьбу с медленным запуском. Скорость работы сейчас гораздо меньше связана с наличием/отсутствием AOT, она больше связана с ростом объема кода самих программ и связанным с этим уровнем вложенности абстракций. MS Visual Studio тоже работает не быстро, хоть и скомпилирована AOT компилятором.
Я предполагаю, что Oracle HotSpot AOT, использует существующий код JIT-компиляции, для генерирования нативного кода и его сохранения для использования при последующем запуске программы.
Настоящий AOT компилятор, в отличие от JIT, имеет больше времени для оптимизации. Например если есть java-класс который вызывает другой класс, а тот третий в котором просто надо получить какое-то значение. То JIT-компилятор будет последовательно вызывать геттеры, а оптимизирующий AOT компилятор, в такой ситуации, мог бы просто переместить несколько байтов в памяти (MOV AX, addr), избавившись от «лишних вложенных абстракций». Или например при однотипной обработки массива байтов, можно воспользоваться дополнительными инструкциями процессора (SIMD, AVX).
Вообще Eclispe/JetBrains мы давно умеем компилировать статически и даже у нас на сайте можно найти их (несколько устаревших версий) в скомпилированном виде и скачать абсолютно бесплатно. Мы с JetBrains довольно давно ведем переговоры, чтобы они выкладывали JET-скомпилированные версии своих продуктов на сайт, но переговоры двигаются не очень быстро (а сами мы не находим ресурсов обновлять их).
Скачал эклипс с вашего сайта и Eclipse SDK Version: 4.2.2 Build id: M20130204-1200
с сайта эклипс, написал HelloWorld в обоих версиях и нативная версия выдала ошибку
Unbound classpath container: 'JRE System Library [OSGi/Minimum-1.2]' in project 'HelloWorld'
Хотя конечно запускается быстре, примерно 2-3 секунды против 8-ми секунд у не нативной версии.
А в остальном эта версия эклипса (Version: 4.2.2) работает примерно с одинаковой скоростью (по субьективным ощущениям) в обоих вариантах.
А сколько надо ресурсов, чтобы скомпилировать Eclipse или JetBrains с помощью Вашего продукта?
Unbound classpath container: 'JRE System Library [OSGi/Minimum-1.2]' in project 'HelloWorld'
Ну так научитесь эклипсом пользоваться. Где он по вашему джаву возьмёт (стандартную библиотеку и т. д.)? Если вы запустили эклипс с помощью JRE, он автоматом вам эту JRE нашёл и заиспользовал при компиляции программ, которые вы пишете. А если вы запустили скомпилированный AOT'ом эклипс, как он догадается, какую JRE взять? Будет весь ваш жёсткий диск перекапывать в поисках джавы?
А сколько надо ресурсов, чтобы скомпилировать Eclipse или JetBrains с помощью Вашего продукта?
Пару часов на современных персональных компьютерах.
А в остальном эта версия эклипса (Version: 4.2.2) работает примерно с одинаковой скоростью
(по субьективным ощущениям) в обоих вариантах.
Вот вам и ответ про AOT. Будет он в OpenJDK или нет, настоящим он будет или нет, по субъективным ощущениям в IDE существенную разницу вряд ли почувствуете. Хотя по моим субъективным ощущениям, мне кажется, что jet-скомпилированная идея реагирует пошустрее (у свинга больше слой абстракций, чем у SWT), но каждый кулик, понятно, хвалит свое болото. А померить ощущения надо еще придумать как.
Хотя по моим субъективным ощущениям, мне кажется, что jet-скомпилированная идея реагирует пошустрее
К вопросу о субъективности. Автора zero-latency typing в IDEA спрашивали, действительно ли быстрее. Он рассказал, что как-то запустил и ощутил прямо прирост отзывчивости. Порадовался, а потом обнаружил, что zero-latency typing отключен, а он думал, что включен. Эффект плацебо в действии :-)
class A(val p: Int)
fun main(args: Array<String>) {
val prop = A::p
println(prop.get(A(1))) // prints "1"
}
Обсуждалось в рамках проекта лямбда. В джаве обычно не нужно, так как поля всё равно скрыты. Зато это существенно усложняет резолюцию метод-референсов, которая и так сложная. Сейчас A может быть ссылкой на класс, а может быть ссылкой на инстанс-объект с именем A. Так добавится неоднозначность, что p может быть именем поля, а может быть именем метода. В джаве легко иметь поле и метод с одинаковым именем, но тогда method-reference вообще не сделаешь: будет неоднозначность. Теперь уже и не добавить это, не поломав обратную совместимость. Ну и написать (A a) -> a.p не сильно длиннее так-то.
Аннтоцию @Singleton — метод getInstance() и ссылка на объект генерятся автоматически
Аннтоцию @Sealed — метод sealed() генерится автоматически и после его вызова все поля класса становятся final
Элвис оператор — взгляд со стороны: вместо 'употребления' его с вызывающей стороны перенести в тип, как пример, public SomeData? getSomeData(String? type), думаю идея понятна
Оператор декапсуляции — опасный, но иногда очень нужный — осуществляет доступ к приватным полям (например для тестов), пример, someInstance#privateFieldName
Некоторые фантазии свои вспомнить не могу, дело давно было…
Аннтоцию Singleton — метод getInstance() и ссылка на объект генерятся автоматически
Ну нафиг, есть же Dependency inject'он фреймворки которые поддерживают эту аннотацию из спецификации JSP 299. А создавать сингельтон руками это совсем уж антипатерн, не говоря уже о вопросах потокобезопасности getInstance(). Его не протестировать толком в unit тестах и он нарушает SOLID принципы.
Оператор декапсуляции — опасный, но иногда очень нужный — осуществляет доступ к приватным полям (например для тестов), пример, someInstance#privateFieldName
Опять-таки, ну нафиг хотите берите рефлексию и работайте с приватными полями. Можно даже сделать в тестах статическую функцию, которая вернет поля, а аля getPrivateField(someInstance, privateFieldName), это практически тоже самое. Но как только введут оператор декапсуляции, так его начинающие начнут везде юзать. Это как goto, он имеет иногда смысл, но не настолько насколько он может быть вредным в кривых руках.
Про потокобезопасность Singleton — так в том-то и суть, чтобы java забрала у нас шедевры человеческого разума по их реализации и сделала безопасными, я такие видел, как вспомню аж муражки по коже, да и сам черные дела творил, что греха таить. Вот один из них
// Прости гениев и помилуй
public enum MySingleton {
MY_SINGLETON;
private MySingleton() {
init();
}
private void init() {/**..some_init_work...*/}
public Result doSomeWork(/**args*/){/**..some_work...*/}
}
//где-то в коде, статик импорт
MY_SINGLETON.doSomeWork(/**params*/);
Насчет протестировать, я наверное Ваш контекс не уловил,
assertEquals(etalonValue, MySingleton.getInstance().doSomeWork(data))По поводу JSP 299 и реализации (weld, как пример), есть маленький проектик на 40-50 классов и 2 синглтона, уж очень не хочется тащить в проект слона или из жизни, главный архитектор запретил напрочь в ядро системы (оформлено обычным модулем с java классами) использовать какие-либо зависимости (даже apache) — только jdk и синглтончик там имеется.
По поводу декапсуляции все таки рефлексия != оператор декапсуляции. Пример из жизни (про безопасность), делали мы проект для 3их лиц, код представляет ценность и его эксплуатация тоже, Один из классов имеет 3 поля, важных, наружу не торчат нужно было проверять время от времени их состояние и согласованность, дошло время до защиты исходников — тут все просто, накрыли jar proguard'ом, нужна была защита от reverse engineering, дела здесь посложнее, но выкрутились — критичное накрыли stringer'ом (не сочтите за рекламу). И дальше — самое интересное, что достучаться просто до поля по его имени (после всего что было :) — та еще задачка (глаза вверх — момент тогда я познал дзен)
Еще был вариант — получал ВСЕ поля, и сравнивал типы.
… А потом все равно пришлось от этой глючной возможности отказываться.
Про синглтон:
Что так: простой и паттерн реализации легко запоминается
Что не так:
1) Эстетический пейзаж фауны enum класса в виде синглтона оставляет желать лучшего
2) enum все таки перечисление сущностей одного типа и предназначен для другого нежели сингл тон — как боевая единица бизнес задачи
3) под капотом этого синглтона будут лишние методы values и valueOf, конструктор с лишними аргументами, скрытые поле $values с блоком инициализации, неоправданное наследование от класса Enum, а также по факту он будет фабрикой для получения единственного объекта по имени енума. Кое-что мог упустить или не точно указать так как пишу по памяти
По второму вопросу — это один ИЗ прикладных способом защиты приложения, а не bad-design code как Вы подумали
Простой способ получить очень хороший синглтон
Я буду честен — встречал всего один раз такой подход, и думаю недостаточно 1го раза для вывода с моей стороны лучший или хучший
По факту любой синглтон такая фабрика.
Вот с этим я пожалуй не соглашусь.
// Ярко выраженный фабричный метод
MySingleton instance1 = MySingleton.valueOf("MY_SINGLETON");
// Доступ к синглетрну можно и так осуществить
MySingleton instance2 = MySingleton.values()[0];
// и так
MySingleton instance3 = MySingleton.MY_SINGLETON;
Спрошу: Вы используете у себя в коде такой подход?
Для аннотаций можно написать annotation processor, это Java позволяет — это официальный способ расширять язык.
Декапсуляции точно не будет и это исключительно хорошо. Напротив Java закручивает гайки. Уже в девятке вы через reflection не залезете куда угодно. Любой код может отгородиться от этого и сказать, что нечего в меня лазить. И всё, привет. Сама Java тоже так сделает, то есть в классы JDK вы уже в девятке не залезете через reflection. Останется только Unsafe и JNI, но вполне вероятно, что к десятке и Unsafe открутят. Java должна быть безопасной. В этом её важное отличие от каких-нибудь питонов.
Для тестов делайте поля package-private и помещайте класс теста в тот же пакет.
Вещь, которая изо дня в день бесит в java — геттеры сеттеры. Пусть сделают человечный property в качестве сахара. Дабы не быть голословным:
class Test {
private String vasya;
public String getVasya() { return this.vasya;}
public void setVasya(String vasya) { this.vasya = vasya;}
}Итак, для описания одного лишь свойства vasya мы повторили это слово 7 раз в общей сложности затратив 17 слов! Думаете все? Нет. Добавьте еще javadoc-описание свойства к гетеру и продублируете его же в сеттере.
Хочется некий алиас который бы генерировал для свойства поле, геттер и сеттер, а в интерфейсах только геттер и сеттер, плюс который бы позволял в коде напрямую обращаться к property. При этом бы вся семантика с override сохранялась.
Может быть можно задействовать «транспайлер» или сниппет в текстовом редакторе?
Зачем вам такой код? Сделайте публичное поле vasya и не мучайтесь :-)
Де-факто в Java есть проперти. И описаны они в стандарте JavaBeans при помощи геттеров и сеттеров. И многие сторонние фреймворки и библиотеки не привыкли работать напрямую с полями, а вместо этого делают интроспекцию пропертей.
В общем случае некорректно думать о пропертях как о полях для хранения данных. Пропертя позволяют скрыть логику хранения данных и добавить дополнительный функционал как валидация значений, lazy-инициализации, связанные значения, события, etc. Ну и естественно, сделовать принципам ООП и переопределять поведение при наследовании.
А в DTO геттеры и сеттеры действительно не нужны. Я по возможности стараюсь их делать immutable со всеми полями public final. Есть неплохой проект на этот счет Immutables.org.
Хотелось услышать Ваши экспертные мнения, не халивара ради, a больше для себя, по некоторым аспектам, которые меня беспокоят:
1) Не станет ли 'наша' java другой после внедрения Lombok, не потеряет ли она свое изящество, когда содержательной части станем меньше, чем аннотаций, как пример:
@Entity
@Table(name = "EMPLOYEE")
@RequiredArgsConstructor(staticName = "of")
@AllArgsConstructor(access = AccessLevel.PUBLIC)
@ToString(exclude="description")
@EqualsAndHashCode(exclude="description")
public class Employee {
@Getter
@Setter
@NonNull
private Integer id;
@Getter
@Setter
@NonNull
private String description;
}
2) Как будет осуществляться поиск использования методов, скажем, toString или getId и что будет с java-doc'ми этих методов в наших любимых IDE?
3) Какие баги нас могут ждать после начала эксплуатации фишек этого проекта?
Я понимаю что отстал по этой теме лет на 6 так, но все же. Заранее спасибо отвечающим.
К IDE бывают плагины, которые помогают ей понимать, что методы на самом деле есть. Вообще, насколько я понимаю, Java+Lombok — это не Java. Lombok не является annotation processor'ом в том смысле, в котором определено в спецификации языка, поэтому это по сути дела новый язык. А если уж переходить на новый язык, то может лучше взять Kotlin или Groovy?
Эклипс у меня, кстати, дико крэшился, когда я в него поддержку ломбока поставил. Может, конечно, была какая-нибудь неудачная версия...
Lombok не является annotation processor'ом в том смысле, в котором определено в спецификации языка, поэтому это по сути дела новый язык.
А технически он также остаётся annotation processor'ом как и, скажем, org.immutables:value?
Начинается разработка OpenJDK 10