JVM internals - what does the JVM do? — Ian Rogers

[Леонид Ильич Брежнев]

Не зря приходится пользоваться костылями вроде http://projectlombok.org/ (даже на коммерческих проектах).

Какой ужас.

Code: Select all

01 import lombok.AccessLevel;
02 import lombok.Getter;
03 import lombok.Setter;
04 
05 public class GetterSetterExample {
06   @Getter @Setter private int age = 10;
07   @Setter(AccessLevel.PROTECTED) private String name;
08   
09   @Override public String toString() {
10     return String.format("%s (age: %d)", name, age);
11   }
12 }

[Интеррапт]

Какой ужас.

Ну чего ужас? Костыли они и есть костыли. Для тех, кто ненавидит сотни строчек с обьявлениями getXXX и setXXX.

[crypto5]

Какой ужас.

Ну чего ужас? Костыли они и есть костыли. Для тех, кто ненавидит сотни строчек с обьявлениями getXXX и setXXX.

А почему бы просто паблик поля не использовать?

[rzen]

иногда сеттеры и геттеры помимо присвоений производят дополнительные пляски бубном, например проверяют правильность переданного значения переменной или вообще прячут тот факт что за ними переменной нет вообще, а значение возможно читается из присоединённого объекта (а этот получается как прокси). вариантов много разные. суть в том чтобы спрятать конкретику от пользователя.

[Komissar]

Не зря приходится пользоваться костылями вроде http://projectlombok.org/ (даже на коммерческих проектах).

Какой ужас.

Code: Select all

01 import lombok.AccessLevel;
02 import lombok.Getter;
03 import lombok.Setter;
04 
05 public class GetterSetterExample {
06   @Getter @Setter private int age = 10;
07   @Setter(AccessLevel.PROTECTED) private String name;
08   
09   @Override public String toString() {
10     return String.format("%s (age: %d)", name, age);
11   }
12 }

а ведь еще тов. Сталин говорил: "Красивый молдаванин этот Брежнев, только не давайте ему много говорить".

[dotcom]

алгоритмы обработки изображений на Java vs Intel IPP

Я что, кто-то это на Java пишет?

Нет, была библиотека, в том числе и на Жабе. Люди PhD защаищают, им надо на пустом месте рефераты писать. Вот и расширили распознавание образов, жестов и.т.п. на Жабе. Когда делом надо было заняться, то уже перенесли под Intel. Цель была показать прирост производительности на порядок. А получилось два порядка. В академической среде страшно любят JVM сейчас, поэтому видимо сразу не опубликовали бумагу. Чувствую, что подгоняют результаты опять.

ИМХО - кесарю-кесарево, нефиг сравнивать Java c С++, вообще. Если Java хоть немного похожа на .NET, то она интересна именно как инфраструктура - я имею в виду JVM, самодостаточные файлы классов (с метаданными), и т.д. Это всю делает её подходящей для всякого enterprisey программирования и т.д.

Я не спорю. Просто попытки навести критику и объяснить, что виртуальная машина всегда будет overhead'ом, какой стороной на нее не смотри, как ее не оптимизировать, - молодое поколение не всегда схватывает. Еще раз. Никак не хотел разводить флейм. Я больше хочу как раз разобраться в JVM. Литературы нормальной шишь. Спецификация, как и положено спецификации, можно давать на чтение заключенным Гитмо вместо water boarding'а.

А вот как язык она полностью убога. Т.е. проблема не в GC overhead (если ваше приложение так критично к этому, то нефиг вообще managed code писать), а в том, что язык слишком низкого уровня, слишком многословен. Way to go - более высокоуровневые языки для JVM.

Согласен по поводу многословности. Бяда Жабы в том, что ее делали не для того, для чего ее сейчас применяют. Язык попал под горячую руку доткома (моего родственника т.е.), когда на него начали вешать страшные фреймворки и наспех сделанные библиотеки. Хотя в самой идеи VM нет ничего плохого. Мне нравится концепция LLVM, например. Жабу туда тоже пытаются перенести, но ИМО не через то место. В старые добрые времена разбирался с p-code'ом и linked code (он же "шитый"), написал свой интерпретатор Форта на нем.

[Интеррапт]

Какой ужас.

Ну чего ужас? Костыли они и есть костыли. Для тех, кто ненавидит сотни строчек с обьявлениями getXXX и setXXX.

А почему бы просто паблик поля не использовать?

А если кто-то захочет класс экстендить и доп логику в какой-нибудть getter или setter вставить в производном классе? А что если нужны только getters? А что если хочешь работать с JPA, где нельзя просто повесить аннотации на public instance variables, т.к. все равно обязательно нужны getters/setters. А с lombok пишешь себе для JPA что-то вроде:

Code: Select all

@Entity
public @Data class Contact {
    
    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE)
    private Long id;

    private String name;

    private String email;

    private String primaryPhone;

    @OneToMany(cascade=CascadeType.ALL) 
    private Set<Task> tasks; 
}

и все, никаких getters и setters имплементировать не нужно, т.к. @Data по умолчанию сгенерит их всех. Ну или можно по отдельности генерить для каждого поля через @Getter/@Setter

И главное, что никаких run-time overhead. Плагин под maven ес-но есть. Плагины под все основные IDE (т.е. Eclipse, Netbeans, IntelliJ) тоже есть - и поэтому эти IDE спокойно себе эти аннотации видят как настоящие getters/setters у себя в autocomplete.

Костыль? Костыль. Я тоже бы предпочел, чтобы getters/setters были языковой конструкцией, как в C#. Но за неимением лучшего...

[Интеррапт]

а ведь еще тов. Сталин говорил: "Красивый молдаванин этот Брежнев, только не давайте ему много говорить".

[Palych]

Какой ужас.

Ну чего ужас? Костыли они и есть костыли. Для тех, кто ненавидит сотни строчек с обьявлениями getXXX и setXXX.

(философское отступление)
Господа, вам не напоминает эта ситуация тот эксперимент с обезьянами, которые боялись того, чего с ними никогда не происходило?
Если я правильно помню - изначально применение get/set методов оправдывалось тем, что:
- Можно сделать интерфейс;
- Можно добавит custom logic;
- Можно засинхронизировать как надо;
- Можно иметь fields, которые не будут доступны через get/set methods (для технических целей)
В наше время (когда с вредными насекомыми борются стерилизуя самцов) - кто-нибудь использует вышеперечисленные блага? Тем более что всякие frameworks/toolkits в основном генерируют такие классы из DB Structure, WSDL и проч.

Иными словами - если вас когда-нибудь в палате лордов спросят: зачем вы использовали setXXX()/getXXX() methods вместо непосредственного доступа к публичным (извиняюсь) членам - вы будете знать что ответить?

[Интеррапт]

Иными словами - если вас когда-нибудь в палате лордов спросят: зачем вы использовали setXXX()/getXXX() methods вместо непосредственного доступа к публичным (извиняюсь) членам - вы будете знать что ответить?

Выше же написали уже. Например, для того, чтобы кто-то мог отнаследовать класс и овверрайднуть ваш геттер или сеттер и добавить туда дополнительную логику. Опять же, rzen правильно выше написал, что в мире всяких технологий типа hibernate, этот самый getter вполне может быть прокси, а вот как вы такой трюк провернете с публичным (тоже извиняюсь) членом? Или, например, повесить какой-нибудь логгинг или секьюрити на доступ к ресурсу через AOP.

А вообще я на 100% согласен с Joshua Bloch:

If a class is accessible outside its package, provide accessor methods, to preserve the flexibility to change the class’s internal representation. If a public class exposes its data fields, all hope of changing its representation is lost, as client code can be distributed far and wide.
However, if a class is package-private or is a private nested class, there is nothing inherently wrong with exposing its data fields—assuming they do an adequate job of describing the abstraction provided by the class.

[Palych]

Иными словами - если вас когда-нибудь в палате лордов спросят: зачем вы использовали setXXX()/getXXX() methods вместо непосредственного доступа к публичным (извиняюсь) членам - вы будете знать что ответить?

Выше же написали уже. Например, для того, чтобы кто-то мог отнаследовать класс и овверрайднуть ваш геттер или сеттер и добавить туда дополнительную логику. Опять же, rzen правильно выше написал, что в мире всяких технологий типа hibernate, этот самый getter вполне может быть прокси, а вот как вы такой трюк провернете с публичным (тоже извиняюсь) членом? Или, например, повесить какой-нибудь логгинг или секьюрити на доступ к ресурсу через AOP.

И кто-то реально оверрайдит геттеры/сеттеры в DTO?
Разве манипуляции с такими объектами не выносятся наружу?
Про hibernate не знаю (честно говоря - надеюсь не узнать никогда), но выглядит как вполне логичный аргумент. Принимаю.
Признаю что другого пути нет кроме как колоться, давиться и имплементировать геттеры/сеттеры.

[Интеррапт]

И кто-то реально оверрайдит геттеры/сеттеры в DTO?

А разве речь только о DTO?

[rzen]

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

[Palych]

И кто-то реально оверрайдит геттеры/сеттеры в DTO?

А разве речь только о DTO?

Если сеттеры/геттеры не составляют основную часть класса - проще их воспринимать как обычные методы. Так понятнее будет.
Например, если геттер/сеттер задекларирован через жоаннотацию, а потом оверрайдится - каким образом оверрайдинг метода, который нигде не описан будет способствовать улучшению кода?

[rzen]

И кто-то реально оверрайдит геттеры/сеттеры в DTO?

А разве речь только о DTO?

Если сеттеры/геттеры не составляют основную часть класса - проще их воспринимать как обычные методы. Так понятнее будет.
Например, если геттер/сеттер задекларирован через жоаннотацию, а потом оверрайдится - каким образом оверрайдинг метода, который нигде не описан будет способствовать улучшению кода?

в ОО модели имеется четкая разница между мутаторами/акцессорами и сообщениями.

(сорри больше не буду вмешиваться )

[Zorkus]

Ох, чую, понесется сейчас.

Доля правды в этом есть. Например, по сравнению с тем же C# (если как язык сравнивать) или cо Scala (который JVM). Оба конкретно опережают Java по выразительности. К сожалению приходится признать, что Java довольно медленно эволюционирует. Не зря приходится пользоваться костылями вроде http://projectlombok.org/ (даже на коммерческих проектах).

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

[Zorkus]

Какой ужас.

Ну чего ужас? Костыли они и есть костыли. Для тех, кто ненавидит сотни строчек с обьявлениями getXXX и setXXX.

А должно быть как в груви хотя бы. Оставляешь поле без всякого модикатора видимости, компилер добавляет самому полю private, и добавляет синтетические методы. Для Java это можно тоже сделать через compile time annotations, но муторно жеж.

[Интеррапт]

Например, если геттер/сеттер задекларирован через жоаннотацию, а потом оверрайдится - каким образом оверрайдинг метода, который нигде не описан будет способствовать улучшению кода?

Как это он нигде не описан? Описан - при помощи аннотации. Мало того, все инструменты (типа того же Eclipse, Netbeans, IntelliJ) видят это именно как getter и setter, а не как какую-то аннотацию.

Вот так всегда, поделишься с людьми инструментом, которым сам пользуешься и который (с моей точки зрения) довольно полезен как syntax sugar - и тут же начинается критика

И ведь никто не критикует C# за наличие встроенных getters/setters или Objective-C за наличие @synthesize. Наоборот, это считается приятной фичей языка. Которую очень бы хотелось видеть хотя бы где-нибудь в Java 9.

[Интеррапт]

Оставляешь поле без всякого модикатора видимости, компилер добавляет самому полю private, и добавляет синтетические методы. Для Java это можно тоже сделать через compile time annotations, но муторно жеж.

Вот собственно lombok подобное и делает. А таки да - хотелось бы иметь это как часть языка.

[Palych]

Если сеттеры/геттеры не составляют основную часть класса - проще их воспринимать как обычные методы. Так понятнее будет.
Например, если геттер/сеттер задекларирован через жоаннотацию, а потом оверрайдится - каким образом оверрайдинг метода, который нигде не описан будет способствовать улучшению кода?

в ОО модели имеется четкая разница между мутаторами/акцессорами и сообщениями.
[/quote]
Метод - это вроде как сообщение, или нет?
Замена членов методами (getXX()/setXX()) - разве это не обрушивает стройную теорию?
(я извиняюсь за свою дремучесть. Я никогда не изучал ОО в университетах)

[rzen]

в ОО модели имеется четкая разница между мутаторами/акцессорами и сообщениями.

Метод - это вроде как сообщение, или нет?
Замена членов методами (getXX()/setXX()) - разве это не обрушивает стройную теорию?
(я извиняюсь за свою дремучесть. Я никогда не изучал ОО в университетах)

угу. вернее скорее наоборот, передача сообщения реализуется методом, а сеттеры/геттеры это особый случай сообщений влияющих на состояние объекта, в классическом ОО вообще то они не предусмотрены.

[crypto5]

иногда сеттеры и геттеры помимо присвоений производят дополнительные пляски бубном, например проверяют правильность переданного значения переменной или вообще прячут тот факт что за ними переменной нет вообще, а значение возможно читается из присоединённого объекта (а этот получается как прокси). вариантов много разные. суть в том чтобы спрятать конкретику от пользователя.

Ну вот я считаю что для иногда писать кучу ненужного кода это premature optimization. При необходимости можно потом отрефакторить.

[crypto5]

Какой ужас.

Ну чего ужас? Костыли они и есть костыли. Для тех, кто ненавидит сотни строчек с обьявлениями getXXX и setXXX.

А почему бы просто паблик поля не использовать?

А что если хочешь работать с JPA, где нельзя просто повесить аннотации на public instance variables, т.к. все равно обязательно нужны getters/setters.

вроде не обязательно, кажется есть какой то AccessType.FIELD который говорить JPA работать с филдами а не с accessor-ами

[crypto5]

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

В IDE обычно нагенерить аксесоров - пара кликов мышки

[rzen]

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

В IDE обычно нагенерить аксесоров - пара кликов мышки

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