LINUX.ORG.RU

Apache Harmony: 2006 был замечательным - 2007 будет лучше


0

0

Вице-презедент проекта Apache Harmony Геир Магнуссон обратился с новогодним поздравлением к сообществу:

"С Новым Годом! 2006 был замечательным - 2007 будет лучше.

Я хотел бы поблагодарить всех, кто помог Apache Harmony (http://harmony.apache.org) добиться замечательных успехов в 2006 году.

У нас есть, чем гордиться - счастливое и здоровое сообщество, составляющее проект ASF верхнего уровня, замечательная реализация библиотеки классов и виртуальной машины Java SE 5, хороший задел в области JDK инструментария, тестовая инфраструктура, становящаяся лучше день ото дня, серьёзная нацеленность на качественную документацию и множество остальных вещей, которые я не смог сразу вспомнить.

Нашими усилиями мы доказали всем, что реализация Java с открытым исходным кодом может быть сделана за приемлемое время, и, как теперь очевидно, мы имеем большое влияние на развитие экосистемы FLOSS Java (Java с открытым исходным кодом) в целом.

2007 год будет ещё лучше - мы закончим реализацию Java SE 5, как и, будем надеяться, Java SE 6. Я с нетерпением жду дальнейшего роста и процветания нашего сообщества, знакомства с новыми людьми и совместной работы с ними, изучения новых подходов и новых идей, осуществления этих идей в нашем сообществе и исходном коде. Я ожидаю совместной работы с другими сообществами - GPLv3 должна выйти в 2007 году, так же как и код библиотек классов из OpenJDK, так что было бы интересно увидеть, что мы можем сделать вместе.

Ещё раз, большое спасибо всем вам! Мне было приятно работать с вами в течение прошедших 12 месяцев, и я с надеждой смотрю на следующие 12.

Геир"

>>> Исходное сообщение на английском



Проверено: Shaman007 ()
Ответ на: комментарий от Robotron

>Т.е. Вы хотите сказать, что разработчики Struts идиоты и API меняется каждый месяц?

Не хочу я этого сказать, а хочу всего лишь сказать, что потенциально никто не гарантирует как из API может что-то исчезнуть, или изменится по непонятным вам причинам. Такое допустим у меня было несколько раз. (Например, IBM ICU взяло и убрала один С++ интерфейс - сказали, что это не "кошерно" и пишите на С, и что - пришлось собственными силами возвращать на место? :)

akira_ag
()
Ответ на: комментарий от r

>Я как раз говорю что они этого не делают, потому что необходимость стабильного апи для них так же очевидна, без всяких третьих сторон.

Случаи бывают разные, за Struts я особенных проблем не замечал в этом плане, но застрахованным не чувствую.

akira_ag
()
Ответ на: комментарий от akira_ag

>Я считаю что для коммерческих проектов частые изменения API библиотек не самая хорошая вещь, и требует доп. вложенийЧто неправильного я сказал, по-вашему мнению?

Хотя бы то что вы сказали не это. Вы сказали:

> У Hibernate/Struts есть один существенный минус - их API не утверждаются независимой стороной и зависят от настроения разработчика.

Дык вот между этим вашим утверждением и верхним есть существенная разница. "Третья независимая сторона (здесь насколько я понимаю JCP имеется ввиду?" - это не что-то спущеное свыше - это просто стандартизирующий инструмент с целью обеспечить стабильную спеку. Из этого не проистекат что стабильную спеку не может обеспечить сам разработчик - если он понимает зачем. Разработчики струтс это прекрасно понимают. ЗАвремя своего существования API струтса поменялся меньше чем суперстандартное EJB. Еще один пример - C3 - ECMA-стандартизирован. что не мешает ему менятся с каждуй версией.

r ★★★★★
()
Ответ на: комментарий от r

>Хотя бы то что вы сказали не это. Вы сказали:

мои оба утверждения это одно и тоже - просто про Hibernate это в частности: Любое API лучше бы заверять независимой стороной (лучше теми, кто используюет это же API), без относительно, кто сам разработчик

>Третья независимая сторона (здесь насколько я понимаю JCP имеется ввиду?" - это не что-то спущеное свыше

Ну для Java лучше JCP счас вроде ничего и нет. . Стандартизация API и одобрение его со стороны пользователей/разработчиков других систем - хорошая и полезная вещь.

EJB как раз менялся под давлением общественности, потому что писать теже CMP было практически очень трудно.

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

akira_ag
()
Ответ на: комментарий от Robotron

Это все есть ересь и отход от единственно правильного канона Галахи (EJB). Исключение таки сделаем только для Hibernate, поскольку он вместе с TopLink и KODO используется для EEJB3 (см. мегарулезный NetBeans 5.5).

Bioreactor ★★★★★
()

EJB, CMP, BMP, JCP, JDO, JPA, JSF, JSP Просто охрененная фантазия у жабаделателей на названия...

anonymous
()
Ответ на: комментарий от anonymous

>EJB, CMP, BMP, JCP, JDO, JPA, JSF, JSP...

Причем надо заметить, что только в 2-х случаях нет буквы J. И эти оба же провальные получились :)

akira_ag
()
Ответ на: комментарий от anonymous

А еще таки уже есть CoG (Java CoG Kit). Кто еще что имеет сказать?

Bioreactor ★★★★★
()
Ответ на: комментарий от akira_ag

Вы сделали нам смешно! CMP и BMP "провальные"??? :)

Конечно persistence.xml содержащий

<persistence version="1.0" ... >
<persistence-unit name="..." transaction-type="JTA">
<provider>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source>jdbc/oracle</jta-data-source>
<properties/>
</persistence-unit>
</persistence>

типа удобнее будет, да вот только еще много что из legacy работает под Entity EJB 2.

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

Ваша ирония, говорит о том, что вы не видели сколько в XML нужно писать для EJB2/CMP. А вас не смутило, что так быстро Sun смог отказаться по сути дальнейщего его продвижения? Очень просто - очень сложно, тормознутый, неудобный и негибкий - лучшие слова для этой штуки. Почему Hibernate/JDO жить начали вообще? Короче, что вам доказывать... Вы сами-то их хоть раз в продакшане использовали без проблем?

akira_ag
()
Ответ на: комментарий от akira_ag

На самом деле, XDoclet все это дело очень прилично скрывал и автоматизировал.
Тут люди на Hibernate налигают,типа вот из-за нее многое поменялось, а вот про XDoclet все быстренько забыли. А ведь я уверен, что все кто сейчас потдерживает Ejb2.x проекты, на 90% используют XDoclet.
Я пробывал EJB2+JDO(Kodo)+XDoclet, кодирование как таковое не сильно намного отлечилось от EJB3 (%20 меньше), сильно изменильсь кол-во классов необходимых для реализации, что привело к упрощению в отладки, пддержке, развертывании, а это %40 времени....

gapik
()
Ответ на: комментарий от gapik

Ой, звеняйте, что-то коньяка сегодня лишнего принял... все что после EJB3 относиться к EJB3 (простите за тафтологию)...

gapik
()
Ответ на: комментарий от akira_ag

>Почему Hibernate/JDO жить начали вообще? Короче, что вам доказывать... Вы сами-то их хоть раз в продакшане использовали без проблем?

Т.е. Hibernate/JDO в продакшене можно использовать без проблем или нет?

Robotron
()

Прочитал ветку, и хочу добавить некоторые ясности по поводу EJB и Hibernate:

Для того, чтобы понять последние изменения в новой спецификации EJB3, надо копнуть чуть глубже в историю, во времена EJB2 (EJB 2.1). В последние годы всё громче и громче слышалась критика в адрес EJB2, в частности в области entity beans и persistence. Разработчикам не нравилось, что для того, чтобы просто иметь дело с persistence надо писать много чего лишнего. Компаниям не оставалось ничего, как начать улучшать EJB. В это же время начался расцвет легковесных фреймворков, в том числе и persistence-фреймворка Hibernate.

В 2003 году, Sun, как главнокомандующий, начал новый проект с целью упрощения EJB, проект получил название Enterprise JavaBeans 3.0 (JSR 220), к которому многие проявили очень большой интерес, в том числе и разработчики Hibernate. Более того, разработчики из команды Hibernate присоединились к экспертной группе по разработке спецификации EJB3 ещё на ранней стадии, и привнесли многое из того, что сейчас представляет из себя EJB3. Самым важным решением нового стандарта было привнести и стандартизировать вещи, которые уже работают на практике, беря идеи и концепции с уже успешных продуктов и проектов. Одним из примеров успешного проекта был Hibernate, который сыграл очень важную роль в становлении спецификации в области persistence.

Спецификация EJB3 состоит из нескольких частей: первая часть состоит из программной модели, которая представляет из себя session бины, message-driven бины, правила, и т.п., а вторая часть: persistence: объекты, ОРМ, язык запросов. Вторая часть спецификации просто называется Java Persistence API или просто JPA. Что важно, продукты могут теперь реализовывать весь EJB3 или только ту часть, которая относится к JPA. И ещё два важных принципа заложенных в спецификации: возможность замены JPA-движка и возможность запуска JPA-движка вне контейнера EJB3, т.е. в стандартной Яве.

И подытоживая, Hibernate как раз может выступать как продукт в качестве того JPA-движка. То есть, реализует Java Persistence.

Насчёт будущего Hibernate, как говорят сами авторы, Hibernate будет развиваться независимо и быстрее чем спецификации EJB3 и Java Persistence. То есть, оставаться той самой тестовой площадкой для новых идей, каковой она была до этого. А если, со временем, какая-то новая концепция докажет свою полезность, то разработчики Hibernate будут дальше работать с другими членами экспертной группы над будущей стандартизацией в обновлённых спецификациях EJB или Java Persistence. И поэтому авторы Hibernate призывают использовать полную функциональность Hibernate и слать им свои замечания и/или пожелания, если вы заинтересованы в быстром развитии стандарта.

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

dotcoder ★★★★★
()
Ответ на: комментарий от akira_ag

Ой, вей! А Вы таки вручную писали деплоймент-дескрипторы?

> Вы сами-то их хоть раз в продакшане использовали без проблем?

АПВС? В чем проблемы?

> Почему Hibernate/JDO жить начали вообще? Короче, что вам доказывать...

Потому что некий B.A.Tate именно доказал правильность такого подхода.

http://www.oreilly.com/catalog/bfljava/

Именно доказал, ибо следуя заветам Профессора В.С.Луговского, надо все ДОКАЗЫВАТЬ, а не создавать информационный шум.

ЗЫ. Сам я, как Вы таки понимаете, сторонник использования EJB3 и технологий, рекомендованных мегарулезной Sun (TopLink, JDO KODO, Hibernate). Плюс JSF, разумеется. А не поделий, имя коим легион. Типа "велосипеда" под названием velocity.:)

Bioreactor ★★★★★
()
Ответ на: комментарий от dotcoder

После появления NB 5.5 интерес к EEJB 2.1 у меня лично как-то пропал. Однако

1) Есть унаследованные приложения.

2) Масса ленивых программистов, которые не хотят самосовершенствоваться, изучая Java 5 (и EJB3). Таких я знаю, и знаю, что переубедить их не смогу. Кроме WebLogic 8.1 + JBuilder 2005 и знать ничего не хотят.

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

>Ой, вей! А Вы таки вручную писали деплоймент-дескрипторы? >> Вы сами-то их хоть раз в продакшане использовали без проблем? >>>АПВС? В чем проблемы?

Ага... счас начнут нам рассказывать маркетинговые бредни... Когда тот-же ваш Netbeans научился генерировать CMP? 2006-год? Что вы до этого делали- писали доклеты? АПВС говорите? И где там СMP и какая структура БД? Надеюсь не одна таблица? Кто-то цитировал Луговского, так покажите нам success story please...

akira_ag
()
Ответ на: комментарий от Bioreactor

>После появления NB 5.5 интерес к EEJB 2.1 у меня лично как-то пропал

Я вот одного понять не могу... Если отобрать у вас IDE, вы даже дескрипторы прочитать и понять не сможете?

akira_ag
()
Ответ на: комментарий от dotcoder

>Разработчикам не нравилось, что для того, чтобы просто иметь дело с persistence надо писать много чего лишнего

Разработчикам (да и не только) всегда не нравиться, писать много лишнего, вне зависимости от того, с чем иметь дело :)

akira_ag
()
Ответ на: комментарий от Bioreactor

>Потому что некий B.A.Tate именно доказал правильность такого подхода.

Это не он написал книгу о том, что Java прошлый век и стоит ориентироваться на что-то типа Ruby?

>ибо следуя заветам Профессора В.С.Луговского, надо все ДОКАЗЫВАТЬ, а не создавать информационный шум.

Кто этот замечательный муж?

Robotron
()
Ответ на: комментарий от Bioreactor

> Плюс JSF, разумеется.

И что, JSF уже поддерживает container security, j_security_check и form-based authentication?

Поделитесь рецептом.

daebear
()
Ответ на: комментарий от Robotron

>Т.е. Hibernate/JDO в продакшене можно использовать без проблем или нет?

Проблемы всегда будут, особенно с БД со сложной структурой, где множество таблиц, связей, batch-запросы, stored/procedures.

Просто с CMP вы поимеете их гораздо большие, но в продакшене использовать можно и нужно, особенно в системах.

akira_ag
()
Ответ на: комментарий от akira_ag

менеджмента данными, где обычно много форм, и много таблиц.

Для задач, где требуется только мелкие и быстрые выборки можно вообще обойтись без тяжеловесных ORM.

akira_ag
()
Ответ на: комментарий от daebear

АВОВНВ???

Какая у Вас конкретная задача? Обоснуйте превосходство "тейпстри", "велосипеда" или "стратсов" перед JSF. Можно не мне, а сразу сантехникам.

Bioreactor ★★★★★
()
Ответ на: комментарий от akira_ag

> где требуется только мелкие и быстрые выборки можно вообще обойтись без тяжеловесных ORM.

Угу! True JDBC - рулит.

Bioreactor ★★★★★
()
Ответ на: комментарий от Robotron

>>ибо следуя заветам Профессора В.С.Луговского, надо все ДОКАЗЫВАТЬ, а не создавать информационный шум.

>Кто этот замечательный муж?

Профессор - это наше всё!

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

>"стратсов" перед JSF

Блин. Я не понимаю, откуда такой фанатизм? Я тоже уважаю компанию Sun, но не молюсь на нее. Я надеюсь в курсе, что JSF и Struts имеет за собой задумки одного человека по имени Craig Mcclanahan, который и создал Struts и был co-spec-leader в JSF) ?

akira_ag
()
Ответ на: комментарий от Robotron

> Это не он написал книгу о том, что Java прошлый век и стоит ориентироваться на что-то типа Ruby?

Он, он! А еще, кроме Bitter Java, сей корифей писал Taligent, работая в IBM... :)

Повторяю. Надо все обосновывать, а не создавать информационный шум.

Bioreactor ★★★★★
()
Ответ на: комментарий от akira_ag

Какие нехорошие борландеры! Исключили струтсы из JBiulder 2007!!! Напишите им ноту протеста.

Или просто обоснуйте свое мнение без флуда о "удачных" и "неудачных" названиях.

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

>Какие нехорошие борландеры! Исключили струтсы из JBiulder 2007!!! Напишите им ноту протеста.

Вы там случайно не пьете? Причем тут JBuilder вообще... Короче, понятно все... Не буду мешать "блаженствовать"!

akira_ag
()
Ответ на: комментарий от akira_ag

Поделие Struts с двумя классами на действие - не поддерживается нынче за ненадобностью. Была сделана более-менее хорошая поддержка в свое время Struts в WSAD, но сейчас и сами бимеры предлагают использовать JSF.

"Struts (I am not saying you should not use Struts)

&#8211; No built-in UI component model

&#8211; No built-in event model for UI components

&#8211; No built-in state management for UI components

&#8211; No built-in support of multiple renderers (Struts is more or less tied up with HTML)

&#8211; Not a standard (despite its popularity)"

(c) Sang Shin, sang.shin@sun.com, Sun Microsystems, www.javapassion.com/j2ee, class forum

А Вы свою точку зрения ДОКАЗАТЕЛЬНО изложить можете?

Bioreactor ★★★★★
()
Ответ на: комментарий от akira_ag

Ну, раз не можете изложить по существу, можете переходить на личности. Ваше право. Я Вам читату из презентации выступавшего привел...

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

Какую точку зрения вы хотите из, чтобы я доказывал? CMP - вы не привели ничего, чтобы не потвердило опыт успешного его использования. По использованию - любой разработчик увидит, насколько он "тяжел". Struts - что вы от меня хотите? Я всего-лишь писал, что JSF то большей частью эволюция Struts вместе с стандартизацией. А господин Sang Shin умалчивает, что для некоторых задач Controller в Struts выглягит удачнее, чем event model в JSF, о чем я собственно с ним и беседовал.

Если вы думаете, что мнения "евангелистов" Sun - священные писания, то бессмысленно с Вами спорить.

akira_ag
()
Ответ на: комментарий от Bioreactor

> Ну, раз не можете изложить по существу, можете переходить на личности. Ваше право

Я не хотел переходить на личности, поэтому прошу извинить за столь неуместную реплику, но язвительный тон нашей беседы задан вами самими.

akira_ag
()
Ответ на: комментарий от akira_ag

Позвольте, я таки уже высказал свою точку зрения о том, что EJB 2.1 подходят только для поддержки унаследованных приложений и для тех, кто не хочет развиваться. Код XML был явно c моего NB 5.5.

> Controller в Struts выглягит удачнее, чем event model в JSF

У Вас есть конкретные обоснования? Есть мнение, что и когда желательно испоьзовать, четко изложенное

http://www.simplica.com/strutsvsjsf.htm

с приведением аргументом. Аргумент может быть и неправильный. Главное, чтобы он был.

> Если вы думаете, что мнения "евангелистов" Sun - священные писания, то бессмысленно с Вами спорить.

Вообще-то принципа Карла (не Маркса:)), о том, что научностью любой теории является ее принципиальная возможность фальсифицированости наряду с верифицированностью, я здесь как-то много говорил. Так, что важны аргументы, а не каббалистика названий JFC & etc..:)

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

>Позвольте, я таки уже высказал свою точку зрения о том, что EJB 2.1 подходят только для поддержки унаследованных приложений и для тех, кто не хочет развиваться. Код XML был явно c моего NB 5.5.

А причем тут весь EJB2.1? Я всего лишь про Entity. Меня Session Beans/MDB даже в 2.1 устраивали.

>> Controller в Struts выглягит удачнее, чем event model в JSF

>У Вас есть конкретные обоснования? Есть мнение, что и когда желательно испоьзовать, четко изложенное

Пожалуйста, не вырывайте фразу без начала. Я писал в _некоторых случаях_ . А то потом, обвините меня в каких-нибудь смертных грехах. Вы правильно сказали - есть мнение и даже ссылку привели. Точно также есть оно у меня, тоже из опыта работы с Struts/JSF. Поэтому приводить полные плюсы и минусы Struts приводить не будо, ибо они и так известны. Если говорить про Controller - то Struts контроллер позволял отделить логику обработки HTTP-запроса, от бинов и обеспечить reuse этой логики было проще. Для JSF это делать тоже можно - но самому. Посмотри, например, на Shale: http://shale.apache.org/ - я правда не слежу особо за его развитием, но там как раз собиралось, то что не хватало в JSF.

akira_ag
()
Ответ на: комментарий от akira_ag

> Меня Session Beans/MDB даже в 2.1 устраивали.

Новые поприятнее будут. Правда, надо Java 5 учить:)

Хорошо генерация SEJB "фасадов" к персистент-объектам в NB 5.5 реализована - эргономично. NB 5.5 - Это просто приятный инструмент, хотя есть небольшие глючки типа, что не все стили в элементах отрабатываются в дезайнере страницы (VisualWeb) . И менюшки для странички внешние от ICEfaces цеплять требуется. Но, в целом, неплохо и удобно.

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

Вы сами какую IDE используете? Cледуете ли Вы заветам безвременно покинувшего наш форум Проф.В.С.Луговского о том, что надо все писать в emacs или vi? :)

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

>Вы сами какую IDE используете?

История моего использования IDE долгая, но раз спросили: - Symantec Cafe 1.0 (Java 1.0) - FAR (Java 1.1/1.3) - NetBeans 3.x (Java 1.3) - NetBeans 4.x (Java 1.4) - NetBeans 5.x (Java 1.5) - для создания GUI/Web и JDeveloper - библиотеки/UML (к сожалению NetBeans проигрывает по производительности и качеству - слишком много баг встречается).

p.s. JBuilder 1.0 запускал один всего раз (очень долго запускал), после того как он мне попытался в проект по умолчанию запихать свои нестандартные библиотеки удалил.

akira_ag
()
Ответ на: комментарий от akira_ag

> NetBeans проигрывает по производительности и качеству - слишком много баг встречается

Ну, что же, обновляется потихоньку.

Самому приходится

- IBM WSAD / Rational Application Developer for WebSphere Software

- NetBeans 5.5

:)

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

> NetBeans проигрывает по производительности и качеству - слишком много баг встречается

>Ну, что же, обновляется потихоньку.

Да в курсе ...

> - IBM WSAD / Rational Application Developer for WebSphere Software

Купленный? ;-)

akira_ag
()
Ответ на: комментарий от Bioreactor

> - IBM WSAD / Rational Application Developer for WebSphere Software

А я как-то к Eclipse никак привыкнуть не могу... Мне все время кажется, что можно было сделать как-то проще... для людей так сказать... Правда, честно пытаюсь каждый год к нему подступиться :)

akira_ag
()
Ответ на: комментарий от Bioreactor

После Eclipse к NetBeans тяжко привыкать. Всё как-то не так, выглядит по деццки. Хотя и GUI дизайнер в нём на голову выше.

anonymous
()
Ответ на: комментарий от anonymous

>После Eclipse к NetBeans тяжко привыкать. Всё как-то не так, выглядит по деццки. Хотя и GUI дизайнер в нём на голову выше.

Уж не знаю, что там по деццки, но факт в том, что NetBeans приятней эклипса!

Robotron
()
Ответ на: комментарий от Bioreactor

>Cледуете ли Вы заветам безвременно покинувшего наш форум Проф.В.С.Луговского о том, что надо все писать в emacs или vi? :)

Какой достойный был муж, его не пугала, но закаляла суровость emacs и vi!

От нас уходят лучшие! :)

Robotron
()
Ответ на: комментарий от Robotron

> но факт в том, что NetBeans приятней эклипса!

Разве что Java GUI Builder там действительно лучше. А в остальном - хуже.

kda ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.