потому что на стабильной 2017.3.5 не поддерживается этот language level.
Если я правильно помню, там был более хитрый алгоритм: надо просто написать var x = "foo", а когда подсветит красным, там есть квик-фикс на нём. Так-то в 2017.3 у нас уже всё работало. Но вообще да, проще на 2018.1 уже перейти.
Если в контракте написано, что "метод add добавляет элемент, а метод addAll добавляет все элементы", то базовый класс волен поменять реализацию и использовать, либо не использовать add внутри addAll, этим он контракт не нарушает.
Не все клиенты вашего класса могут быть вам доступны. А если доступны все и всегда (у вас не библиотека, а приложение, которое не подразумевает сторонних плагинов), то необходимость выделения виджета без нотификаций вызывает ещё больше вопросов. Ключевой принцип ООП — инкапсуляция. В том числе она означает, что пока существующий класс сохраняет свой контракт, приложение не должно ломаться. Добавление нового метода или изменение реализации addAll через add не изменяет существующий контракт, но ломает приложение.
Ну так потому что уже особо не надо: JEP-280 срабатывает в подавляющем большинстве случаев (кроме модуля java.base и вручную написанных StringBuilder'ов). По сути дела и существующую оптимизацию если удалить, сильно хуже не станет.
Самое интересное, что в MyObservableWidget вы должны будете переопределить все методы MyWidget, изменяющие состояние, чтобы вызвать в них notify(). При этом вы попадаете на жёсткую зависимость от реализации MyWidget. При добавлении нового метода в MyWidget, который изменяет состояние, вам придётся изменять MyObservableWidget, иначе ничего вас не спасёт от багов. А если метод вроде addAll вместо ручной реализации в новой версии начнёт в цикле вызывать add, вы пришлёте миллион эвентов вместо одного (либо обратное произойдёт, тогда вы в новой версии вообще не пришлёте эвент). В этой ситуации невозможность множественного наследования и необходимость вручную делегировать пару методов к какому-нибудь подобию javax.swing.event.EventListenerList — это наименьшая из ваших проблем. Я считаю, если вы не используете аспекты или что-то аналогичное (а я совсем не призываю их использовать), то вы не сможете сделать изменяемую структуру данных отдельно от нотификаций, а потом прикрутить нотификации в дочернем классе. Вообще наследование конкретных классов плохо пахнет. Если вам при этом приходится переопределить реализацию N методов (например, "все методы, которые изменяют состояние"), вы точно ищете себе проблемы. На это напоролся, например, EclipseLink, который расширил ArrayList, переопределив все методы, а в Java 8 — сюрприз — появились новые методы.
И вот тут-то JIT-компилятор может хорошо покуражиться
JIT-то тут при чём? Основную работу делает собственно фабрика, генерируя цепочку методхэндлов, которые сперва считают суммарную длину всех строк, затем выделяют один массив точно нужного размера и всовывают его в строку через небезопасный конструктор.
Если вам специалньо нужно подержать переменную, для этого есть специальный API-метод Reference.reachabilityFence(). Нужен он в реальной жизни исключительно редко, а из-за такой оптимизации вы получаете существенный прирост в производительности вашей программы нахаляву.
В четвёртой задаче я рассуждал, что ничего не мешает создать свой класс class java.lang.Integer implements Iterable и загрузить кастомным класслоадером. Ну или в bootstrap classpath подсунуть. Нет?
Я бы в резюме явно написал «контрибутил в такие-то и такие-то проекты, список моих коммитов в этих проектах вот по ссылке». Разумеется, выбрав только наиболее значительные и релевантные планируемому месту работы, чтобы сэкономить время потенциальному работодателю.
Вы думаете, обычный AOT-компилятор вам будет выдавать код одинаковой производительности на разный профиль? Вы компилируете с использованием рантайм-профиля?
> И, кстати, в вызов метода checkIndex передавать надо, наверное, index:
Да, спасибо.
> почти двукратное «торможение» параллельных стримов
970 против 806 — это почти двукратное? У вас одна итерация существенно быстрее. Явно процессор другой. Возможно, с улучшенной хардварной поддержкой криптографии. Можно усложнить функцию и посмотреть, что получится. Ну и количество ядер хотя бы указывайте. Вряд ли меньше четырёх, но мало ли.
Если я правильно помню, там был более хитрый алгоритм: надо просто написать
var x = "foo"
, а когда подсветит красным, там есть квик-фикс на нём. Так-то в 2017.3 у нас уже всё работало. Но вообще да, проще на 2018.1 уже перейти.Интересно, а компилятор проверит, что обещания контракта метод действительно выполняет или примет их на веру?
Если в контракте написано, что "метод
add
добавляет элемент, а методaddAll
добавляет все элементы", то базовый класс волен поменять реализацию и использовать, либо не использоватьadd
внутриaddAll
, этим он контракт не нарушает.Самое интересное, что в
MyObservableWidget
вы должны будете переопределить все методыMyWidget
, изменяющие состояние, чтобы вызвать в нихnotify()
. При этом вы попадаете на жёсткую зависимость от реализацииMyWidget
. При добавлении нового метода вMyWidget
, который изменяет состояние, вам придётся изменятьMyObservableWidget
, иначе ничего вас не спасёт от багов. А если метод вродеaddAll
вместо ручной реализации в новой версии начнёт в цикле вызыватьadd
, вы пришлёте миллион эвентов вместо одного (либо обратное произойдёт, тогда вы в новой версии вообще не пришлёте эвент). В этой ситуации невозможность множественного наследования и необходимость вручную делегировать пару методов к какому-нибудь подобиюjavax.swing.event.EventListenerList
— это наименьшая из ваших проблем. Я считаю, если вы не используете аспекты или что-то аналогичное (а я совсем не призываю их использовать), то вы не сможете сделать изменяемую структуру данных отдельно от нотификаций, а потом прикрутить нотификации в дочернем классе. Вообще наследование конкретных классов плохо пахнет. Если вам при этом приходится переопределить реализацию N методов (например, "все методы, которые изменяют состояние"), вы точно ищете себе проблемы. На это напоролся, например, EclipseLink, который расширилArrayList
, переопределив все методы, а в Java 8 — сюрприз — появились новые методы.JIT-то тут при чём? Основную работу делает собственно фабрика, генерируя цепочку методхэндлов, которые сперва считают суммарную длину всех строк, затем выделяют один массив точно нужного размера и всовывают его в строку через небезопасный конструктор.
Если вам специалньо нужно подержать переменную, для этого есть специальный API-метод Reference.reachabilityFence(). Нужен он в реальной жизни исключительно редко, а из-за такой оптимизации вы получаете существенный прирост в производительности вашей программы нахаляву.
В четвёртой задаче я рассуждал, что ничего не мешает создать свой класс
class java.lang.Integer implements Iterable
и загрузить кастомным класслоадером. Ну или в bootstrap classpath подсунуть. Нет?Да, спасибо.
> почти двукратное «торможение» параллельных стримов
970 против 806 — это почти двукратное? У вас одна итерация существенно быстрее. Явно процессор другой. Возможно, с улучшенной хардварной поддержкой криптографии. Можно усложнить функцию и посмотреть, что получится. Ну и количество ядер хотя бы указывайте. Вряд ли меньше четырёх, но мало ли.