All streams
Search
Write a publication
Pull to refresh
632
0
Тагир Валеев @tagir_valeev

Программист

Send message
Так нечего было им пользоваться :-) Понятно, что такие шибко хакерские вещи, которые прямо скажем ломают джаву изнутри, сами очень хрупкие.
потому что на стабильной 2017.3.5 не поддерживается этот language level.

Если я правильно помню, там был более хитрый алгоритм: надо просто написать var x = "foo", а когда подсветит красным, там есть квик-фикс на нём. Так-то в 2017.3 у нас уже всё работало. Но вообще да, проще на 2018.1 уже перейти.

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

TECO сам себе IDE! Можно прямо в нём писать TECO-программы, тут же выполнять и отлаживать, не выходя наружу и не запуская внешние процессы.

Если в контракте написано, что "метод add добавляет элемент, а метод addAll добавляет все элементы", то базовый класс волен поменять реализацию и использовать, либо не использовать add внутри addAll, этим он контракт не нарушает.

Нарушил контракт наследник: переопределил метод, делая помимо добавления элемента дополнительную логику, не предусмотренную контрактом (оповещение слушателей).
Как-то совершенно случайно получилось, что древняя виртуалка с Кубунтой была под рукой. Так-то я вообще виндузятник :D
Я думаю, какой-нибудь jlink проще научить обновлять байткод в таких ситуациях. Все же пользуются jlink начиная с Java 9 ;-)
Не все клиенты вашего класса могут быть вам доступны. А если доступны все и всегда (у вас не библиотека, а приложение, которое не подразумевает сторонних плагинов), то необходимость выделения виджета без нотификаций вызывает ещё больше вопросов. Ключевой принцип ООП — инкапсуляция. В том числе она означает, что пока существующий класс сохраняет свой контракт, приложение не должно ломаться. Добавление нового метода или изменение реализации 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-то тут при чём? Основную работу делает собственно фабрика, генерируя цепочку методхэндлов, которые сперва считают суммарную длину всех строк, затем выделяют один массив точно нужного размера и всовывают его в строку через небезопасный конструктор.

Ёлки, что-то столько классных докладов заявлено, разрываться придётся…
Я один заметил, что на титульном слайде не весь экран опечатка — hitchKiker вместо hitchhiker? Если да, то мне приз!

Если вам специалньо нужно подержать переменную, для этого есть специальный API-метод Reference.reachabilityFence(). Нужен он в реальной жизни исключительно редко, а из-за такой оптимизации вы получаете существенный прирост в производительности вашей программы нахаляву.

Ну да, через bootstrap можно и java.lang.Class подменить, тогда все четыре варианта будут возможны :D

В четвёртой задаче я рассуждал, что ничего не мешает создать свой класс class java.lang.Integer implements Iterable и загрузить кастомным класслоадером. Ну или в bootstrap classpath подсунуть. Нет?

Я бы в резюме явно написал «контрибутил в такие-то и такие-то проекты, список моих коммитов в этих проектах вот по ссылке». Разумеется, выбрав только наиболее значительные и релевантные планируемому месту работы, чтобы сэкономить время потенциальному работодателю.
Вы думаете, обычный AOT-компилятор вам будет выдавать код одинаковой производительности на разный профиль? Вы компилируете с использованием рантайм-профиля?
> И, кстати, в вызов метода checkIndex передавать надо, наверное, index:

Да, спасибо.

> почти двукратное «торможение» параллельных стримов

970 против 806 — это почти двукратное? У вас одна итерация существенно быстрее. Явно процессор другой. Возможно, с улучшенной хардварной поддержкой криптографии. Можно усложнить функцию и посмотреть, что получится. Ну и количество ядер хотя бы указывайте. Вряд ли меньше четырёх, но мало ли.

Information

Rating
Does not participate
Location
Новосибирск, Новосибирская обл., Россия
Registered
Activity