Как стать автором
Обновить

Комментарии 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;

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Ну да, еще про оператор var из C# забыли. Очень удобно писать SomeBigNameOfClass result = new SomeBigNameOfClass();

По факту тогда, в чем смысл криков про лямбды и больше новых фич в новых версиях? Все же можно через сторонние либы сделать или, как вы сказали, добавить обработку типа в JVM.
Только вот ни того ни другого в Java нет, а во всех современных языках есть.
Дополнительно из-за отсутствия сахара для свойств в java, в случая любых ограничений (not null/not negative) на поля приходиться постоянно использовать get/set
НЛО прилетело и опубликовало эту надпись здесь
Писать код вида #define true (Math.random()>0.5) все равно не запретишь. Сейчас это можно размешать внутри equals и радоваться странным результатам. Это не та проблема с которой нужно бороться.

Оператор "==", типы в коллекциях java иммеет много больных мест и при нынешнем ходе развития они никогда не исправяться и не будут исправляться, чтобы не ломать совместимость.
НЛО прилетело и опубликовало эту надпись здесь
Я понимаю, что изменить поведение "==" уже не получиться, но можно хотя бы ввести "===" на сравнение по значению. Это не ломает совместимость. В js уже так поступили.
Не дай бог. Не нужно в Java этого костыля, пусть остается в JS.
Костыль это Object.equals(a,b) не удобный в использованию и не работающий к тому же для чисел.
Метод в объектно-ориентированном языке не может быть костылем по определению ) Вот === вполне. И ради чего, чтоб Java был больше похож на JS? Да сами JS разработчики не в восторге от ==/===, а вы предлагаете его еще и перенести в язык без этого костыля. Не нужно.
В js используется == в java же он очень редкий зверь годный только для примитивов. Единообразие в синтаксисе сильно повысит читаемость. А предупреждения при компиляции помогут избегать ошибок. Можно же попросить явно аннотировать места где используется именно сравнение по ссылке.
Мне лично кажется, что при соревнованиях между скоростью разработки и православностью синтаксиса в долгосрочной перспективе при прочих равных всегда выигрывает скорость разработки. Поэтому лично мне кажется, что упарываться чистотой белой расы синтаксиса — это путь в никуда.
Почему вы пытаетесь использовать объектно-ориентурованную 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;
}
НЛО прилетело и опубликовало эту надпись здесь
Название balance уже само собой подразумевает финансы) Где альтернатив просто нет.
НЛО прилетело и опубликовало эту надпись здесь
Ксчастью вам не приходилось постоянно ковыряться в многостраничных текстах арифмитических операций, которые трудно читаемых в любых случаях чуть более отличных от тривиальных.
На самом деле, можна записать ваш код короче, использовав метод signum()
return val.signum() ==0;
Соглашусь на 80%

Добавлю, что объекты все равно создаются. А запись ссылки в переменную — не overhead (не факт что будет). И в более сложных случаях можно сделать запись в несколько строк, давая осмысленные имена получаемым сущностям.

Но syntax sugar все же удобен.
Но syntax sugar все же удобен

Проблема syntax sugar в том, что он делает кривую обучения более крутой. Для понимания работы кода, необходимо понимать не только базовые операторы языка, но и особенности реализации «сахара».

Это особенно заметно в проектах, без стандартизации формата кода и с большим числом разработчиков. Кодовая база быстро делится на блоки, с которыми работают только те разработчики, которые знакомы с используемым в этом блоке «сахаром». На практике это выглядит примерно так: «в проект пришел джун, запилил реализацию на каком нибудь модном сахаре, после чего покинул проект, и реализацию либо переписали, либо все бояться ее трогать».
На изучение возможностей сахара требуется ничтожное количество времени. Вот чтобы изучить, сконфигурировать и настроить простейший сервер, требуется на порядки больше времени и усилий, чем на изучения скажем множественного возврата.
Это от человека зависит, сколько ему времени требуется для изучения сахара, а если это группа человек, то времени требуется еще больше, и все для того, чтобы джуниор мог попробовать в проекте новый «сахар». Такая себе плата за «сахар», заменяющий add() на +
На понимание, что в отличие от других языков здесь надо складывать через add(), а не через + уходит как бы не больше времени.

В целом вопрос не был бы столь болезненным, если всего для одного! стандартного класса определили бы арифметические операции.
На понимание, что в отличие от других языков здесь надо складывать через add(), а не через + уходит как бы не больше времени

Повторюсь: это зависит от типа. Если вы работаете с примитивами, они прекрасно поддаются сложению с использованием математических операторов, но если вы пишете свой тип (класс), то придерживайтесь объектной нотации — операции над объектами это методы. Любой разработчик на java это понимает сразу. На понимание смеси процедурного и объектно-ориентированного кода уходит больше времени просто потому, что это два подхода, а не один, что, априори, требует больше знаний.

В целом вопрос не был бы столь болезненным, если всего для одного! стандартного класса определили бы арифметические операции.

Возможность перегрузки математических операторов спорна, так как применима далеко не к любому типу чисто семантически, а методы, в свою очередь, позволяют отразить операцию максимально приближенно семантически к домену.
Вся боль, что так как Java это в первую очередь финансовые системы, а все расчеты для них ведутся через стандартный BigDecimal. Работать с остальными примитивами нельзя.
А именно для этого стандартного класса нет удобного способа работы. В итоге приходиться писать все арифметические операции словами.
Потому я вам сразу и сказал: работая с объектно-ориентированным языком, придерживайтесь объектно-ориентированной нотации. Математические операторы это не объектно-ориентированная нотация, потому ее и нет в Java.
А аттрибуты?
Что «аттрибуты»?
Аттрибуты вписываются в концепцию объектно-ориентированная нотации?
Если они инкапсулированы. По сути, атрибуты (я предпочитаю термин — свойства) не видны снаружи, потому их семантически не существует, вы оперируете объектами и методами, а не переменными, данными и операциями над ними. В этом и отличие объектной нотации от процедурной.

Т.е. я прописываю классу атрибут Controller, кардинально меняю его поведение, считай, наследуюсь от другого класса и это все вписывается в объектно-ориентированную нотацию?

Вы под атрибутом понимаете «аннотацию» или «метаданные»? Если так, то это уже не объектно-ориентированная нотация, а декларативная.
Вместо того, чтобы решить проблему, вы предлогаете постоянно бороться с плохим дизайном языка, не предусмотревшем арифметических операций.
Почему вы решили, что если у другого ЯПа непривычный для вас дизайн, то это плохой дизайн? Вы давно занимаетесь разработкой? Вы знакомы более чем с 1 ЯПом?

Если вы привыкли к математическим операторам и процедурному подходу, возможно вам стоит использовать язык, который под это лучше заточен, а не Java, которая является объектно-ориентированным языком.
Я из хожу из простого наблюдения, что один и тот же код написаный на js и на java. Читаем на стороне фронта, а вот на стороне сервера вызывает затруднения. К сожалению просто поменять язык сервера нельзя.
К тому же совершенно не понятно, почему для базовой сущности нельзя сделать исключение. Как ниже заметили для строки же это сделали.
К сожалению просто поменять язык сервера нельзя.

Ну согласитесь, что если вам тяжело читать 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
Android не «перешёл на Котлин», а теперь поддерживает ещё и Котлин.
Извиняюсь за неточную формулировку. Добавил поддержку, камушек в огород Java :)
в огород Java, которая является основой для Котлин?

Пытается нагнуть гуголь с его j--

А архитектура SPARC? Это же большой кусок истории (да и сейчас например Fujitsu делает спарки)
Это в Co, т.к. Solaris на x86 был, но все-таки больше для SPARC. Большой кусок истории — да, но сам Оракл не видит как это сейчас можно продавать.

Он давно развивается в рамках OpenZFS под разные популярные ОС (линукс, фряха, иллюмос)

Разработчики ZFS ушли в опенсорсный illumos очень скоро после закрытия OpenSolaris. Там же и развивали, а дальше код уже остальные растащили, в том числе Linux.

А она разве использовалась достаточно широко?
С некоторых пор есть более свободная BTRFS, которая повторяет многие фичи из ZFS. Полагаю, ZFS сегодня не слишком-то нужна. Хотя году в 2009 она казалась интересной.

ZFS — старая проверенная ФС (в целом, линукс-реализация молода и не всё поддерживает, насколько я помню), а вот BTRFS пока еще очень молодая, все её тестируют только, а воз и ныне там.
Ввиду недавнего решения Red Hat будущее BTRFS уже слегка как бы под вопросом. Посмотрим. Надеюсь выживет и будет развиваться, альтернативы и здоровая конкуренция — это классно.
Нет. SUSE и далее продолжит развивать и поддерживать BTRFS, а решения RH ничего не решают.
image
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, на мой взгляд, только один нормальный продукт — это собственно их СУБД и кластерное ПО для неё (Solaris не считаю, т.к. это их продукт, пришедший извне). Всё остальное, что доводилось администрировать, требует недюжинной выдержки и постоянного копания в десятках разрозненных конфигов и мутных мануалах.
Зато сама СУБД — космос, полностью компенсирует недостатки остального Оракловского софта. :)
Эх, поднажать бы ещё на Postgre. И забудут все про Oracle.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории