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