Новый стандарт Java EE 6 утвержден

И чего ASF было против?..

The Apache Software Foundation's vote is based on the point of view that this spec lead - Sun - is in violation of the JSPA

http://www.apache.org/jcp/sunopenletter.html

and therefore shouldn't be allowed to lead other JSRs until the above matter is resolved.

кратко, из-за лицензии на Java Compatibility Kit

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

Ага, жалко только что в Ынтырпрайзах начнет появляться через годика полтора-два, некоторые на 1.4 до сих пор

как профессиональный жабер говорю «ну и х...с ним».

> как профессиональный жабер говорю «ну и х...с ним».

непонятно... Вы смотрели это? я просто уже похеллоуворлдил и прочитал рефернсы. там все в шоколаде. основной плюс «Java EE в массы». все стало проще и дотсупнее рядовым веб-девелоперам. а былая мощность осталась.

Ага, жалко только что в Ынтырпрайзах начнет появляться через годика полтора-два, некоторые на 1.4 до сих пор

Это да... Жаба ЫЫ таким страдает. Особенно книги на Петровке... Только 1.4...

а былая мощность осталась.

Что лично меня, как профессионального жабера, радует в моей безрадостной жизни, так это то что каждый крутой стандарт в этой области создавался, распространялся, проходил мимо и тихо издыхал будучи замененным более простым стандартом в этой области. А я не испытывал никакого дискомфорта на протяжении всех лет, что я их игнорировал:) Servlet/JSP+EL и JTA(последнйи раз года 3 назад) единственные стандарты которыми я реально повседневно пользовался.

>как профессиональный жабер говорю «ну и х...с ним».

ребята из спринг сказали так же, и даже не удосужились проголосовать )

ну, ребята из спринг могут себе такое позволить)))

Ну просто смотря какая контора и смотря какие проекты. Я вон тоже долгое время сидел на чистом JSP/Servlets, в начале карьеры это было не особенно хорошо.

Мутанты, они бы лучше эпический баг с \u в коментах пофиксили. Если в комментах встречается \u то считается что дальше должен идти уникод и компилятор выплевывает ошибку, например в случае // test\ums. Все решают как исправить, а в багтрекере кажись года с 2000 висит.

> например в случае // test\ums.

Потому что разделитель каталогов - «/», а «\» - начало escape-последовательности. И это скорее фича чем бага.

Спринг гавно.

Голод не тетка, да?

>Если в комментах встречается \u то считается что дальше должен идти уникод и компилятор выплевывает ошибку, например в случае // test\ums. Все решают как исправить, а в багтрекере кажись года с 2000 висит.

Дык, надо было в багзиллу M$ эту багу вешать: какого хрена у них разделитель каталогов - «слэш не в ту сторону»?

А что, есть багзилла M$?

> основной плюс «Java EE в массы». все стало проще и дотсупнее рядовым веб-девелоперам. а былая мощность осталась.

Быдлоява стала еще больше быдло и еще больше ява?

> какого хрена у них разделитель каталогов - «слэш не в ту сторону»?

Элементарно. / как маркер опции команды они сперли у DEC раньше, чем стырили из Unix дерево каталогов.

Отличная новость!! Ознакомился с GF V3 prelude не так давно - намного интереснее GF 2.2.

Элементарно. / как маркер опции команды они сперли у DEC раньше, чем стырили из Unix дерево каталогов.

ага и саму идею каталогов - были только диски с корнем (подкаталоги появились во 2 версии доса)

Новый стандарт Java EE 6 утвержден

Элементарно. / как маркер опции команды они сперли у DEC раньше, чем стырили из Unix дерево каталогов.

ага и саму идею каталогов - были только диски с корнем (подкаталоги появились во 2 версии доса)

(напеваю) Каппитаны... Каппитаны...

Ну вот и отлично. Буду ждать универских семинаров по теме.

По ссылке пройти не?

Потому же, почему SAP воздержался:

On 2009-11-30 Apache Software Foundation voted No with the following comment: The Apache Software Foundation's vote is based on the point of view that this spec lead - Sun - is in violation of the JSPA

http://www.apache.org/jcp/sunopenletter.html

and therefore shouldn't be allowed to lead other JSRs until the above matter is resolved.

This vote is not a comment on the technical merits of the JSR. If not for the issue of the spec lead, the ASF would have otherwise voted «yes».

Spring - это стандарт de facto. Spring + Hibernate. Плюс maven.

Из MVC - либо спринговый, либо новомодный Apache Wicket.

Говорю это как бывший жабабыдлокодер.

Что-то меня напрягает что ASF был против... Они столько сделали хорошего по-настоящему качественного и незаменимого продукта (куда без антов-мавенов томкатов и прочего). Думаю не зря им чето не понравилось...

>Spring - это стандарт de facto
согласен. Но почитай спеку пожалуйста. В j2ee6 кроме всего прочего входит jsr 299 - Java Contexts and Depenency Injection. Так что теперь Weld - стандарт де-факто

Кста а, что насчет Wicket vs Tepestry 5?

Wicket легче в изучении и понимании. Typestry года 3-4 назад применялся во всю, ща приутихло. Все ударились в gwt, extjs, ext-gwt (в качестве гуевых библиотек).

> Что лично меня, как профессионального жабера, радует в моей безрадостной жизни, так это то что каждый крутой стандарт в этой области создавался, распространялся, проходил мимо и тихо издыхал будучи замененным более простым стандартом в этой области. А я не испытывал никакого дискомфорта на протяжении всех лет, что я их игнорировал:) Servlet/JSP+EL и JTA(последнйи раз года 3 назад) единственные стандарты которыми я реально повседневно пользовался.

Советую посмотреть JPA, Facelets, EJBLite. Идея в том что сделали облегченную для программирования EJB, так как только в EJB работают инъекции. А так обзываете любой класс EJB и пару за строчек кода туда будут любые инъекции.

Ну а JPA хоронит MS LINQ, потому что работает с любыми СУБД, а тот только с MS SQL, что не всем подходит. Oh, well, вообще мало кому. Вот и стонут, делают хаки.

Glassfish v3 - вообще красавец, очень крутой сервер.

Facelets - подростает замена JSF, который работал через JSP, которые сами работали через Servlet, которые потом компились в нативный код. Долой длинные цепочки. Пишете XHTML файл - шаблоны страниц, а потом просто наполняете контентом. Там где не наполнили, там по умолчанию. таким образом дизайнер наваял XHTML страницы с шапкой и кнопками навигации, которая дизайнер френдли. Программер отдельно написал код генерации контента, код для кнопок, а на странице номер 5 еще две кнопки добавил. Легко. А скорость работы - молниеносная на Facelets.

Я конечно сейчас говорю отчасти не о стандарте, я не знаю что там точно написано. Просто скорее о фичах Glassfish v3, первого Java EE 6 сервера.

Вы имели в виду Tapestry?

Это такой холиварчик.

Мне, Spring MVC хватало. Ну и всяких там вкусностей типа DWR и jQuery UI для кавайных страничек.

Главное, чтобы не Struts + Velocity, что есть полный кирдык читаемости, сопровождения и модифицируемости кода.

А обосновать?

> Мутанты, они бы лучше эпический баг с \u в коментах пофиксили.

Абалдеть! Я прочёл и глазам своим не верю. Я правильно понимаю, что эти горе-языкостроители обрабатывают \u раньше, чем вырежут из исходников комменты?!!? Я валяюсь!!! :))))

Быдлокодинг. Теперь по стандартам.

LINQ работает с любыми данными из любых источников, учите матчасть

Это как бы не то что сказала мне девушка, которая работает на LINQ проэкте. Только с MS SQL Server действительно все гладко. А вот с остальными бывают косяки. Хотя заявлена поддержка через ADO.NET любой бд. Ты не знаешь основную стратегию MS? vendor lock-in?

>По ссылке пройти не?

Java лично мне неинтересна, чего ходить? :)

>> Только с MS SQL Server действительно все гладко. А вот с остальными бывают косяки.

Теоретически оно может работать со всем, только бэкэнд надо соответсвующий написать/применить. Однако сейчас там, насколько я помню, реализована работа только с XML и MS SQL (и м.б. Оракл, не помню точно).

>Советую посмотреть JPA, Facelets, EJBLite. Идея в том что сделали облегченную для программирования EJB, так как только в EJB работают инъекции. А так обзываете любой класс EJB и пару за строчек кода туда будут любые инъекции.

Ну вот, какие-то инъекции придумали. Грязные хаки для нормального языка. Похабцы.

Пишете XHTML файл - шаблоны страниц, а потом просто наполняете контентом.

Программер отдельно написал код генерации контента, код для кнопок, а на странице номер 5 еще две кнопки добавил. Легко.

Давайте уже скажем прямо: вместо Java везде использовать XML в качестве языка программирования. Чевоуж. Зачем использовать половинчатые решения?

>как профессиональный жабер говорю «ну и х...с ним».

+1024^2

>Думаю не зря им чето не понравилось...

ASF Яву свою Harmony пилят. Она несовместима с JavaEE 6 более чем полностью.

LINQ работает с любыми данными из любых источников, учите матчасть

А напеши ка мне на LINQ установку соединения и SQL-запрос к Apache Derby.

>> ASF Яву свою Harmony пилят. Она несовместима с JavaEE 6 более чем полностью.

Конечно, потому, что Harmony - это имплементация Java SE 5 )))

Ну просто смотря какая контора и смотря какие проекты. Я вон тоже долгое время сидел на чистом JSP/Servlets, в начале карьеры это было не особенно хорошо.

Любая. Большинство проектов на J2EE серверах их не требуют в принципе. Исключение - вебсервисы.

> ребята из спринг сказали так же, и даже не удосужились проголосовать )

+1 им, если так. :D Колупают монстра, ну хоть EJB в порядок привели, а то страшно вспомнить...

> Что-то меня напрягает что ASF был против... Думаю не зря им чето не понравилось...

Ъ?

> м.б. Оракл, не помню точно

Да вы правы. Кажется и оракл

> Ну вот, какие-то инъекции придумали. Грязные хаки для нормального языка. Похабцы.

В чем хак? Аннотация - средство языка. Приложение управляется VM, а EE еще и контейнтером. Пусть автоматом при загрузки инициализирует переменные обьектом из контейнера. Например соединением с БД

ничё, что это ВНЕЗАПНО описано в спецификации языка? будешь дальше валяться?

Советую посмотреть JPA, Facelets, EJBLite.

Я знаю что там.

Идея в том что сделали облегченную для программирования EJB, так как только в EJB работают инъекции.

Класно. EJB почти здохло в том виде в каком задумывалось 10 лет назад. Первым шагом к эвтаназии были Local интерфейсы. Задумывали корбу с человеческим лицом, получили страшно тормозную хрень. Кто нить их зовет сейчас через RMI/IIOP? У них как была область применения крайне узкая так и осталось - но куча фанбоев начала писать хомепаги на J2EE с распределенными транзакциями. И да у меня нет проблем с кластеризацией сервисов на энтерпрайз бинах - потому что у меня нет тормозов связанных с энтерпрайз бинами, и как следствие необходимости в кластере. Так что то что теперь технология которая была оверкилом с самого основания в 99% случаев, стала такой что на ней даже писать можно - это очень смешно. Вся тенденция развития EJB была не в направлении «просто -> след версия лучше», а «неюзабельное говно -> менее неюзабельное говно».

JPA - тоже песня. Типичная архитектура систем, в которых это используется - это RDBMS + вебморда. При чем методом ORM возможности RDBMS обрезаны по самые помидоры. В результате имеем - запрос через JDBC в базу, материализация в виде жабских объектов, сериализация в текст веб страницы. Материализация - тормозная вещь, делаем кэш второго уровня. Кэш второго уровня требуется делать распределяемым, чтобы иметь возможность кластеризоваться. Тут наступает момент эпического вопроса - нам нужен кластер потому что тормозит или тормозит потому что кластер сделали там где не надо? Потому многоядерные феномы и неосиливают нагрузку с которой вполне справлялись и 10 лет назад двухсотые пеньки. С покон веку производительность упиралась в RDBMS, а тут придумали где бы еще все затормозить, чтобы потом это все кластеризовать.

Про JSF вообще облом говорить - одно дело делать стандарт для визуальных редакторов - но так изгаляться чтобы табличку вывести из базы в веб - это офигеть.

Ну а JPA хоронит MS LINQ, потому что работает с любыми СУБД, а тот только с MS SQL,

http://code.google.com/p/dblinq2007/ LINQ provider for Oracle, PostgreSQL, MySQL, Ingres, SQLite, Firebird and ... SQL Server (C# 3.0)

Легко. А скорость работы - молниеносная на Facelets.

Подход типа тайлсовского - самострангулейшен для дизайнера и динамисно развивающегося проекта. Одно дела заменить один инклуд на другой, но при их инвертированном подходе вставок в общие шаблоны отличий путем некого маппинга - через некоторое время это превращается в немайнтабельный ужос. Этот опыт конечно основан на тайлсах, а не на фейслетах, но если там таже идеология - то идет она лесом - по моему мнение разработка проекта состоит в развитии бизнесфункциональности проекта, а не в разборках как подружить JPA с ораклом и EJB так, чтобы JSF не тормозил.

И тут еще тайпестри упоминали. Не знаю как сейчас но в тайпестри 2 когда мне прилось реализовать аналог invokeLater для веба - я понял что кто-то сильно головой ударился изобрев такой фреймворк где «доступ к параметрам запроса зависит от того в какой фазе находится страница». После этого все это было выпилено нахрен.

Есть классические задачи которые типичны для веба и не менялись с момента появления HTTP и все то что я вижу практически не пытается их решать.

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

Не осилил вашу логику. Ничего более удобного чем Facelets для гигантских страничек, а также и для любых других не видел.

http://code.google.com/p/dblinq2007/ LINQ provider for Oracle, PostgreSQL, MySQL, Ingres, SQLite, Firebird and ... SQL Server (C# 3.0)

Повторяю. Человек в реальном проэкте сказал, что они сказали одну из этих поделок, и они не для продакшн. Имеем костыли. И они в своем проэкте просто не смогли свой код заставить работать на чем либо другом кроме MS SQL. Это поддержка других БД? Должно быть так: данные перелил в другую бд, подключение поменял и все. Тем более делать специально отдельный бекенд для каждой бд? В Java нужен просто JDBC драйвер. Более того делаю неподвержденное предположение что это работает через мост JDBC-ODBC.

а «неюзабельное говно -> менее неюзабельное говно».

В чем вы видите проблему

@Stateless
public class UsersManager {
... 
   @PersistenceContext(unitName="webapp2PU")
    EntityManager em;

    public List<UserItem> getUsers()
    {
        List<UserItem> i = em.createNamedQuery("selectAllUserItems").getResultList();

        return i;
    }
...
}

...

@EJB
UsersManager manager;

В чем вы видите проблему EJB? Это потом очень легко как угодно распределить. Я привел локальный простой код. Никаких оверкилов.