Подготовка первого стабильного выпуска языка программирования Rust (http://www.rust-lang.org), развиваемого проектом Mozilla, выходит на финишную прямую - бета-выпуск Rust 1.0 ознаменовал (http://blog.rust-lang.org/2015/04/03/Rust-1.0-beta.html) полную стабилизацию программных интерфейсов всех библиотек и языковых конструкций. Обращение ко всем компонентам API, которые признаны нестабильными, в бета выпуске и релизе будет приводить к выводу ошибки, для использования экспериментальных возможностей отныне следует использовать ночные сборки или явно разрешить данные возможности на этапе сборки. Релиз запланирован на 15 мая.
Основной причиной подготовки Rust 1.0 является желание стабилизировать язык и сделать его пригодным для использования в реальных проектах. В процессе подготовки ветки Rust 1.0 программные интерфейсы и возможности языка подверглись значительной ревизии, после которой по умолчания оставлены (http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html) только полностью готовые к применению возможности, реализация которых не будет изменяться в дальнейшем. Все остальные функции переведены в разряд экспериментальных и вынесены из поставки по умолчанию. Таким образом каждый следующий за Rust 1.0 стабильный выпуск будет полностью обратно совместим с предыдущим и будет гарантировать неизменность API. По мере доведения до готовности экспериментальные возможности будут стабилизироваться и включаться в основные выпуски.
Язык Rust развивается проектом Mozilla и сфокусирован на безопасной работе с памятью и обеспечении высокого параллелизма выполнения заданий (возможность порождать тысячи и даже миллионы подпроцессов). Исходные тексты проекта распространяются (https://github.com/mozilla/rust/) под лицензией MIT. Параллельно с Rust совместно с компанией Samsung развивается экспериментальный браузерный движок Servo (http://www.opennet.me/opennews/art.shtml?num=36576), написанный (https://github.com/servo/servo/) на языке Rust и отличающийся поддержкой многопоточного рендеринга web-страниц и распараллеливанием операций с DOM (Document Object Model).По структуре язык Rust напоминает C++, но существенно отличается в некоторых деталях реализации синтаксиса и семантики, а также ориентацией на блочную организацию структуры кода, которая позволяет реализовать задачи в виде легковесных сопрограмм. Автоматическое управление памятью избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Rust поддерживает смесь императивных процедурных и объектно-ориентированных методов с такими парадигмами, как функциональное программирование и модель акторов, а также обобщённое программирование и метапрограммирование, в статических и динамических стилях.
URL: http://blog.rust-lang.org/2015/04/03/Rust-1.0-beta.html
Новость: http://www.opennet.me/opennews/art.shtml?num=41975
>а также ориентацией на блочную организацию структуры кода, которая позволяет реализовать задачи в виде легковесных сопрограммот этого давно отказались в пользу обычных тредов
Они тоже уже полгода как отказались. Автор новости - слоупок.
Но вот утверждение, что корутинам вообще всегда предпочитают обычные треды - это враки, нанодесу.
Java с AOT заруливает эту хрень :)
уже сделали минимальный рантайм чтобы в виде бандла распространять можно было и не заставлять пользователя ставить JRE?
Уже лет пять как
Где почитать про это?
Возможность была с шестёрки (ЕМНИП, можно было и до этого, но были лицензионные заморочки). В архиве с JRE шёл файлик с лицензией и описанием того, как расковырять и сделать кастомный билд. Для ленивых: http://resources.ej-technologies.com/install4j/help/doc/help....В семёрке в рамках первых попыток запилить Jigsaw провели большую реструктуризацию, но ей и ограничились. Впрочем размер "базового", сильно урезанного комплекта сократили в разы.
Последние достижения были оформлены в рамках 8 (всё это уже было готово в 7, но нужно же создавать видимость работы): http://openjdk.java.net/jeps/161. Также добавили в сам JDK тулзу для ленивых: https://docs.oracle.com/javase/8/docs/technotes/tools/window....
В декабре прошлого года завершили распиливание напильником отдельных пакетов (попутно окончательно разосравшись с OSGi и придумав новый формат файлов метаданных). Однозначтно будет в девятке: http://openjdk.java.net/projects/jigsaw/doc/jdk-modularizati....
ОМГ10 мб - минимальный рантайм??
океюшки...
и че? А теперь посчитай весь рантайм какогонить приложения на Qt.
> и че? А теперь посчитай весь рантайм какогонить приложения на Qt.Ну и то. Для разнообразия посчитаем рантайм программы на си, собранной c -nostdlib, да? Ах, он равен нулю? Ну вот чем-то таким они и отличаются: на сях так можно, а на яве...
> Также добавили в сам JDK тулзу для ленивыхммм.
Для ленивых - это когда я например просто добавляю ключ при компиляции:javac .... --bundle=compact1
> javac --- A new command-line option will be defined to specify the intended target Profile. It will be a compile-time error for source code being compiled to reference APIs outside of that Profile.
они уже это запилили или нет?
ну все нормальные люди используют gradle на крайняк maven но ни кто не юзает javac в ручную.... если у вас конечно не хеллолуролд
ЩИТО? Даже title этой страницы однозначно говорит о чём речь -- modularization.Project Jigsaw: JDK modularization
То есть, разбиение по модулям самой jdk.
Самая первая ссылка которую вы кинули -- это проприетарная контора которая судя по всему пакует обычную jre. Вставляет в ваши exe-шники делая установку jre плохо видимой для обычного юзверя. Вот, например, гляньте раздел "лицензирования": http://resources.ej-technologies.com/install4j/help/doc/inde...
Если что, я сам сейчас деньги получаю за написание кода под JVM (язык Scala). Но врать не стоит в любом случае...
> Java с AOT заруливает эту хрень :)а java многословность никуда не делась.
Для тех, кому не нравится многословность есть Xtend. Замечательная вещь. Попробуйте. Я доволен как слон :) Транслируется в читаемый java-код. Жаль только мало популярен, но авторы в данный момент усиленно пыхтя пилят плагин для IDEA после чего надеюсь оно пойдёт на взлёт.
Зачем, если есть Groovy?
Зачем молоко когда есть борщь? Ну вот не разбираетесь в вопросе но суетесь с комментариями.
Если года три назад это был борщ, то сейчас — полный стол блюд:* Статическая _или_ динамическая компиляция на выбор
* Доступ к AST на всех возможных уровнях — хочешь городи AOT, хочешь — генерируй байткод, а можно и сразу гнать исходники, всё это с поддержкой локальных и глобальных преобразований
* Возможность использовать всё это с жабными процессорами аннотаций при помощи генерации т.н. Java Stubs.Зачём теперь вообще другие самопальные языки поверх JVM, ну вот объясните?
> Зачем, если есть Groovy?это который сейчас на кладбище apache проектов лежит, тухнет.
> с возможностями Python, Ruby и Smalltalk.
скрестили разные ЯП, ну и получили гермофродита в итоге.
хочется такого лаконичного ЯП как python. но со строгой типизацией и компиляцией в полноценный java-байткод. чтобы такая же производительность как у java была.
> хочется такого лаконичного ЯП как python. но со строгой типизацией и компиляцией
> в полноценный java-байткод. чтобы такая же производительность как у java была.
оно только недавно начало шивелится опять, но думаю это не на долго версию p3k они не осилят
> хочется такого лаконичного ЯП как python. но со строгой типизацией и компиляцией
> в полноценный java-байткод. чтобы такая же производительность как у java была.И главное чтобы он сам еще программы писал :)
> Для тех, кому не нравится многословность есть Xtend. Замечательная вещь. Попробуйте. Я
> доволен как слон :) Транслируется в читаемый java-код. Жаль только мало
> популярен, но авторы в данный момент усиленно пыхтя пилят плагин для
> IDEA после чего надеюсь оно пойдёт на взлёт.- не нашел где есть утилита для использования из командной строки.
он только как плагин к эклипсу чтоли идет - привязка к IDE это жирный минус.- не намного уменьшает читабельность. static void public final - остаются
> - не намного уменьшает читабельность. static void public final - остаютсяВ сях все это можно переопределить ;). Хоть sv пишите вместо static void, так можно :).
>> - не намного уменьшает читабельность. static void public final - остаются
> В сях все это можно переопределить ;). Хоть sv пишите вместо static
> void, так можно :)."static void public final" более читабельно чем "sv", "pv", "xv" и т.п. "hzv"
если же проблема в увеличении скорости написания
- это легко решается через https://www.jetbrains.com/idea/help/live-templates.html
> - не нашел где есть утилита для использования из командной строки.
> он только как плагин к эклипсу чтоли идет - привязка к IDE
> это жирный минус.Изначально он был привязан к еклипсу это да, и то что это жирный минус все понимают, поэтому он и малопопулярен. Но с тех пор уже появились плагины для maven и gradle, а грубо говоря что ещё надо? Так что про командную строку я не понял, видимо у Вас какой - то совсем экзотический юзкейс... Про плагин для IDEA я упоминал, что его как раз сейчас активно пилят забив на все другие фичи, потому что да, все понимают про минус одной, уже не доминирующей IDE..
> - не намного уменьшает читабельность. static void public final - остаются
Ну да, точно так же как for, if, равно, плюс минус и прочие слова и конструкции языка. А как без них? Как мне сказать что у меня static без использования слова static? Не понимаю.. Где что могли - вроде всё повыкидывали... Вывод типов есть, расширения, лямбды были задолго до 8й джавы и аналог builder'ов из груви. Этого уже хватает чтобы сократить количество кода раз в пять если не десять. К тому же есть что-то типа макросов. В общем всё то, чтобы хотелось иметь в обычной java.
Не путайтесь, это не ещё один язык для JVM, это DSL для java. Никаких новых возможностей оно не вносит, всё это можно сделать и на чистой java, только получится очень многа букаф, а эта штука как раз и пишет их за Вас. Изначально я отвечал на замечание о многословности java, которую этот иструмент по - моему мнению успешно побеждает. Я пользуюсь и радуюсь, но на выхлопе чистая java, в этом есть свои плюсы и нюансы. А груви и скала это уже всё-таки другие языки, а это не совсем тоже самое.
Сравнил горячее с зелёным.
А что насчёт задержек от сборщика мусора?
А когда это в Java успели сделать семантику одалживания-и-владения? :-)
Делают что-то схожее в Checker Framework, но там скорее база. Сама семантика должна реализовываться отдельным инструментом на его основе. Да и сам Checker пока сыроват даже на потрогать.
Зачем нужен Rust если есть Ди?
Дык... вестимо зачем - для неосиляторов С/C++. Им видите-ли сложно offset по указателю посчитать, все время бедняжки за границу выходят. А еще после того как покакают в штан^W в память, забывают подтеретьс^W очистить ее. Вот и нужна этим детям мамочк^W GC, который их обкаканые штанишки менять будет.
в Rust нет GC, только опциональный подсчет ссылок
Ну в Go есть, разница то, блин.
Главное, что мнение имеешь - подробности фигня :)
Ну давай разберем по порядку тобой написанное.
> Им видите-ли сложно offset по указателю посчитать, все время бедняжки за границу выходят.Ошибки делают абсолютно все. Если ты думаешь, что ты их не делаешь, то у тебя проблемы. Это хорошо, когда язык защищает от части ошибок.
> А еще после того как покакают в штан^W в память, забывают подтеретьс^W очистить ее.В С++ так не делают. См. RAII.
> Вот и нужна этим детям мамочк^W GCВ расте нет GC. Там используется тот же самый RAII.
> В С++ так не делают. См. RAII.Т.е. в декструкторе не надо delete вызывать? А если я пишу на С++ без классов, но использую перегрузку функций (потому и С++, а не Си).
Ну и потом... если я создал объект класса динамически через "new", то кто за меня delete вызовет? Пушкин? Или может Google?
Известно кто -- shared_ptr .. Если только нет циклических ссылок :-)
> Т.е. в декструкторе не надо delete вызывать?Нет. Деструкторы unique_ptr, shared_ptr, string и контейнеров уже написаны и сами вызовутся из деструктора твоего класса.
Иногда нужно освобождать какие-то другие ресурсы. Но один раз написать это в специально предназначенной для этого функции – это не то же самое, что писать delete по всему коду для каждого объекта. Вероятность ошибки сводится к минимуму, и найти такую ошибку проще.> А если я пишу на С++ без классов, но использую перегрузку функций (потому и С++, а
> не Си).Нельзя считать недостатком языка то, что ты по известным тебе одному причинам не пользуешься его возможностями. И нет, "С++ без классов" - это не С++.
> Ну и потом... если я создал объект класса динамически через "new", то
> кто за меня delete вызовет?См. выше про unique_ptr, shared_ptr, string и контейнеры. Кроме того, начиная с С++14 ты _вообще_ не создаешь объекты через new, т.к. там появилась функция make_unique.
> Нет. Деструкторы unique_ptr, shared_ptr, string и контейнеров уже написаны и сами вызовутся из деструктора твоего классаЭто всё шаблоны-обертки из boost`а (перекочевавшие в стандарт), в операторе присваивания которого просто счетчик указателей инкрементируется и декрементируется в деструкторе. Под капотом все тот же new/delete.
Я знаю, лол. И что с того? Пользователям языка больше не нужно руками работать с памятью.
> Я знаю, лол. И что с того? Пользователям языка больше не нужно руками работать с памятью.В С++ можно так писать что не нужно руками работать. Читать надо умные книги, эффективные техники программирования на С++ уже сто лет как известны нам, но похоже не вам.
o_O
Просвети.Есть класс Геометрические фигуры, от него унаследованы классы Круг, Треугольник, Квадрат.
Создаём L1 из геометрических фигур.
Нужно:
1. реализовать единый метод Нарисовать() без хранения переменной типа геометрической фигуры внутри класса
2. реализовать корректное освобождение памяти при вызове delete
> Просвети.
> Есть класс Геометрические фигуры, от него унаследованы классы Круг, Треугольник, Квадрат.Ещё для разнообразия: Точка, Окружность, Эллипс, Многоугольник.
Это не шутка. Меня в какое-то время надоело бодаться с ООП, которое якобы что-то там должно упрощать, но вместо этого задалбывает синтаксисом сильнее, чем облегчает работу. В итоге я вернулся к функциональному программированию с С++'овым синтаксисом.Тут чувак корчит из себя эксперта, может он знает решение.
По факту получается, что невозможно реализовать Нарисовать() не храня тип фигуры. А хранение типа фигуры ставит крест на всяком наследовании, ибо нахрена козе баян и ручное жонглирование классами, когда можно тупо создать файл НарисоватьФигуру.cpp и запихать в него всё рисование, а в НарисоватьФигуру.h уйдут все макроопределения. В ООП то же самое будет разбросано (как после взрыва) по десятку файлов в каждом из которых по 2-5 строчек кода.
И зачем мне деструктор класса, если я должен сам хранить какого он типа и преобразовывать тип к правильному лишь чтобы вызвался правильный деструктор, когда я могу сразу запихать всё это в switch.
Хранить тип Строка в классе лишь чтобы не забыть в конце освободить память - я амнезией не страдаю. А там где страдаю (как в примере выше), там мне ООП ничем не помогает.
Как был код команда-условие-переход, таковым он и остался. А всякие MMX, лямбда-функции, квантовые вычисления, ООП (в большинстве случаев) и пр. - попытки поиграть в игру "сломай мозг" и не более того.
> И зачем мне деструктор класса, если я должен сам хранить какого он
> типа и преобразовывать тип к правильному лишь чтобы вызвался правильный деструктор,
> когда я могу сразу запихать всё это в switch.
Когда речь о переменных, это работает, т.к. компилятор отслеживает человеческую глупость. Когда речь об L1 - нет, т.к. никакой дополнительной информации о типе класса при выделении памяти компилятор не добавляет и следовательно тип класса при удалении не знает.
> никакой дополнительной информации о типе класса
> при выделении памяти компилятор не добавляет
> и следовательно тип класса при удалении не знает.Effective C++ item 7: Declare destructors virtual in polymorphic base classes
Reference: “Effective C++” Third Edition by Scott Meyers.
Понимаешь в чем прелесть С++ - эти шаблоны опциональны и по сути своей реализации являются просто wrapper'ом надо new/delete. Хочешь - руками работай с памятью, не хочешь - юзай shared_ptr. Более того любой С++ программист знакомый с С++ больше года и знающий что можно перегружать operator=, легко сам такой shared_ptr напишет.
Во-первых, у меня уже сомнения в том, что ты напишешь полноценный shared_ptr, и даже в том, что ты нормально знаешь его устройство. Но речь не о том.
Напомню, речь шла о том, что якобы в С++ надо писать delete, а неосиляторы забывают. Потом я сказал, что хорошие погромисты в хороших программах на С++ не пишут delete вообще. Что ты хотел сказать своим комментарием применительно к исходному топику?
> Во-первых, у меня уже сомнения в том, что ты напишешь полноценный shared_ptr,
> и даже в том, что ты нормально знаешь его устройство. Но
> речь не о том.
> Напомню, речь шла о том, что якобы в С++ надо писать delete,
> а неосиляторы забывают. Потом я сказал, что хорошие погромисты в хороших
> программах на С++ не пишут delete вообще. Что ты хотел сказать
> своим комментарием применительно к исходному топику?Раньше я как-то писал, а теперь разучился что ли? Ты ведь полюбому и сам знаешь принцип работы shared_ptr, так сказать, на моллекулярном уровне, и явно понимаешь, что я лишь написал самый базовый принцип его работы основанный на инкрементированнии счетчика и присвании указателя в перегруженном operator=? А потом я ниже тебе ответил, что И РАНЬШЕ не надо было руками работать с памятью, а достаточно было лишь один раз реализовать свой собственный аналог shared_ptr (ну не было тогда boost). То, что за тебя кто-то в бусте обернул new/delete в шаблон, не означает что ручное управление памятью куда-то делось, он просто скрыто под одеялом.
Я это собственно к тому, что и раньше не надо было руками работать - написал один раз класс-шаблон со приватным членом-счетчиком ссылок и инкрементируешь его в operator=. Это техника известна хер знает сколько лет и, как я выше уже писал, любой С++ программист ее всегда применял. Но для всяких недопрограммистов на Rust и особенно на Go, это видимо какая-то инопланетная магия. Так что твоё "теперь не надо руками работать" - мимо, никогда не надо было, если один раз сделать. Такими тенденциями как в Go и Rust через лет 5 ручное управление памятью станет в разряд эдакого супер-пупер-хардко-профи скиллом, хотя это ваще тривиальнейшая вещь, которой нас еще в школе обучали.
Сам чего-то придумал – сам поговорил. Ок.
Так я не понял -- что тебе надо от языка? Работа с памятью напрямую, или возможность избежать работы с памятью напрямую при помощи всяких костылей?
> Так я не понял -- что тебе надо от языка? Работа с
> памятью напрямую, или возможность избежать работы с памятью напрямую при помощи
> всяких костылей?И то и другое. Хорошо когда инструмент гибкий.
>> Так я не понял -- что тебе надо от языка? Работа с
>> памятью напрямую, или возможность избежать работы с памятью напрямую при помощи
>> всяких костылей?
> И то и другое. Хорошо когда инструмент гибкий.Тогда твоим выбором должен быть rust.
> Тогда твоим выбором должен быть rust.Странно, мой выбор ни у кого не занимал.
>> Тогда твоим выбором должен быть rust.
> Странно, мой выбор ни у кого не занимал.Что в этом странного? Обычно занимает?
> Т.е. в декструкторе не надо delete вызывать?Послушай, ну, если ты настолько суров, что даже в деструкторе не вызываешь delete, то попрограммируй пока на Бейсике.
Пожалуйста, позвольте мне не вызывать в деструкторе delete, если конструктор у меня ничего в кучу не аллоцирует. Можно?
Дык, осиляторов в живой природе пока никто не наблюдал, в комментах разве что...
> Дык, осиляторов в живой природе пока никто не наблюдал, в комментах разве что...Я наблюдал.
> Я наблюдал.Что они написали?
>> Я наблюдал.
> Что они написали?Компиляторы и линкеры пишут, которыми потом неосиляторы свой код компилят/линкуют.
Вечно дырявая JRE тому подтверждение.
Я наблюдал как команда писала ядро проекта на С++ и код был очень ровным. Вот тогда меня и научили "вменяемому" программированию на С++ и научили ненавидеть Java :)
От жабки мало кто в восторге, но это не делает плюсокодеров сверхлюдьми, они ошибаются, как и все остальные, постоянные фиксы уязвимостей в тех же браузерах тому доказательство.
Сверхлюди тоже не идеальны и бывает, что ошибаются, Таков уж мир.
На Java ругаются только дети-максималисты, в жизни не писавшие вещей сложнее университетских лаб, это если еще профильное образование имеется, а то и вообще Hello, world - предел. Вменяемые люди знают отличительные черты профессиональных инструментов и умеют пользоваться ими к месту.
Проблема в том, что жабка (точнее - весь стек J2EE) на своём месте в проектах такой величины, которых не так уж много. А в более мелких её практики - суровый оверкилл. Биллинг опсоса на ней написать - да, нормально. А небольшой application server или движок веб-приложения - хочется взять что-нибудь, где соотношение "количество смысла/количество строк" получше.
> Проблема в том, что жабка (точнее - весь стек J2EE) на своём
> месте в проектах такой величины, которых не так уж много.
> А в более мелких её практики - суровый оверкилл. Биллинг опсоса
> на ней написать - да, нормально. А небольшой application server или
> движок веб-приложения - хочется взять что-нибудь, где соотношение
> "количество смысла/количество строк" получше.Java EE уже не нужен,
http://projects.spring.io/spring-framework/ подходит для проектов практически любой сложности,
если хочется в начале не тратить много времени на конфигурирование приложения - тогда http://projects.spring.io/spring-boot/ - здесь "количество смысла/количество строк" будет максимальным.
Вполне возможно. Я, в общем-то, говорил о том, откуда пошли традиции писать на джаве, а потом на плюсах громоздкий код. Если появилось что-то вменяемое - прекрасно, теперь бы оно стало ещё мейнстримом... Хотя как по мне - джава всё равно крайне некомфортный язык. Те же get/put в коллекциях, к примеру.
> Вполне возможно. Я, в общем-то, говорил о том, откуда пошли традиции писать
> на джаве, а потом на плюсах громоздкий код. Если появилось что-то
> вменяемое - прекрасно, теперь бы оно стало ещё мейнстримом...Spring Framework уже давно популярнее Java EE во многих областях,
Spring Boot они активно пиарят и продвигают на своем сайте и конференциях.> Хотя как по мне - джава всё равно крайне некомфортный язык.
> Те же get/put в коллекциях, к примеру.С другой стороны - будет ли комфортно писать и читать программу,
в которой используется много различных библиотек и каждая из этих
библиотек по своему перегружает арифметические операторы ?
Ок, спринг стал мейнстримом. Учту. Если ещё Hybernate заменяется чем-то менее монструозным - вообще сочту, что чудо случилось. Но накопленные традиции и привычки всё делать, как будто пишешь пакет на сто миллионов строк - укоренились крепко, это и по вашим ответам видно.По перегрузке - так не берите неудобные библиотеки. Собственно, по причине неудобства те, кто персетарался с перегрузкой, уже повымирали (лет пятнадцать назад). Арифметику сейчас никто не перегружает без нужды. А вот не дать возможности сделать нормальное индексирование или сравнение - это скотство, по-моему. Я вообще в этом плане предпочитаю подход D - пользовательский тип должен иметь возможность сделать абсолютно всё, что делает встроенный в язык. Это, во-первых, сильно упрощает обобщённое программирование, а во-вторых позволяет легко заменить в любой момент в приложении встроенный тип на что-то более подходящее для данного случая. А вот как будут выглядеть на джаве вычисления в 256-битовых целых, буде понадобится - мне и представлять не хочется.
> Ок, спринг стал мейнстримом. Учту.По крайней мере, в рунете на Java-конференциях про спринг говорят очень много,
а про Java EE - практически ничего. В других частях света может быть ситуация иная.> Если ещё Hybernate заменяется чем-то менее монструозным
> - вообще сочту, что чудо случилось.Есть несколько реализаций интерфейса Java Persistence API,
Hibernate - это только одна из таких реализаций.Кстати, в презентации https://www.youtube.com/watch?v=YzOTZTt-PR0
рассказывается для каких проектов от Hibernate / JPA будет
больше вреда, чем пользы, начиная с #t=48m15sЕсли не ограничивать себя рамками Hibernate
- есть много других способов работы с базой данных,
например, спринговый JdbcTemplate или http://jdbi.org/ или вообще,
голый JDBC, если надо выжать из базы данных максимум производительности:
http://samolisov.blogspot.com/2014/01/dao-jdbc-spring-framew...> По перегрузке - так не берите неудобные библиотеки.
Иногда библиотеки пишутся своими силами. И если язык не будет ничем
и никак ограничивать полет творческой мысли - там могут написать такого...Вот например, Perl - очень удобный язык, 5-й версии и особенно 6-й,
ничем и никак программиста не ограничивает. Писать на таком языке очень удобно.
А читать потом написанный код на перле? А ведь там полная свобода самовыражения.> Арифметику сейчас никто не перегружает без нужды. А вот не дать возможности
> сделать нормальное индексирование или сравнение - это скотство, по-моему.Это минимализм. Такой же подход, который был применен и при создании UNIX.
Реализовывать только то что необходимо без лишнего синтаксического сахара.Интерфейс
https://docs.oracle.com/javase/7/docs/api/java/util/Collecti...
или
https://docs.oracle.com/javase/7/docs/api/java/util/Map.html
не выглядит сложным или неудобным.И если используем метод из интерфейса - можно быть уверенным,
что он делает именно то, что написано в описании интерфейса.> А вот как будут выглядеть на джаве вычисления
> в 256-битовых целых, буде понадобится - мне и представлять не хочется.Строить программу и модель прикладной области на таких понятиях,
как "256-битовые целые" - это изначальная ошибка в архитектуре программы.ООП подразумевает, что будут использоваться более высокоуровневые понятия,
а детали реализации будут скрыты внутри класса и интересны только его разработчикам.
>> Ок, спринг стал мейнстримом. Учту.
> По крайней мере, в рунете на Java-конференциях про спринг говорят очень много,
> а про Java EE - практически ничего. В других частях света может быть ситуация иная.То же самое: про GNU/Linux (Git) "вони" больше, чем по Windows (Mercurial), хотя, казалось бы, должно быть наоборот. Почему? Всё дело в (НЕ)ОЧЕВИДНОСТИ тех или иных ситуаций с точки зрения практического применения.
Java EE — это стандарт и масса реализаций ("хуже-лучше", "быстрее-медленнее"). Spring — это частичная неполная реализация элементов Java EE и собственные суб-фреймворки, заменяющие стандартные реализации там, где это видится разработчиками более подходящим и востребованным.
>>> Ок, спринг стал мейнстримом. Учту.
>> По крайней мере, в рунете на Java-конференциях про спринг говорят очень много,
>> а про Java EE - практически ничего. В других частях света может быть ситуация иная.
> То же самое: про GNU/Linux (Git) "вони" больше, чем по Windows (Mercurial),
> хотя, казалось бы, должно быть наоборот. Почему? Всё дело в (НЕ)ОЧЕВИДНОСТИ
> тех или иных ситуаций с точки зрения практического применения.Git - более популярная система, чем Mercurial, поэтому про него говорят больше.
Аналогично и Linux / Windows.Если через http://www.google.com/ncr погуглить "Linux"
и "Windows", то будут такие результаты:Результатов: примерно 455 000 000 - Linux
Результатов: примерно 2 280 000 000 - WindowsАналогичные результаты получаются и по Git / Mercurial:
Результатов: примерно 220 000 000 - Git
Результатов: примерно 27 000 000 - Mercurial> Java EE — это стандарт и масса реализаций
"масса" - это две, если брать Java EE 7 Web Profile Compatible Implementations
и аж четыре разных для Java EE 7 Full Platform Compatible Implementations,
две из которых малоизвестны, то есть по факту получается только так же - две.то есть на деле эта "масса реализаций" выливается только в то,
что силы тратятся впустую на создание конкурирующих решений.Чем-то это напоминает ситуацию с операционными системами,
Linux - всего одна система, которая развивается очень быстро,
BSD - раздробилась на много мелких систем, которые конкурируют между собой.> Spring — это частичная неполная реализация элементов Java EE
> и собственные суб-фреймворки, заменяющие стандартные реализации там,
> где это видится разработчиками более подходящим и востребованным.То же самое можно сказать и про Linux, сравнивая его с UNIX Compatible Implementations.
Которых тоже было масса реализаций ("хуже-лучше", "быстрее-медленнее").
>[оверквотинг удален]
>>> а про Java EE - практически ничего. В других частях света может быть ситуация иная.
>> То же самое: про GNU/Linux (Git) "вони" больше, чем по Windows (Mercurial),
>> хотя, казалось бы, должно быть наоборот. Почему? Всё дело в (НЕ)ОЧЕВИДНОСТИ
>> тех или иных ситуаций с точки зрения практического применения.
> Git - более популярная система, чем Mercurial, поэтому про него говорят больше.
> Аналогично и Linux / Windows.
> Если через http://www.google.com/ncr погуглить "Linux"
> и "Windows", то будут такие результаты:
> Результатов: примерно 455 000 000 - Linux
> Результатов: примерно 2 280 000 000 - WindowsРазница — 5 раз.
> Аналогичные результаты получаются и по Git / Mercurial:
> Результатов: примерно 220 000 000 - Git
> Результатов: примерно 27 000 000 - MercurialРазница — 8 раз.
>> Java EE — это стандарт и масса реализаций
> "масса" - это две, если брать Java EE 7 Web Profile Compatible
> Implementations
> и аж четыре разных для Java EE 7 Full Platform Compatible Implementations,
> две из которых малоизвестны, то есть по факту получается только так же
> - две.
> то есть на деле эта "масса реализаций" выливается только в то,
> что силы тратятся впустую на создание конкурирующих решений.На деле создаются два решения на одной общей спецификации: эталонное (и медленное) открытое и быстроее (масштабируемое) закрытое, соответствующее эталонной реализации.
> Чем-то это напоминает ситуацию с операционными системами,
> Linux - всего одна система, которая развивается очень быстро,
> BSD - раздробилась на много мелких систем, которые конкурируют между собой.Мне не напоминает, потому что FreeBSD, например, вырождается в GNU/FreeBSD. А Linux без системы приложений GNU — только ядро и чего-то там "конкурировать" с целостной системой не способно в принципе.
> То же самое можно сказать и про Linux, сравнивая его с UNIX
> Compatible Implementations.
> Которых тоже было масса реализаций ("хуже-лучше", "быстрее-медленнее").Как правило, в последние годы "мы это уже проходили" и "зачем множить сущности".
>>> Java EE — это стандарт и масса реализаций
>> то есть на деле эта "масса реализаций" выливается только в то,
>> что силы тратятся впустую на создание конкурирующих решений.
> На деле создаются два решения на одной общей спецификации: эталонное (и медленное)
> открытое и быстроее (масштабируемое) закрытое, соответствующее эталонной реализации.То есть, основная цель создания Java EE была одна - зарабатывать деньги.
Демо-версия - берите бесплатно, а полноценная версия - уже надо платить.Spring - это open source, имеет всего одну версию для платных и бесплатных
пользователей, а деньги зарабатывает не продажей лицензий (как майкрософт)
а продажей поддержки (как Red Hat) - это более честный и справедливый вариант.>> Чем-то это напоминает ситуацию с операционными системами,
>> Linux - всего одна система, которая развивается очень быстро,
>> BSD - раздробилась на много мелких систем, которые конкурируют между собой.
> Мне не напоминает, потому что FreeBSD, например, вырождается в GNU/FreeBSD.Да ладно, они наоборот, вытесняют из своей системы все что было под лицензией GPL
и замещают proprietary-friendly лицензиями, например, вот - gcc меняют на clang.> А Linux без системы приложений GNU — только ядро
когда говорится Linux при сравнении с FreeBSD - подразумевается GNU/Linux.
и даже более точно говоря, - GNU/Linux CentOS 7.1 или GNU/Linux RHEL 7.1
- это есть очень даже целостная система от одного вендора, как и FreeBSD.>> То же самое можно сказать и про Linux,
>> сравнивая его с UNIX Compatible Implementations.
>> Которых тоже было масса реализаций ("хуже-лучше", "быстрее-медленнее").
> Как правило, в последние годы "мы это уже проходили"
> и "зачем множить сущности".Они всеравно множатся: https://en.wikipedia.org/wiki/List_of_BSD_operating_systems
И это только те, которые выложены в открытый доступ, а ведь есть еще десятки,
если не сотни проприетарных операционных систем созданных на базе BSD,
тут же и различные макоси и даже виндовс (TCP/IP стек первых версий).А отличие - только лишь в лицензии. У Linux она оказалась более удачной.
> Java EE уже не нужен,Смело. Вы Java EE 7 смотрели?
http://habrahabr.ru/company/piter/blog/229213/
> http://projects.spring.io/spring-framework/ подходит для проектов практически любой сложности,А Spring какую спецификацию, по-вашему, реализует?!
>> Java EE уже не нужен,
> Смело.Я пока что не нашел ни одной задачи, которую нельзя решить с помощью спринга.
Также не понимаю в чем и где Java EE лучше за Spring. Кроме того случая,
когда есть древний проект написанный на Java EE и его надо поддерживать.> Вы Java EE 7 смотрели?
> http://habrahabr.ru/company/piter/blog/229213/"научитесь обращаться с веб-службами SOAP" - без комментариев.
"исследуете и научитесь использовать API EJB и JPA — от компонентов-сущностей, компонентов-сеансов до компонентов, управляемых сообщениями, и многого другого"
- про EJB 2.1 много уже написано и сказано,
а про JPA - есть очень хорошая презентация
https://www.youtube.com/watch?v=YzOTZTt-PR0
Николай Алименков — Босиком по граблям Hibernate
- рекомендую.>> http://projects.spring.io/spring-framework/
>> подходит для проектов практически любой сложности,
> А Spring какую спецификацию, по-вашему, реализует?!Ставить знак равенства между спрингом и Java EE - это слишком.
чтобы долго не рассказывать:
http://www.slideshare.net/reza_rahman/java-ee-and-spring-sid...
3 и 4 слайды.
>>> Java EE уже не нужен,
>> Смело.
> Я пока что не нашел ни одной задачи, которую нельзя решить с
> помощью спринга.
> Также не понимаю в чем и где Java EE лучше за Spring.В унификации и стандартизации.
> Кроме того случая, когда есть древний проект написанный на Java EE и его надо поддерживать.
Java EE 7 это далеко не J2EE.
>> Вы Java EE 7 смотрели?
>> http://habrahabr.ru/company/piter/blog/229213/
> "научитесь обращаться с веб-службами SOAP" - без комментариев.SOAP уже отменили?
> "исследуете и научитесь использовать API EJB и JPA — от компонентов-сущностей, компонентов-сеансов
> до компонентов, управляемых сообщениями, и многого другого"Это учебник.
> - про EJB 2.1 много уже написано и сказано,
Сейчас актуальны EJB 3.2 как бы.
> а про JPA - есть очень хорошая презентация
> https://www.youtube.com/watch?v=YzOTZTt-PR0
> Николай Алименков — Босиком по граблям Hibernate
> - рекомендую.В видео нет JPA, а рассказ ведётся на примере Hibernate. Hibernate == JPA 1.0 - 2006 год.
JPA 2.1 (2013 год) из Java EE 7 привносит доступ к хранимым процедурам. А новый Criteria API позволяет делать запросы не только на выборку, но и на пакетное обновление и удаление.
Наконец, описание схемы базы данных и единиц хранения в persistence.xml.>>> http://projects.spring.io/spring-framework/
>>> подходит для проектов практически любой сложности,
>> А Spring какую спецификацию, по-вашему, реализует?!
> Ставить знак равенства между спрингом и Java EE - это слишком.Вот и я говорю: Spring лишь частично реализует спецификацию Java EE, остальное делает по-своему, нестандартным образом. И чем дальше, тем быстрее отстаёт от мейнстрима.
>> Также не понимаю в чем и где Java EE лучше за Spring.
> В унификации и стандартизации.Каким образом это поможет в решении практических задач,
если в спинге можно сделать все то же самое что и в Java EEПритом, более удобным и быстрым способом и без необходимости
покупать коммерческую реализацию Java EE от какого-либо вендора?Маркетологи могут разумеется рассказать о преимуществах унификации
и стандартизации, а какая от этих высоких материй практическая польза?> Java EE 7 это далеко не J2EE.
Даже Java EE 8 отстает от спринга.
>>> Вы Java EE 7 смотрели?
>>> http://habrahabr.ru/company/piter/blog/229213/
>> "научитесь обращаться с веб-службами SOAP" - без комментариев.
> SOAP уже отменили?SOAP и WS-* используется только в legacy software.
Оно морально устаревшее, очень кривое и жутко монстрообразное:
https://en.wikipedia.org/wiki/List_of_web_service_specificat...>> про EJB 2.1 много уже написано и сказано,
> Сейчас актуальны EJB 3.2 как бы.Если вспомнить историю, то спринг появился в ответ на то, что кривым
и глючным Java EE было невозможно нормально пользоваться, потому что
получилось так, что "астронавты архитектуры" там такого понапридумывали,
что "мыши плакали, кололись, но продолжали жрать кактус". Хотя такой вариант
развития устроил не всех и тогда появился спринг.EJB 3.x - это попытка исправить свои ошибки EJB 2.1
с оглядкой на то, что у спринга все получилось намного лучше.>> а про JPA - есть очень хорошая презентация
>> https://www.youtube.com/watch?v=YzOTZTt-PR0
>> Николай Алименков — Босиком по граблям Hibernate
>> - рекомендую.
> В видео нет JPA, а рассказ ведётся на примере Hibernate.
> Hibernate == JPA 1.0 - 2006 год.Зачем вы говорите неправду?
Hibernate ORM 4.3.0 Final == Java Persistence API 2.1
Причем, Hibernate - это такая же реакция на кривой Java EE как и спринг:
Hibernate was started in 2001 by Gavin King with colleagues from Cirrus Technologies as an alternative to using EJB2-style entity beans. Its original goal was to offer better persistence capabilities than offered by EJB2 by simplifying the complexities and supplementing missing features.
Когда астронавты архитектуры поняли что у Hibernate получилось лучше, чем в Java EE,
они начали эту самую Hibernate и стандартизировать в виде JPA.> JPA 2.1 (2013 год) из Java EE 7 привносит доступ к хранимым
> процедурам. А новый Criteria API позволяет делать запросы не только на
> выборку, но и на пакетное обновление и удаление.
> Наконец, описание схемы базы данных и единиц хранения в persistence.xml.Ну и чем это отличается от Hibernate? который JPA 2.1 поддерживает полностью.
https://www.youtube.com/watch?v=YzOTZTt-PR0
Николай Алименков — Босиком по граблям Hibernate- хоть и написано "Hibernate", но разве в "JPA 2.1" не все то же самое?
>>> А Spring какую спецификацию, по-вашему, реализует?!
>> Ставить знак равенства между спрингом и Java EE - это слишком.
> Вот и я говорю: Spring лишь частично реализует спецификацию Java EE,
> остальное делает по-своему, нестандартным образом.Спринг многое, практически все релизует способом лучшим, чем Java EE.
После того как пройдет несколько итераций в попытке догнать спринг -
более-менее нормальные и ставшие стабильными варианты спецификаций
начинают дополнительно поддерживаться и в спринге.Менять в спинге то, что изначально было лучше на более кривой вариант смысла нет.
> И чем дальше, тем быстрее отстаёт от мейнстрима.
???
Все время было и есть наоборот, Java EE пыталось догнать спринг.
Вот и Java EE 8 не стало исключением - там еще только собираются
делать SR 371 - Model-View-Controller 1.0 и JSR 375 - Java EE Security API 1.0
а в спринге это уже давно реализовано: Spring MVC и Spring Security.Spring - это гораздо больше, чем Java EE: https://spring.io/projects
и в то же время, проще и удобнее в использовании.
>>> Также не понимаю в чем и где Java EE лучше за Spring.
>> В унификации и стандартизации.
> Каким образом это поможет в решении практических задач,
> если в спинге можно сделать все то же самое что и в
> Java EEЕсть стандарт — есть заменяемые разработчики. Нет стандарта — есть зависимость решения от конкретного разработчика. Spring нестандартен, а значит всё с ним связанное будет на совести конкретного нанятого разработчика. Он уйдёт, компания вынуждена будет всё переписывать или нанимать такого же "гуру".
> Притом, более удобным и быстрым способом и без необходимости
> покупать коммерческую реализацию Java EE от какого-либо вендора?Существуют бесплатные сертифицированные на полную совместимость с Java EE 7 решений. Это Oracle Glassfish (эталонная реализация) и Red Hat WildFly (бывший JBoss). Кроме этого, коммерческие решения в чём-то могут превосходить бесплатные, например, в высокой масштабируемости и нагрузочной способности, что на деле окажется выгоднее бесплатных решений.
> Маркетологи могут разумеется рассказать о преимуществах унификации
> и стандартизации, а какая от этих высоких материй практическая польза?
> Даже Java EE 8 отстает от спринга.В чём конкретно?
>>>> Вы Java EE 7 смотрели?
>>>> http://habrahabr.ru/company/piter/blog/229213/
>>> "научитесь обращаться с веб-службами SOAP" - без комментариев.
>> SOAP уже отменили?
> SOAP и WS-* используется только в legacy software.
> Оно морально устаревшее, очень кривое и жутко монстрообразное:
> https://en.wikipedia.org/wiki/List_of_web_service_specificat...Частное мнение и только. Знаю, в моде сейчас JAX-RS.
>>> про EJB 2.1 много уже написано и сказано,
>> Сейчас актуальны EJB 3.2 как бы.
> Если вспомнить историю, то спринг появился в ответ на то, что кривым
> и глючным Java EE было невозможно нормально пользоваться, потому что
> получилось так, что "астронавты архитектуры" там такого понапридумывали,
> что "мыши плакали, кололись, но продолжали жрать кактус". Хотя такой вариант
> развития устроил не всех и тогда появился спринг.Spring появился как ответ на монструозный J2EE на Java 2.0 v.1.4.x. Всё. К выходу Java EE 6 его задача была исчерпана.
> EJB 3.x - это попытка исправить свои ошибки EJB 2.1
> с оглядкой на то, что у спринга все получилось намного лучше.Так в чём лучше-то?!
>>> а про JPA - есть очень хорошая презентация
>>> https://www.youtube.com/watch?v=YzOTZTt-PR0
>>> Николай Алименков — Босиком по граблям Hibernate
>>> - рекомендую.
>> В видео нет JPA, а рассказ ведётся на примере Hibernate.
>> Hibernate == JPA 1.0 - 2006 год.
> Зачем вы говорите неправду?
> Hibernate ORM 4.3.0 Final == Java Persistence API 2.1Затем, что Sun Microsystems выбрала EclipseLink в качестве эталонной реализации JPA 2.0 в Java EE 6, а не Hibernate - http://www.eclipse.org/org/press-release/20080317_Eclipselin...
2008 год!> Причем, Hibernate - это такая же реакция на кривой Java EE как
> и спринг:Согласен. Но нужно кому-то быть первым, а не лучшим.
>> JPA 2.1 (2013 год) из Java EE 7 привносит доступ к хранимым
>> процедурам. А новый Criteria API позволяет делать запросы не только на
>> выборку, но и на пакетное обновление и удаление.
>> Наконец, описание схемы базы данных и единиц хранения в persistence.xml.
> Ну и чем это отличается от Hibernate? который JPA 2.1 поддерживает полностью.Тем, что в стандартной Java EE более быстрая и эффективная реализация от TopLink/Eclipse.
>> И чем дальше, тем быстрее отстаёт от мейнстрима.
> ???
> Все время было и есть наоборот, Java EE пыталось догнать спринг.
> Вот и Java EE 8 не стало исключением - там еще только
> собираются
> делать SR 371 - Model-View-Controller 1.0 и JSR 375 - Java EE
> Security API 1.0
> а в спринге это уже давно реализовано: Spring MVC и Spring Security.Так попытайтесь соответствать со своим Spring спецификации JSR.
> Spring - это гораздо больше, чем Java EE: https://spring.io/projects
> и в то же время, проще и удобнее в использовании.Так пользуйтесь на здоровье. Делайте vendor lock-in на себя и живите незаменимым.
> Есть стандарт — есть заменяемые разработчики. Нет стандарта — есть зависимость
> решения от конкретного разработчика. Spring нестандартен, а значит всё с ним
> связанное будет на совести конкретного нанятого разработчика. Он уйдёт, компания вынуждена
> будет всё переписывать или нанимать такого же "гуру".Спринг сейчас более популярен, чем Java EE, и разработчиков,
которые знают/умеют спринг больше, чем разработчиков которые знают Java EE.
Хотя у Java EE есть один плюс - это независимость от конкретной реализации.> Существуют бесплатные сертифицированные на полную совместимость с Java EE 7 решений.
> Это Oracle Glassfish (эталонная реализация) и Red Hat WildFly (бывший JBoss).Как может быть Red Hat WildFly сертифицирован на полную совместимость с Java EE 7,
если он использует внутри себя редхатовскую же Hibernate, которая по вашим словам JPA 1.0 - 2006 год?> Кроме этого, коммерческие решения в чём-то могут превосходить бесплатные, например, в высокой
> масштабируемости и нагрузочной способности, что на деле окажется выгоднее бесплатных решений.Обычно для высокого масштабирования и нагрузочной способности надо подальше держаться
от готовых "коробочных" решений. Как пример - Netflix или Одноклассники.ру - ни там ни там
не используется коммерческая реализация Java EE и вообще какая-либо Java EE, насколько я знаю.>> Маркетологи могут разумеется рассказать о преимуществах унификации
>> и стандартизации, а какая от этих высоких материй практическая польза?
>> Даже Java EE 8 отстает от спринга.
> В чём конкретно?Я уже отвечал на этот вопрос, презентация
http://www.slideshare.net/reza_rahman/java-ee-and-spring-sid...
слайды на страницах 3 и 4.Например, Spring MVC - очень удобная штука, в Java EE такого нет.
REST Template, Spring Security, Spring Testing - в Java EE такого тоже нет.С тестированием EJB и прочего Java EE возникают очень большие проблемы,
а в спринге это все делается элементарно, потому что компоненты - это обычные POJO,
так что не особо напрягаясь можно на 100% покрыть юнит-тестами даже очень сложный код.>>> SOAP уже отменили?
>> SOAP и WS-* используется только в legacy software.
>> Оно морально устаревшее, очень кривое и жутко монстрообразное:
>> https://en.wikipedia.org/wiki/List_of_web_service_specificat...
> Частное мнение и только. Знаю, в моде сейчас JAX-RS.Да, через несколько лет в Java EE наверное появится что-то похожее на Spring MVC.
> Spring появился как ответ на монструозный J2EE на Java 2.0 v.1.4.x. Всё.
> К выходу Java EE 6 его задача была исчерпана.Java EE содержит менее 50% тех возможностей, что есть сейчас в спринге: https://spring.io/projects
>> EJB 3.x - это попытка исправить свои ошибки EJB 2.1
>> с оглядкой на то, что у спринга все получилось намного лучше.
> Так в чём лучше-то?!В том что не нужны монстрообразные сервера приложений,
и для нормальной работы достаточно Java SE + Spring.Spring Boot - это вообще крутая штука, на выходе получается один jar-файл,
который можно просто взять и запустить, без каких-либо дополнительных танцев с бубном.Для популярных и модных ныне микросервисов - это самое то, что надо.
Тем более, что спринговцы пошли еще дальше и уже делают http://projects.spring.io/spring-cloud/>> Spring - это гораздо больше, чем Java EE: https://spring.io/projects
>> и в то же время, проще и удобнее в использовании.
> Так пользуйтесь на здоровье. Делайте vendor lock-in на себя и живите незаменимым.При чем тут "vendor lock-in на себя" - программистов, которые знают спринг очень много.
И подозреваю, что в рунете - это более популярная платформа чем Java EE - по крайней мере,
именно такой вывод можно сделать по основным Java-конференциям, там говорят в основном про спринг.Насколько я понимаю, Java EE - это более медленно развивающаяся платформа,
единственным плюсом которой является наличие нескольких реализаций от разных вендоров.
Кому-то это может быть важно, чтобы иметь возможность легко менять вендора для Java EE.Спринг - более быстро развивающаяся платформа с большими возможностями,
у которой есть единственный минус - "vendor lock-in" на единственную реализацию.
В остальном эти две платформы или полностью идентичны или сравнимы по возможностям.Так?
> Спринг сейчас более популярен, чем Java EE, и разработчиков,
> которые знают/умеют спринг больше, чем разработчиков которые знают Java EE.
> Хотя у Java EE есть один плюс - это независимость от конкретной
> реализации.
>> Существуют бесплатные сертифицированные на полную совместимость с Java EE 7 решений.
>> Это Oracle Glassfish (эталонная реализация) и Red Hat WildFly (бывший JBoss).
> Как может быть Red Hat WildFly сертифицирован на полную совместимость с Java
> EE 7,
> если он использует внутри себя редхатовскую же Hibernate, которая по вашим словам
> JPA 1.0 - 2006 год?Так ведь в 2014-2015 году версия Hibernate в WildFly подросла и позволила пройти сертификацию на соответствие JPA 2.1 в Java EE 7.
Spring-фан, очевидно, не принял во внимание прогресс разработки альтернативной реализации. Он же весь в себе, для него время застыло на JavaEE5/6.>> Кроме этого, коммерческие решения в чём-то могут превосходить бесплатные, например, в высокой
>> масштабируемости и нагрузочной способности, что на деле окажется выгоднее бесплатных решений.
> Обычно для высокого масштабирования и нагрузочной способности надо подальше держаться
> от готовых "коробочных" решений. Как пример - Netflix или Одноклассники.ру - ни
> там ни там
> не используется коммерческая реализация Java EE и вообще какая-либо Java EE, насколько
> я знаю.Значит IBM и Oracle зря берут деньги у телекомов — давно пора прикрывать лавочки и заниматься, например, рыбалкой или сёрфингом.
>>> Маркетологи могут разумеется рассказать о преимуществах унификации
>>> и стандартизации, а какая от этих высоких материй практическая польза?
>>> Даже Java EE 8 отстает от спринга.
>> В чём конкретно?
> Я уже отвечал на этот вопрос, презентация
> http://www.slideshare.net/reza_rahman/java-ee-and-spring-sid...
> слайды на страницах 3 и 4.Не понял, честно.
> Например, Spring MVC - очень удобная штука, в Java EE такого нет.
А JSF на что?
Spring MVC: https://netbeans.org/kb/docs/web/quickstart-webapps-spring_r...
JSF: https://netbeans.org/kb/docs/web/jsf20-intro_ru.html
> REST Template, Spring Security, Spring Testing - в Java EE такого тоже нет.Потому что в Java EE 7 есть другое, более стандартизованное. К примеру, полная интеграция CDI в JSF 2.2 сделал часть пакетов последнего устаревшими, видоизменив обработку запросов. Но Spring-бои об этом не догадываются.
> Spring Security
///---
Вы можете использовать программную авторизацию, чтобы выборочно разрешать или блокировать доступ к роли или принципалу. Это становится возможно потому, что у вас есть прямой доступ к интерфейсу JAAS java.security.Principal , а также к контексту EJB, что позволяет проверить роль принципала в коде.
---///> С тестированием EJB и прочего Java EE возникают очень большие проблемы,
В какой версии?
> а в спринге это все делается элементарно, потому что компоненты - это обычные POJO,
> так что не особо напрягаясь можно на 100% покрыть юнит-тестами даже очень сложный код.Дааа? Можно подумать, что POJO — это исключительная фича Spring'а. :))
> Да, через несколько лет в Java EE наверное появится что-то похожее на Spring MVC.
Оно уже там под другим названием — JSF. Полезно хотя бы иногда интересоваться "параллельными" технологиями.
>> Spring появился как ответ на монструозный J2EE на Java 2.0 v.1.4.x. Всё.
>> К выходу Java EE 6 его задача была исчерпана.
> Java EE содержит менее 50% тех возможностей, что есть сейчас в спринге:
> https://spring.io/projectsВерю. Честно-честно. Ведь Spring используют все, а Java EE — единицы (маргиналы). :))
>>> EJB 3.x - это попытка исправить свои ошибки EJB 2.1
>>> с оглядкой на то, что у спринга все получилось намного лучше.
>> Так в чём лучше-то?!
> В том что не нужны монстрообразные сервера приложений,
> и для нормальной работы достаточно Java SE + Spring.Что насчёт масштабируемости, множества виртуальных серверов и отказоустойчивости?
> Spring Boot - это вообще крутая штука, на выходе получается один jar-файл,
> который можно просто взять и запустить, без каких-либо дополнительных танцев с бубном.Я тоже могу на Tomcat собрать Java EE 7 приложение с сервером. И просто запустить из командной строки. Но от этого оно не станет промышленного уровня.
> Для популярных и модных ныне микросервисов - это самое то, что надо.
> Тем более, что спринговцы пошли еще дальше и уже делают http://projects.spring.io/spring-cloud/Oracle Cloud: https://cloud.oracle.com/home
Red Hat Cloud: https://www.openshift.com/products
IBM Cloud: http://www-01.ibm.com/software/websphere/products/applicatio...>>> Spring - это гораздо больше, чем Java EE: https://spring.io/projects
>>> и в то же время, проще и удобнее в использовании.
>> Так пользуйтесь на здоровье. Делайте vendor lock-in на себя и живите незаменимым.
> При чем тут "vendor lock-in на себя" - программистов, которые знают спринг
> очень много.
> И подозреваю, что в рунете - это более популярная платформа чем Java
> EE - по крайней мере,
> именно такой вывод можно сделать по основным Java-конференциям, там говорят в основном
> про спринг.Много говорят обычно о том, что "болит".
> Насколько я понимаю, Java EE - это более медленно развивающаяся платформа,
> единственным плюсом которой является наличие нескольких реализаций от разных вендоров.
> Кому-то это может быть важно, чтобы иметь возможность легко менять вендора для
> Java EE.
> Спринг - более быстро развивающаяся платформа с большими возможностями,
> у которой есть единственный минус - "vendor lock-in" на единственную реализацию.
> В остальном эти две платформы или полностью идентичны или сравнимы по возможностям.
> Так?Несовсем.
Безусловно то, что Spring является одним из поставщиков идей и инициатором революции в Java EE. Но когда его молодой задор иссякнет, Java EE всё равно продолжит развитие, как ни крути.
> Значит IBM и Oracle зря берут деньги у телекомов — давно пора
> прикрывать лавочки и заниматься, например, рыбалкой или сёрфингом.IBM и Oracle продают железо + софт в комплекте,
так что деньги они берут не зря, а за "решения">> Spring MVC - очень удобная штука, в Java EE такого нет.
> А JSF на что?JSF has very nice way of rendering views и его можно использовать
вместе с Spring MVC вместо JSP или других технологий отрисовки view.Но Spring MVC - это гораздо более простой и универсальный инструмент,
который может все то же что и JAX-RS и даже больше,
так что в спринге отдельный JAX-RS просто не нужен.> JSF: https://netbeans.org/kb/docs/web/jsf20-intro_ru.html
Для сравнения, Spring MVC: https://spring.io/guides/gs/serving-web-content/
>> Spring Testing - в Java EE такого тоже нет.
>> С тестированием EJB и прочего Java EE возникают очень большие проблемы
> В какой версии?В любой. Как можно протестировать EJB без сервера приложений?
http://habrahabr.ru/company/luxoft/blog/246465/#comment_8191813В спринге - без проблем тестируется даже очень сложные веб-приложения
без сервера приложений, а лишь с помощью Spring MVC Test Framework.Это преимущество спринга? Да еще какое. Например, у меня на не самом быстром компе
более сотни тестов пролетало всего за 7-8 секунд через Spring MVC Test Framework.>> а в спринге это все делается элементарно, потому что компоненты - это обычные POJO,
>> так что не особо напрягаясь можно на 100% покрыть юнит-тестами даже очень сложный код.
> Дааа? Можно подумать, что POJO — это исключительная фича Spring'а. :))В спринге нет EJB и проч. прелестей Java EE, так что да,
"все есть POJO" - это просто ГРОМАДНОЕ преимущество спринга.>> Да, через несколько лет в Java EE наверное появится что-то похожее на Spring MVC.
> Оно уже там под другим названием — JSF. Полезно хотя бы иногда
> интересоваться "параллельными" технологиями.Каким образом "оно уже там", если в Java EE 8
только собираются добавить JSR 371 - Model-View-Controller 1.0 ?Причем, выглядит это как гибрид JAX-RS + 10% возможностей Spring MVC.
Как обычно версия 1.0 будет очень неудобной для использования, а до версии
3.2 может быть и дорастет до юзабельного состояния, сравнимого со Spring MVC.>> Java EE содержит менее 50% тех возможностей, что есть сейчас в спринге
> Верю. Честно-честно. Ведь Spring используют все, а Java EE — единицы (маргиналы).Спринг массово используется, а Java EE... вот что пишут:
http://java.dzone.com/articles/why-java-ee-lost-and-spring
Why Java EE Lost and Spring Won>>> Так в чём лучше-то?!
>> В том что не нужны монстрообразные сервера приложений,
>> и для нормальной работы достаточно Java SE + Spring.
> Что насчёт масштабируемости, множества виртуальных серверов и отказоустойчивости?С этим тоже все нормально, кластер из двух nginx в качестве роутера,
или аппаратный балансировщик + сколько надо backend`ов с приложением.>> Spring Boot - это вообще крутая штука, на выходе получается один jar-файл,
>> который можно просто взять и запустить, без каких-либо дополнительных танцев с бубном.
> Я тоже могу на Tomcat собрать Java EE 7 приложение с сервером.
> И просто запустить из командной строки. Но от этого оно не
> станет промышленного уровня."промышленного уровня" - в переводе на английский - "Enterprise".
Спринг уже давно Enterprise уровня и в чем-то даже лучше Java EE.> Безусловно то, что Spring является одним из поставщиков идей
> и инициатором революции в Java EE. Но когда его молодой задор
> иссякнет, Java EE всё равно продолжит развитие, как ни крути.Что-то за 12 лет совсем не наблюдается признаков иссякания спринга,
скорее уж наоборот в последнее время он демонстрирует взрывной рост.Java EE - это хорошая штука, если приходится покупать сервера у IBM или Oracle,
или писать очень большие проекты, когда важно отсутствие привязки к одному вендору.А для мелких и средних задач, особенно, когда важна скорость и удобство разработки
- похоже что спринг выигрывает у Java EE как более динамично развивающаяся платформа.
> В любой. Как можно протестировать EJB без сервера приложений?
> http://habrahabr.ru/company/luxoft/blog/246465/#comment_8191813Оригинал статьи: http://www.oracle.com/technetwork/articles/java/integrationt...
"Published September 2011">[оверквотинг удален]
> без сервера приложений, а лишь с помощью Spring MVC Test Framework.
> Это преимущество спринга? Да еще какое. Например, у меня на не самом
> быстром компе
> более сотни тестов пролетало всего за 7-8 секунд через Spring MVC Test
> Framework.
>>> а в спринге это все делается элементарно, потому что компоненты - это обычные POJO,
>>> так что не особо напрягаясь можно на 100% покрыть юнит-тестами даже очень сложный код.
>> Дааа? Можно подумать, что POJO — это исключительная фича Spring'а. :))
> В спринге нет EJB и проч. прелестей Java EE, так что да,
> "все есть POJO" - это просто ГРОМАДНОЕ преимущество спринга.Про @Test для EJB как раз написано в вышеуказанной книге. Не надо бояться изучить что-то новое.
>>> Да, через несколько лет в Java EE наверное появится что-то похожее на Spring MVC.
>> Оно уже там под другим названием — JSF. Полезно хотя бы иногда
>> интересоваться "параллельными" технологиями.
> Каким образом "оно уже там", если в Java EE 8
> только собираются добавить JSR 371 - Model-View-Controller 1.0 ?
> Причем, выглядит это как гибрид JAX-RS + 10% возможностей Spring MVC.
> Как обычно версия 1.0 будет очень неудобной для использования, а до версии
> 3.2 может быть и дорастет до юзабельного состояния, сравнимого со Spring MVC.Вот когда выйдет, тогда решим, чем это отличается от Spring MVC. Может мода на антипаттерн проектирования Model-View-Controller, наконец-то, пройдёт.
>>> Java EE содержит менее 50% тех возможностей, что есть сейчас в спринге
>> Верю. Честно-честно. Ведь Spring используют все, а Java EE — единицы (маргиналы).
> Спринг массово используется, а Java EE... вот что пишут:
> http://java.dzone.com/articles/why-java-ee-lost-and-spring
> Why Java EE Lost and Spring WonДело привычки и только. То же самое, что сидеть на J2EE/JavaEE5 десять-пятнадцать лет, потом ныть, что поддержка ВНЕЗАПНО закончилась.
>>>> Так в чём лучше-то?!
>>> В том что не нужны монстрообразные сервера приложений,
>>> и для нормальной работы достаточно Java SE + Spring.
>> Что насчёт масштабируемости, множества виртуальных серверов и отказоустойчивости?
> С этим тоже все нормально, кластер из двух nginx в качестве роутера,
> или аппаратный балансировщик + сколько надо backend`ов с приложением.То есть без сторонних решений не обойтись.
>>> Spring Boot - это вообще крутая штука, на выходе получается один jar-файл,
>>> который можно просто взять и запустить, без каких-либо дополнительных танцев с бубном.
>> Я тоже могу на Tomcat собрать Java EE 7 приложение с сервером.
>> И просто запустить из командной строки. Но от этого оно не
>> станет промышленного уровня.
> "промышленного уровня" - в переводе на английский - "Enterprise".
> Спринг уже давно Enterprise уровня и в чем-то даже лучше Java EE.Так в какой промышленности он используется?
>> Безусловно то, что Spring является одним из поставщиков идей
>> и инициатором революции в Java EE. Но когда его молодой задор
>> иссякнет, Java EE всё равно продолжит развитие, как ни крути.
> Что-то за 12 лет совсем не наблюдается признаков иссякания спринга,
> скорее уж наоборот в последнее время он демонстрирует взрывной рост.
> Java EE - это хорошая штука, если приходится покупать сервера у IBM
> или Oracle, или писать очень большие проекты, когда важно отсутствие привязки к одному вендору.Да и для "наколеночных" поделок Java EE масштабируется неплохо, так как технология модульная: хочешь, используешь только JPA с JSF (WAR), хочешь - EJB с JMS (EAR). Куча embedded-решений на сертифицированных серверах Java EE 7, не нуждающихся в поддержке сторонних костылей и фронт-эндов.
> А для мелких и средних задач, особенно, когда важна скорость и удобство
> разработки
> - похоже что спринг выигрывает у Java EE как более динамично развивающаяся
> платформа.На JSP много чего можно писать. Это ж "PHP на Java", считай. Обезьянки радуются простоте. :))
>> В любой. Как можно протестировать EJB без сервера приложений?
>> http://habrahabr.ru/company/luxoft/blog/246465/#comment_8191813
> Про @Test для EJB как раз написано в вышеуказанной книге.
> Не надо бояться изучить что-то новое.Про @Test написано и в статье на сайте
https://netbeans.org/kb/docs/javaee/javaee-entapp-junit.html
- но там всеравно запускается Embedded EJB Container, других вариантов нет.
вопрос был: как протестировать без сервера приложений? ответ: никак, это невозможно.>> Каким образом "оно уже там", если в Java EE 8
>> только собираются добавить JSR 371 - Model-View-Controller 1.0 ?
>> Причем, выглядит это как гибрид JAX-RS + 10% возможностей Spring MVC.
>> Как обычно версия 1.0 будет очень неудобной для использования, а до версии
>> 3.2 может быть и дорастет до юзабельного состояния, сравнимого со Spring MVC.
> Вот когда выйдет, тогда решим, чем это отличается от Spring MVC.JSR 371 - Model-View-Controller 1.0 можно прочитать не дожидаясь выхода Java EE 8.
> Может мода на антипаттерн проектирования Model-View-Controller, наконец-то, пройдёт.
??? :-() Почему Model-View-Controller - это антипаттерн?
>>> Что насчёт масштабируемости, множества виртуальных серверов и отказоустойчивости?
>> С этим тоже все нормально, кластер из двух nginx в качестве роутера,
>> или аппаратный балансировщик + сколько надо backend`ов с приложением.
> То есть без сторонних решений не обойтись.Если не использовать nginx - такое "масштабируемое" решение
будет легко уязвимо к DDoS и DOS атакам Slowloris и т.п.B потребует в несколько (десятков) раз больше аппаратных ресурсов
для выполнения той же работы что и в случае с использованием nginx.Хотя, если "без сторонних решений" - это может быть удобно для того,
чтобы продавать компаниям более мощные сервера и более масштабируемые Java EE решения.Но если смотреть с точки зрения клиента - ему более выгодно будет поставить
на frontend nginx или даже купить NGINX Plus и это обойдется в разы дешевле.>>> Но от этого оно не станет промышленного уровня.
>> "промышленного уровня" - в переводе на английский - "Enterprise".
>> Спринг уже давно Enterprise уровня и в чем-то даже лучше Java EE.
> Так в какой промышленности он используется?А где в промышленности используется Java EE ?
> На JSP много чего можно писать. Это ж "PHP на Java", считай.
Разработчик языка Java, Джеймс Гослинг, охарактеризовал технологию JSP, лежащую в основе JSF, как «проект-клон Microsoft ASP, который был создан, только чтобы продемонстрировать насколько сама подобная идея плоха; но модель почему-то отказалась умирать»
- https://www.youtube.com/watch?v=9ei-rbULWoAЕсли посмотреть на https://spring.io/guides/gs/serving-web-content/
- в спринге не заставляют пользоваться именно JSP, для отрисовки View
можно применять Thymeleaf, JSF и практически любую другую технологию.> Обезьянки радуются простоте. :))
Любой вменяемый человек радуется простоте. Чем проще софт - тем он надежнее.
Например, операционная система UNIX построена на тех же принципах -
минимализма и простоты интерфейсов.Для сравнения, когда оракл выкатил обновление 4.1 для своего Java EE стека,
они в этом минорном релизе 4.x -> 4.y исправили более одной тысячи багов.
Страшно даже подумать, сколько там еще багов осталось и как оно вообще
может работать и выдавать какой-то осмысленный результат при этом.
По поводу SOAP, не мог не написать. Например написали апи на нём, для передачи ограниченного набора данных между Ява приложениями - тут всё ок, но впоследствии если выясняется что теперь нужно взаимодействие с разными системами, на разных языках, да и само кол-во данных увеличилось, плюс учитывая сразу что SOAP имеет кучу разных версий, которые в разных языках, в разных библиотеках с багами, нюансами, плюс обязательный xml добавляет кучу дополнительного объёма при передаче данных... и т.п
soap это анахронизм который кое-где оставили в качестве легаси в яве, и никому кроме них и не сдавшийся в наше время.
> Я наблюдал как команда писала ядро проекта на С++ и код был
> очень ровным. Вот тогда меня и научили "вменяемому" программированию на С++
> и научили ненавидеть Java :)Ненависть была связана с обоснованным отказом от использования Java в пользу C++ или же чисто эмоциональными претензиями/отсутствием навыков программирования на Java и необходимостью его изучать/?
Архитектура сервера онлайн-игры на примере Skyforge: http://habrahabr.ru/company/mailru/blog/220359/
C++ неидеален. К сожалению, D, Rust, Go и прочие - тоже. Но то, что новые языки появляются, в любом случае хорошо, есть возможность обкатать новые идеи.
Обкатать новые идеи и добавить их в очередной стандарт C++
Нет уж, в С++ лучше ничего не добавлять. А вот если взять лучшие идеи из C, C++, Objective C, D, Go, Rust, Swift, C#, Java, Scala, Nemerle, Nim, Haxe и создать язык, который превзойдет все остальные языки программирования - это да.
> Нет уж, в С++ лучше ничего не добавлять. А вот если взять
> лучшие идеи из C, C++, Objective C, D, Go, Rust, Swift,
> C#, Java, Scala, Nemerle, Nim, Haxe и создать язык, который превзойдет
> все остальные языки программирования - это да.И назвать ++C.
Ваше высказывание выглядит примерно так: мозилловцы "ниасилили" с/с++, а потому, чтобы менял им обкаканные штанишки, запилили Rust. Мда..
судя по мейллистам, главные дишники сейчас чешут головы и обсуждают, что они сделали не так по сравнению с Го
Забыли стать мегакорпорацией и пропиариться на весь мир?
А че, D так хорош? Стоит изучать его и перейти с С++ на D ?
Ну, вон Facebook используют. Ну это они скорее всего с гуглем пискомерюются. Типа, у нас тоже есть свой язык. Но тем не менее... :)
В Facebook использует D потому, что его там использует Андрей Александреску, который на данный момент один из главных разработчиков D 2.*
Это ты Bearophil'а начитался, что ли? D с Go даже сравнивать толком не получается - языки - результат принципиально разынх подходов. D целенаправленно делался так, чтобы сохранить и приумножить всю мощь плюсов, избавившись от их недостатков. Go - чтобы получить что-то минимальное, на чём можно писать компилируемый код.
не взлетит
>А че, D так хорош? Стоит изучать его и перейти с С++ на D ?Я перешел правда с C#. Очень доволен. Обратно, а тем более на Плюсы не за что не вернусь. Теперь код так же легко как на Питоне писать, разве что либ меньше чем у самого Питона, но зато сишные либы идут на ура.
Предметная область?
>Я перешел правда с C#. Очень доволен. Обратно, а тем более на Плюсы не за что не вернусь. Теперь код так же легко как на Питоне писать, разве что либ меньше чем у самого Питона, но зато сишные либы идут на ура.C#, Python - фу, какая гадость. С++ штука отличная но нужно уметь не перегнуть палку. Но раз любители python'a в восторге от D, то я пока повременю с D.
Лучше всё же глянь. Он с питоном сравним в основном простотой писания кода и сильно более "человеческим" синтаксисом, чем у плюсов. А так - как раз для плюсовика там рай, если он не в джава-стиле привык писать с двумя дестяками уровней наследования и тяжелыми паттернами на каждом шагу.
>> и тяжелыми паттернамиЧто Вы понимаете под "тяжелыми паттернами"?
Много уровней абстракции тянут за собой более-менее стандартный набор - фабрики, медиаторы, фасады, прокси и т.п. - всё, что отвечает за то, чтобы не утонуть в громоздком коде. Как по мне - они очень замыливают глаз в плане понимания "а что мы тут, черт возьми, хотим сделать" - особенно когда тыкаются в глаза в названиях классов и методов. Туда же - запрет иметь классы-реализации без абстрактных классов, попытки конфигурировать то, что никто и никогда не будет менять, вроде используемого движка БД... Оно, насколько я опнимаю, пошло из библиотек джавы, которые, во-первых, должны быть универсальными, а во-вторых - рассчитаны на работу в раках стека Java EE, что автоматом подразумевает монструозность приложения, в-третьих - результат бедности (особенно в прошлом, когда традиция и появлялась) джавовского синтаксиса.В плюсах всегда был возможен другой стиль - когда наследование используется минимально, зато в ход идут STL, шаблоны, перегрузка, стековые объекты, сейчас еще auto добавилось - в результате в софте небольшого масштаба (скажем, на пару сот тысяч строк) можно иметь более-менее читабльный код именно в плане понимания "что делаем".
> Много уровней абстракции тянут за собой более-менее стандартный набор - фабрики, медиаторы,
> фасады, прокси и т.п. - всё, что отвечает за то, чтобы
> не утонуть в громоздком коде. Как по мне - они очень
> замыливают глаз в плане понимания "а что мы тут, черт возьми,
> хотим сделать" - особенно когда тыкаются в глаза в названиях классов
> и методов. Туда же - запрет иметь классы-реализации без абстрактных классов,
> попытки конфигурировать то, что никто и никогда не будет менять, вроде
> используемого движка БД... Оно, насколько я опнимаю, пошло из библиотек джавы,
> которые, во-первых, должны быть универсальными, а во-вторых - рассчитаны на работу
> в раках стека Java EE, что автоматом подразумевает монструозность приложения,Кроме Java EE есть и другие фреймворки, например, https://spring.io/ Там все гораздо лучше.
> В плюсах всегда был возможен другой стиль - когда наследование используется минимально,
Использование наследования вместо композиции - это вообще антипаттерн,
для Java нормальным вариантом является именно что композиция, а не наследование.
подробнее об этом написано в http://www.ozon.ru/context/detail/id/6108824/В плюсах не всегда возможен другой стиль, и это одно из тех мест, где Java
значительно лучше плюсов - в Java есть интерфейсы и есть nested классы,
так что множественное наследование не нужно вообще, интерфейсы и вложенные
классы с этим полностью справляются, причем гораздо более элегантным способом.В плюсах вообще все делается через наследование - и имплементация интерфейса
и наследование поведения, что не способствует понятности плюсовых исходников.Поскольку интерфейсы в Java оказались очень удачной идеей -
эту же идею потом реализовали и в новом гугловском языке программирования Go.
> Поскольку интерфейсы в Java оказались очень удачной идеей - эту же идею потом реализовали и в новом гугловском языке программирования Go.и не только в ге
http://wiki.freepascal.org/Interfaces
Что за бред, простите. В плюсах есть мощные шаблоны и auto, которые в подавляющем большинстве случяаев вообще избавляют от нужды в динамическом полиморфизме в пользу duck typing. Вот о мышлении "давайте для всего сделаем интерфейс" я и говорил - оно вообще не нужно в плюсах. Просто берешь и пишешь имплемиентацию. Если нужна фабрика - это шаблонный метод, ты даже не знаешь, какой тип она вернёт и тебе не требуется, чтобы он что-то наследовал - только чтобы сигнатуры методов были совместимы с вызовами. А в случае джавы - антипаттерн или нет - но придётся наследоваться лишний раз.И, разумеется, в плюсах есть вложенные классы - ещё от сишных вложенных структур пришли. Другое дело, что у них нет автоматического доступа к экземпляру клсса-владельца - надо явно отдать ссылку или указатель на него. А интерфейс от абстрактного класса вообще ничем кроме названия не отличается.
> Что за бред, простите. В плюсах есть мощные шаблоны и auto, которые
> в подавляющем большинстве случяаев вообще избавляют от нужды
> в динамическом полиморфизме в пользу duck typing. Вот о мышлении
> "давайте для всего сделаем интерфейс" я и говорил - оно вообще не нужно в плюсах.Способность видеть отличие между интерфейсом и реализацией - это плюс.
Интерфейсов в плюсах нет, вместо интерфейсов там абстрактные классы используются.
Из-за того что в плюсах вообще нет интерфейсов - там пришлось сделать
множественное наследование. Которое добавляет сразу большое количество
проблем, - виртуальные базовые классы и т.п.> Просто берешь и пишешь имплемиентацию.
Можно вообще не заморачиваться никакими паттернами
а просто брать и писать имплементацию.
И оно даже будет как-то работать.> Если нужна фабрика - это шаблонный метод, ты даже не знаешь,
> какой тип она вернёт и тебе не требуется, чтобы он что-то наследовал
> - только чтобы сигнатуры методов были совместимы с вызовами.Factory method - это только один из способов реализации фабрики.
Есть и другие, например:https://en.wikipedia.org/wiki/Abstract_factory_pattern
https://ru.wikipedia.org/wiki/Абстрактная_фабрика_(шаблон_проектирования)> А в случае джавы - антипаттерн или нет - но придётся наследоваться лишний раз.
С чего бы это вдруг? В Java есть интерфейсы. Там не нужно наследоваться.
> И, разумеется, в плюсах есть вложенные классы - ещё от сишных вложенных
> структур пришли. Другое дело, что у них нет автоматического доступа к
> экземпляру клсса-владельца - надо явно отдать ссылку или указатель на него.Есть static nested classes, но нет inner classes.
Вот именно inner classes + интерфейсы покрывают все случаи,
когда в плюсах для этого используется создающее проблемы множественное наследование.> А интерфейс от абстрактного класса вообще ничем кроме названия не отличается.
"Что за бред, простите".
Различие между интерфейсом и реализаций видно очнеь легко - интерфейс - это объявления публичный членов, если речь идёт о классе. Напомниаю, что на плюсах можно отлично писать вообще вне парадигмы ООП - а используя, к примеру, принципы data-flow. А вот желание везде именно явно отделить интерфейс, даже если он будет реализован один единственный раз, да чтобы это было именно слово interface - это как раз та проблема, о которой я и говорю. Для больших проектов такой подход окупается. "Безобразно, зато единообразно". Для малых/средних, те более на плюсах - больше мусора в коде, чем толку.И да, плюсовые абстрактные классы в плане поведения от джавовских интерфейсов вообще ничем не отличаются. ТОлько и того, что ключевое слово разное, да для интерфейсов implements надо писать.
И да, до какого-то размера "не заморачиваться паттернами, а писать реализацию" - самый правильный подход. Потому что писанины меньше, а архитектура и так вся в голове помещается. И поддерживается - опять-таки, до определённого размера - такой код ЛЕГЧЕ, чем тот, где всё тщательно выписано.
Насчёт вариантов фабрики - я в курсе, но, во-первых, это был просто пример, а во-вторых, всё это одна и та же идея "фабрики" в слегка разной подаче. Простите, но чтобы сообразить, что набор генераторов сущностей можно скомпоновать во что-то, что будет выдавать осмысленное сочетание - большого ума не надо.
>> А в случае джавы - антипаттерн или нет - но придётся наследоваться лишний раз.
>С чего бы это вдруг? В Java есть интерфейсы. Там не нужно наследоваться.Ну "реализовывать интерфейс". Суть в том, что в джаве вы обречены иметь (и, соответственно, декларировать и поддерживать) какую-то общую сущность чтобы присвоить переменной значения различных типов. В плюсах же это не обязательно - пока не нужен динамический полиморфизм (а он, как ни странно, довольно редко нужен) - можно обойтись без наследования.
>Есть static nested classes, но нет inner classes.
>Вот именно inner classes + интерфейсы покрывают все случаи,
>когда в плюсах для этого используется создающее проблемы множественное наследование.В плюсах, если это нужно, просто вложенному объекту отдаётся ссылка на родителя в конструктор. И всё.
>> А интерфейс от абстрактного класса вообще ничем кроме названия не отличается.
>"Что за бред, простите".Никакого бреда. Джавовский interface и плюсовый абстрактный класс (точнее, pure abstract class) функционально абсолютно идентичны.
> Различие между интерфейсом и реализаций видно очнеь легко - интерфейс - это
> объявления публичный членов, если речь идёт о классе.То есть, на плюсах - любой класс у которого есть публичные члены является интерфейсом?
Интерфейсом даже является тот класс, который содержит какую-то реализацию? Путаница это.> А вот желание везде именно явно отделить интерфейс, даже если он будет реализован
> один единственный раз, да чтобы это было именно слово interface - это как раз
> та проблема, о которой я и говорю. Для больших проектов такой подход окупается.Для средних тоже. Отделяя интерфейс от реализации интерфейса, например,
очень легко и удобно делать юнит-тестирование кода, на время тестирования
подсовывая mock-классы вместо реально используемых в программе реализаций.Есть такое очень хорошее видео:
https://www.youtube.com/watch?v=G6LJkWwZGuc
Николай Алименков — Парадигмы ООП- это пожалуй лучшая презентация по ООП, что я когда-либо вообще видел.
Рекомендую. Скорее всего, она будет полезна и программистам на С++ тоже,
ведь принципы ООП везде одни и те же.Первым советом идет всегда использовать интерфейсы. Это спорный совет,
но он говорит на основании своего многолетнего опыта программирования.Иногда я этот совет нарушал и тогда было очень проблематично писать юнит-тесты.
> И да, плюсовые абстрактные классы в плане поведения от джавовских интерфейсов вообще
> ничем не отличаются. ТОлько и того, что ключевое слово разное, да
> для интерфейсов implements надо писать.Абстрактные классы есть и в Java. Но это не то же самое что и интерфейсы.
В С++ происходит смешение понятий - разные сущности называются одним и тем же словом,
class - что как минимум, не способствует читаемости кода и легкости его восприятия.> И да, до какого-то размера "не заморачиваться паттернами, а писать реализацию" -
> самый правильный подход. Потому что писанины меньше, а архитектура и так
> вся в голове помещается. И поддерживается - опять-таки, до определённого размера
> - такой код ЛЕГЧЕ, чем тот, где всё тщательно выписано.Да, так. Из чего следует, что обсуждать мелкие проекты вообще смысла нет.
А на среднего размера и крупных проектов пользы от паттернов больше, чем вреда.> Простите, но чтобы сообразить, что набор генераторов сущностей можно скомпоновать
> во что-то, что будет выдавать осмысленное сочетание - большого ума не надо.Это сейчас, когда паттерн известен и хорошо изучен он кажется очевидным.
Когда-то явно этот паттерн не был выделен и его осмысление было открытием.http://habrahabr.ru/post/170125/
Для чего нужны шаблоны проектирования>>> А в случае джавы - антипаттерн или нет - но придётся наследоваться лишний раз.
>>С чего бы это вдруг? В Java есть интерфейсы. Там не нужно наследоваться.
> Ну "реализовывать интерфейс".Если хочем иметь возможность менять реализации - да, надо отделить мухи от котлет,
и сказать, что вот это у нас интерфейс, а вот это у нас - реализация интерфейса.> Суть в том, что в джаве вы обречены иметь (и, соответственно, декларировать
> и поддерживать) какую-то общую сущность чтобы присвоить переменной
> значения различных типов.Извините, а зачем переменной присваивать значения разных типов? Не понимаю.
> В плюсах же это не обязательно - пока не нужен динамический полиморфизм
> (а он, как ни странно, довольно редко нужен) - можно обойтись без наследования.Порочным является исходное желание присвоить переменной значения различных типов.
А тогда когда это оправдано и имеет смысл - все объекты имеют один базовый класс.>>> А интерфейс от абстрактного класса вообще ничем кроме названия не отличается.
>> "Что за бред, простите".
> Никакого бреда. Джавовский interface и плюсовый абстрактный класс
> (точнее, pure abstract class) функционально абсолютно идентичны.Понятно. Я смотрю просто на это все с точки зрения языка программирования Java,
а там interface и pure abstract class - это совсем не одно и тоже, а разные сущности.Вот об этом неудобстве в языке программирования С++ я как раз и говорю - невозможно
понять от чего мы наследуемся, от интерфейса или от реализации не посмотрев внутрь
базового класса.В Java эти понятия очень четко разделены - интерфейс - это всегда только контракт,
а наследование от класса - это наследования реализации/поведения а не интерфейса.Из-за чего - Java позволяет писать более понятный код, по сравнению с плюсами:
James Gosling: Java — это C++, из которого убрали все пистолеты, ножи и дубинки.
> Оно, насколько я опнимаю, пошло из библиотек джавы, которые, во-первых, должны быть универсальнымиСправедливости ради можно отметить, что для библиотек универсальность является плюсом независимо от языка программирования.
Да, должны. Но если универсальность включает в себя требование удобного использоавния в приложениях из многих миллионов строк, а внимание более простым случаям не уделили - то платить за организацию кода прикладной программист будет больше, чем мог бы. Вот теми самыми иерархиями и громоздким кодом.
>Предметная область?Да фактически все тоже самое, что и на C#/C++ пишут пишу на Ди. Прямо сейчас пишу софтину для получения метаданных из спутниковых снимков. До этого писал парсеры и различные утилиты.
Приятель на Ди тоже с Шарпа перешел, пишет серверную часть для сайтов.
> пишет серверную часть для сайтовЧтобы не уволили.
Хорошо, сложно стыковать D с perl. Интересуют вызовы как из D так и из D-функции(кода) из perl.
Любая сишная библиотека достаточно тривиально зацепляется из D, хотя заголовок транслировать, конечно, придётся. Но на практике трансляция заголовка SQlite (а он не маленьки ни разу) требовала у меня пару часов, не больше. Наоборот - C-интферфейс вывешивается тоже совершенно тривиально, с автоматической генерацией сишного хидера. Но на практике пробовать никогда нужды не было, так что за отсутствие подводных камней не ручаюсь.
Уговорил, гляну D как-нибудь на досуге. Но посоветуйте нормальную литуратуру по D чтобы не для нубов, но и не практическое руководство. Издавались нормальные книги?
Ой не туда ответил:
Андрей Александреску - Язык программирования D - 2012
Ruppe - D Cookbook - 2014
При всём уважении к Александреску - советую вот это как минимум в дополнение глянуть: http://ddili.org/ders/d.en/index.html
Андрей Александреску - Язык программирования D - 2012
Ruppe - D Cookbook - 2014