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 ()

замените плиз чисто русское слово - "имплементация" на "реализация".

isden ★★★★★
()

что это такое? =)

anonymous
()

Поздновато он с поздравлениями.

Arceny ★★
()

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

похоже на заявление ммелкомягких :)

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

>похоже на заявление ммелкомягких :)

а что? Нужно было обязательно сказать "вендекапец"? :)

akira_ag
()

Народ! А кто пользовал флосс? Что скажите? Можно уже кушать?

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

Да - интересно было бы еще сравнение с BEA JRockit. Кстати - Java6 реально порадовал - на реальной прилоге прирост 20%-25%.

Кстати - производительность это ключевая фишка, которая может заставить народ смотреть на Harmony. Я надеюсь это понимает и Apache.

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

А что думает народ о тех "хороших" новшествах, что хотят добавить в Java 7. А именно кол-во зарезервированых слов возрастёт с 83 до 180 + всякие clouures, другой доступ к полям (в стиле PHP - Foo->bar, заместо getField, setField)?

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

>Интересно было бы еще сравнение с BEA JRockit

Sun Java вроде, как с версии 5 "рвёт" JRockit...

>Кстати - производительность это ключевая фишка, которая может заставить народ смотреть на Harmony

Очень сомневаюсь, что Harmony будет более производителен чем Sun Java...

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

>Sun Java вроде, как с версии 5 "рвёт" JRockit...

Что-то не заметил - JRockit 5 на моих тестах (правда искуственных) был чуток быстрее.

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

>Что-то не заметил - JRockit 5 на моих тестах (правда искуственных) был чуток быстрее.

На сайте BEA было сравнение Sun Java 5 и JRockit (какой версии не помню, 4 или 5 версия). JRockit потреблял меньше памяти, но был более медленым.

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

Что народ думает о всяких фреймоврках типа Hibernate, Struts, Spring? Imho, всё это ложный путь и нужно придерживаться технологий компании Sun!

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

>Что народ думает о всяких фреймоврках типа Hibernate, Struts, Spring? Imho, всё это ложный путь и нужно придерживаться технологий компании Sun!

Одно другому не мешает. Вот придумали Hibernate, теперь внимательно смотрим на EJB3 и радуемся.

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

>На сайте BEA было сравнение Sun Java 5 и JRockit (какой версии не помню, 4 или 5 версия). JRockit потреблял меньше памяти, но был более медленым.

я недели 3 назад брал Java5 и JRockit 5 - на некоторых тестах JRockit был быстрее, на других сравнительно одинаково... Но опять же - это ведь искуственные тесты, на реальной работе приложения не проверял.

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

>Одно другому не мешает. Вот придумали Hibernate, теперь внимательно смотрим на EJB3 и радуемся.

Мешает, ибо в объявлениях о работе часто требуют знание сторонних фреймворков. Знать всё не возможно, голова лопнет. Предлагаете сидеть без работы? :)

Смотрим на EJB3 и видим, что есть реализация и на hibernate, и на toplink. Однако, если EJB это ORM+куча вкусностей зачем требовать знать стороний ORM (тот же hibernate)???

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

>Что народ думает о всяких фреймоврках типа Hibernate, Struts, Spring? Imho, всё это ложный путь и нужно придерживаться технологий компании Sun!

Struts - посмотри на JSF (кроме Contoller) Hibernate - уже сказали - посмотри на EJB3.

А теперь давай вспомним о тихом ужасе под названием CMP/BMB (EJB2).

Да и официальная позиция Sun вроде достаточно неплохая - типа народ предлагайте и участвуйте в JCP/dev.java.net.

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

>Struts - посмотри на JSF (кроме Contoller)

Ну и зачем работадатель требует Struts если JSF это из той же оперы???

>Hibernate - уже сказали - посмотри на EJB3.

Ровно тоже самое, зачем работодатель требует Hibernate если есть EJB3?

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

>Мешает, ибо в объявлениях о работе часто требуют знание сторонних фреймворков. Знать всё не возможно, голова лопнет. Предлагаете сидеть без работы? :)

Кому мешает, а кому и помогает. Не нравятся требования - ищем работодателя с другими требованиями или изучаем новое. Технологии Sun далеко не идеальны, но она учится :)

Взять тот же JSP - ну фигня полная в качестве View Layer в MVC фреймворке. Поработав с freemarker я не представляю теперь жизни без него :) - до того удобно.

Hibernate имеет много вкусного, чего нет в EJB.

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

> Ну и зачем работадатель требует Struts если JSF это из той же оперы???

Потому, что у него продукт уже написан на Struts/Hibernate (я надеюсь, все в курсе, что EJB3/JSF вышли позже).

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

>Поработав с freemarker я не представляю теперь жизни без него :) - до того удобно.

А много ли объяв о работе в этим требованием? Получается, что зра потратил время на изучение?

>Hibernate имеет много вкусного, чего нет в EJB.

Прошу перечислить чего нет в EJB3.

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

> Hibernate имеет много вкусного, чего нет в EJB.

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

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

> А много ли объяв о работе в этим требованием? Получается, что зра потратил время на изучение?

Ты как-то странно ищещь работу :)

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

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

>А много ли объяв о работе в этим требованием? Получается, что зра потратил время на изучение? А меня это не интересует в объявах. Я знаю и то и то. Если будет возможность самостоятельно сделать выбор я выберу freemarker. На больших приложениях JSP в качестве View выглядит очень плохо, ровно как и JSF на таких же крупных приложениях.

>Прошу перечислить чего нет в EJB3. Нет Criteria API, нет кучи дополнительных параметров для отображения. Очень сложно разработать приложение исходя из готовой БД. В hibernate много средств для этого.

lexius ★★
()

APACHE HARMONY - это та самая щука, благодаря которой не дремлют в озере караси.

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

>А много ли объяв о работе в этим требованием? Получается, что зра потратил время на изучение?

А меня это не интересует в объявах. Я знаю и то и то. Если будет возможность самостоятельно сделать выбор я выберу freemarker. На больших приложениях JSP в качестве View выглядит очень плохо, ровно как и JSF на таких же крупных приложениях.

>Прошу перечислить чего нет в EJB3.

Нет Criteria API, нет кучи дополнительных параметров для отображения. Очень сложно разработать приложение исходя из готовой БД. В hibernate много средств для этого.

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

>нет кучи дополнительных параметров для отображения. Очень сложно разработать приложение исходя из готовой БД. В hibernate много средств для этого.

Прошу это кратко перечислить т.к. у меня сейчас стоит выбор, что именно учить. Спасибо.

Кстати, что более производительнее EJB3 или Hibernate в плане корректного составления SQL запросов? Что меньше БД нагружает?

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

>Прошу это кратко перечислить т.к. у меня сейчас стоит выбор, что именно учить

Придется видимо и то и другое, только ориентироваться на EJB3 как на стандарт.

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

>Прошу это кратко перечислить т.к. у меня сейчас стоит выбор, что именно учить. Спасибо.

Например несколько вариантов реализации many-to-many отношения, наличие такого параметра как formula.

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

>Кстати, что более производительнее EJB3 или Hibernate в плане корректного составления SQL запросов? Что меньше БД нагружает?

EJB3 - это спецификация. реализация может быть на том же hibernate основана, как в JBOSS. Так что тут бессмысленно спрашивать что производительнее.

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

>Из последнего - это поддержка lucene в аннотациях, что меня очень обрадовало.

Не расскажите подробней? Как, где, для чего может быть использованно? :)

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

>Не расскажите подробней? Как, где, для чего может быть использованно? :)

Для полнотекстового поиска. Русская морфология поддерживается.
http://www.google.com.ua/search?q=java+lucene

Поле бина аннотируется примерно как
@Field(name="name", index=Index.TOKENIZED, store= Store.NO)
и вперед...

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

> Однако, если EJB это ORM+куча вкусностей зачем требовать знать стороний ORM (тот же hibernate)???

Причина в том, что EJB2 был очень своеобразной вещью, а его ORM похоже вообще никому не нравился, вот и возник Hibernate и т.д. А теперь уже поздняк метаться с EJB, если в фирме другие фреймворки освоены.

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

Для интересующихся ORM типа Hibirnate & EJP3 рекомендую обратить внимание на JDO и в частности его реализацию jpox.org JDO - это стандарт http://www.jcp.org/en/jsr/detail?id=243

Вот сравнение JPA (то что в EJP3 отвечает за ORM) и JDO http://www.jpox.org/docs/persistence_technology.html http://www.jpox.org/docs/1_2/jdovsjpa.html

Сравнение производительности jpox с Hibirnate

http://www.jpox.org/docs/performance.html

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

>А теперь давай вспомним о тихом ужасе под названием CMP/BMB (EJB2).

Вы не учитываете что если бы не появилось сторонних ORM мапперов которые не были таким тихим ужасом как CMP и уж тем более BMP - то все и осталось бы так как было.

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

>Ну и зачем работадатель требует Struts если JSF это из той же оперы???

Потому что если пишешь не хомепаги по месяцу - то имеется быть наличие проектов более старых. Или думаешь все тут же бросаются все перепиывать под "правильную" технологию как сан зарелизит новую спеку?

>Ровно тоже самое, зачем работодатель требует Hibernate если есть EJB3?

Хотя бы потому что hibernate отдельный продукт, а под EJB3 требуется аппсервер.

К стате hibernate ацтой - OJB рулид.

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

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

И что?

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

>Кстати, что более производительнее EJB3 или Hibernate в плане корректного составления SQL запросов? Что меньше БД нагружает?

EJB3 - это спецификация. Hibernate - это ORM библиотека. "Почувстсвуй разницу" (C)...

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

>Пока это голые слова, факты, где факты?

У меня появилась необходимость как-то вписать поддержку новой платформы, которая не поддерживалась hibernate и OJB. У нас все было на hibernate. Когда полез во внутрь - захотелось блевать, заязки на конкретные реализации, циклические зависимости, классы по несколько тысяч строк кода, никакой возможности замены имплементаций, дурацкие интерфейсы - типа в зависимости от того будут ли bound параметры один и тот же мтод list запрашивается у совершенно разных объектов, фанацкая позиция Гейвина по поводу транзакций - он считал (может с тех пор поумнел) что все должно выполнятся в транцакции и если ее не начал юзер - то hibernate начинал ее сам, (но не завершал - ахренеть), тогда не было criteria api. Конечно это было больше 2х лет назат и с тех пор hibernate приютился у JBoss и насколько я слышал его полностью переписали. Но впечатления у меня остались неизгладимые.

А с OJB все прошло на ура - надо генерировать "иной SQL" для другой платформы - да раз плюнуть, любая имплементация заменяется в конфиге, код вполне вменяемый и логичный, легко писать, легко модифицировать, даже не влезая в саму реализацию OJB - просто в конфиге указал свои классы и все, намного более приятный интерфейс.

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

>Вы не учитываете что если бы не появилось сторонних ORM мапперов которые не были таким тихим ужасом как CMP и уж тем более BMP - то все и осталось бы так как было.

Кхе, кхе - я что-то имел против (писал) сторонних фреймворков? Не запутались в комментах :)

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

>Хотя бы потому что hibernate отдельный продукт, а под EJB3 требуется аппсервер.

EJB3 Persistence API не требует Application Server.

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

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

>И что?

Т.е. изменяющее API и философия каждый месяц - это хорошо для Вас?

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

>Т.е. изменяющее API и философия каждый месяц - это хорошо для Вас?

А вы что считаете что вы такой умный и понимаете зачем не надо каждый месяц менять АПИ и философию, а разработчики struts идиеты этого не понимающие?;)

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

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

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

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

>А вы что считаете что вы такой умный и понимаете зачем не надо каждый месяц менять АПИ и философию, а разработчики struts идиеты этого не понимающие?;)

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

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

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

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

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