Комментарии 83
Т.е. то, что будет в Java 9 и делается для Java 10 — не считается? Или, быть может, вы считаете, что в OpenJDK Оракл почти не контрибьютит?
Ни в одном современном языке не приходиться писать:
balance.setSaldoOut(balance.getSaldoIn().add(balance.getNach()).subtract(balance.getPayment()));
вместо простого и понятного:
balance.saldoOut = balance.saldoIn + balance.nach - balance.payment;
Дополнительно из-за отсутствия сахара для свойств в java, в случая любых ограничений (not null/not negative) на поля приходиться постоянно использовать get/set
Оператор "==", типы в коллекциях java иммеет много больных мест и при нынешнем ходе развития они никогда не исправяться и не будут исправляться, чтобы не ломать совместимость.
balance.recountSaldoOut();
и реализовываться так:
public recountSaldoOut(){
saldoOut = saldoIn + nach - payment;
}
public recountSaldoOut(){
saldoOut = saldoIn.add(nach).subtract(payment);
}
Плюс подобное работает только если работаем с одним объектом. Если входных объектов несколько и есть еще выходной, то данный подход не сработает.
Так писать на Java не получиться
Ну это зависит от типа saldoIn, nach и payment.
Если входных объектов несколько и есть еще выходной, то данный подход не сработает
Почему? Можно ведь всегда указать зависимости, в том числе функциональные, на пример так:
public getSaldoOut(nach, payment){
return saldoIn.add(nach.getValue() - payment.getPaid());
}
public boolean isZero(BigDecimal val) {
return BigDecimal.ZERO.compareTo(val) == 0;
}
return val.signum() ==0;
Добавлю, что объекты все равно создаются. А запись ссылки в переменную — не overhead (не факт что будет). И в более сложных случаях можно сделать запись в несколько строк, давая осмысленные имена получаемым сущностям.
Но syntax sugar все же удобен.
Но syntax sugar все же удобен
Проблема syntax sugar в том, что он делает кривую обучения более крутой. Для понимания работы кода, необходимо понимать не только базовые операторы языка, но и особенности реализации «сахара».
Это особенно заметно в проектах, без стандартизации формата кода и с большим числом разработчиков. Кодовая база быстро делится на блоки, с которыми работают только те разработчики, которые знакомы с используемым в этом блоке «сахаром». На практике это выглядит примерно так: «в проект пришел джун, запилил реализацию на каком нибудь модном сахаре, после чего покинул проект, и реализацию либо переписали, либо все бояться ее трогать».
В целом вопрос не был бы столь болезненным, если всего для одного! стандартного класса определили бы арифметические операции.
На понимание, что в отличие от других языков здесь надо складывать через add(), а не через + уходит как бы не больше времени
Повторюсь: это зависит от типа. Если вы работаете с примитивами, они прекрасно поддаются сложению с использованием математических операторов, но если вы пишете свой тип (класс), то придерживайтесь объектной нотации — операции над объектами это методы. Любой разработчик на java это понимает сразу. На понимание смеси процедурного и объектно-ориентированного кода уходит больше времени просто потому, что это два подхода, а не один, что, априори, требует больше знаний.
В целом вопрос не был бы столь болезненным, если всего для одного! стандартного класса определили бы арифметические операции.
Возможность перегрузки математических операторов спорна, так как применима далеко не к любому типу чисто семантически, а методы, в свою очередь, позволяют отразить операцию максимально приближенно семантически к домену.
А именно для этого стандартного класса нет удобного способа работы. В итоге приходиться писать все арифметические операции словами.
Т.е. я прописываю классу атрибут Controller, кардинально меняю его поведение, считай, наследуюсь от другого класса и это все вписывается в объектно-ориентированную нотацию?
Если вы привыкли к математическим операторам и процедурному подходу, возможно вам стоит использовать язык, который под это лучше заточен, а не Java, которая является объектно-ориентированным языком.
К тому же совершенно не понятно, почему для базовой сущности нельзя сделать исключение. Как ниже заметили для строки же это сделали.
В чем примущество отсуствия сахара?
Диабетики не страдают.
Кроме непосредственно Джавы есть ещё jvm, на которой работает ещё куча языков с кучей фич. Код на этих языках можно положить прямо в тот же проект, что и код на джаве. Так что те, кто желает сахара — без проблем могут его получить.
Того же JPA несчастного
А что там не так то? Цепляем обычный драйвер, поверх накатываем ORM by Hibernate. Все, не паримся, «оно работает».
что мой запрос не нужно будет полностью переделывать в случае перехода на другую ORM.
Не, если у вас это не сфероконные вопросы/ситуации, а вот прям реально на горизонте указанно, что «скоро будем менять подсистему ORM с X на Y», тогда да, возможно этим вопросом надо так же озадачиться.
Однако, на моей памяти не было такого, что по непонятным причинам меняется сама ORM. Во-вторых, сама ORM нужна для чего? Чтобы можно было безболезненно менять саму type-of-database (скажем типично с MySQL на PostgreSQL). То, что вам при этом можно без любых правок менять саму ORM — никто и нигде не обещает (ибо в требования к ORM вообще ни разу не входит).
P.S. Я в своих суждениях отталкиваюсь именно от интересов бизнеса, а не от академических «а что, если...». Ибо постановка ситуации мне видится притянутой за уши.
Так что кейс вполне реальный D:
чем планировали при постановке ТЗ.
В моем мире это означает «раз заказчик ТЗ нарушил, то вот ему штраф, и, что еще приятней — я могу забить на сроки» — волос не теряем. К тому же, ну как-то странно, на мой взгляд гибер будет де-факто-стандарт.
Впрочем то, что вы смогли решить задачу, это делает вам честь безусловно. С этим я согласен.
Что касается авторизации — а в чем проблема то сделать стандартными средствами? Ок, поясню — у нас два варианта входа (авторизации). Пишем один код для веба, другой для 1С. Далее, делаем простейшую единую и универсальную точку входа, уже внутри которой мы сможем определить каким маршрутом делать авторизацию. Это все справедливо, если тащить спринги нет желания (читаем как делаю свой детский велик).
UPD:
Пытается нагнуть гуголь с его j--
Он давно развивается в рамках OpenZFS под разные популярные ОС (линукс, фряха, иллюмос)
Разработчики ZFS ушли в опенсорсный illumos очень скоро после закрытия OpenSolaris. Там же и развивали, а дальше код уже остальные растащили, в том числе Linux.
А она разве использовалась достаточно широко?
С некоторых пор есть более свободная BTRFS, которая повторяет многие фичи из ZFS. Полагаю, ZFS сегодня не слишком-то нужна. Хотя году в 2009 она казалась интересной.
Zones
А напомните мне пожалуйста, Sun первыми их придумали, потом оно уже перетекло в FreeBSD Jail? Гугл что то не помог
Скорее всего наоборот. Они развили идею BSD Jails, довели ее до завершения.
Поэтому от этого Oracle лично у меня ни в голове, ни в жопе. Развались он хоть завтра, даже поностальгировать будет не о чем.
Зато сама СУБД — космос, полностью компенсирует недостатки остального Оракловского софта. :)
Oracle фактически ликвидирует Sun