[JavaEE][EJB] История успеха

Загрузил другую софтину. Jetty+Spring+JPA на сервере. На клиенте Swing+Spring+HttpInvoker+куча бизнес логики = 100 МБ

Java EE, такой Java EE

Джава не для хелловорлдов.
</thread>

Написал хелловорлд стал мужиком?

Ты бы ещё графический торрент клиент написал /trololo

Тебя на скрине ничего не смущает?

А это при чем?

для далеких от Явы, как таковой, что не так кроме непонятной желтой муйни?

Сообщения об ошипке не вижу, но че это она?

Аааа 270МБ, так ничего страшного!
Энтерпрайзы должны поддерживать писателей софта,
каждому менеджеру по 1ТБ ОЗУ!

270 MB на hello world построенные на EJB. Такое на Spring по какому-нибудь протоколу будет метров 40 МБ хавать

Нет. А что меня там должно смущать? Что жаба кушает 200 с хером метров оперативы? Так это же Энтерпрайз, там один глассфиш+вся инфраструктура сложнейшие компоненты, сами по себе будут кушать мама не горюй.

Так я не Glassfish говорю, пофиг сколько он там ест. Это КЛИЕНТ с одной кнопкой и полем ввода. Но естественно в Application Container и с EJB

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

Я знаю что не будет особо ничего меняться. Меня ужасает начальный оверхед. И что же там такого полезного внутри?

При «ява на десктопе не нужна».

Экспериментально проверено что обычные приложения особо не жрут. Но EJB меня поразил

Какая разница какой начальный оверхэд - главное какой конечный - по крайней мере для ситуации, когда реально нужно выбрать инструмент для конкретного приложения.

И что?

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

В БОЛЬШОМ количестве случаев - повод

Поэтому в JavaSE 8 будет модульность. Всегда Ваш - Капитан...

Как то поздно, не?

В БОЛЬШОМ количестве случаев - повод

Даже при том, что сам кэш динамический и освобождается по первому требованию к выделению памяти программных процессов?

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

По-мне, так незанятость памяти на сервере и малая загрузка — пустая трата электроэнергии, выработка механического ресурса кондиционирующего оборудования и низкий КПД использования всего серверного оборудования.

Не. Ребята с серваками ценой в миллион долларов пока не жаловались

Но разговор ведь о EJB на клиентских машинах, а не о ZFS (и пожалуйста, не о FreeBSD). Клиентские машины ввиду своего количества даже в приличных компаниях бывают маломощными.

EJB — серверная технология.

Но у Оракла написано что нормальное Java EE клиентское приложение должно связываться с сервером через EJB, тоесть держать Application Client Container на клиенте. И жрать память (этого не написано)

Я тоже могу письмо в железнодорожном контейнере посылать, а потом возмущаться что дорого вышло.

Плохо что его нельзя сделать Lightweight, будучи вообще главным методом связи в Java EE.

Не проблем нет, пару строчек и будет JAX-WS, работает отлично. Просто за обычный EJB обидно