Хотелось бы узнать, насколько целесообразно использование фич Java 5 при программирования ядра системы, если общение с интерфейсом будет происходить посредством протокола XML-RPC. Т.е. хотелось бы узнать, не будет ли там заморочек с несовместимостью?

Более подробную информацию об использованных технологиях и библиотеках предоставлю по первому требованию.

Заранее спасибо.

simanyay, передо мной тоже такая проблема стоит, но вот, что я тебе скажу - был пол-года назад на конференции BEA, где они рассказывали, что они ещё внедрят в Diablo (WLS 9) и там прозвучало, что он будет рассчитан на то, что бы крутиться всё ещё на четвёртом JRockit`е. Они это объяснили так, что пятая JVM ещё не достаточно стабильна и не устоялась, по-этому они пока ждут...

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

Цитата(simanyay @ 2.7.2005, 19:29)

Более подробную информацию об использованных технологиях и библиотеках предоставлю по первому требованию.

А у тебя какой контейнер?

Я вот тоже думал перескочить на Java 5, но на тот момент в качестве контейнера использовал JBoss 4, а он не работает с пятеркой. А потом (во многом благодаря многочисленным дискуссиям в форуме Винград!) я все порефакторил, выкинул все EJB, и смог впихнуть свое приложение в рамки веб контейнера - без потери функциональности, со значительным упрощением структуры кода и облегчением среды разработки и выполнения.

Теперь у меня все мослает в Tomcat 5.5 под Java 5, чего и вам желаю

Цитата(Stampede @ 14.7.2005, 19:39)

А у тебя какой контейнер?

Tomcat 5.5

Я пока на 1.4.

В 1.5. убрали xml а у нас много кода под него. Неохота переделывать. Да и все-таки 5-ка пока не много времени работает. Надо подождать.

Цитата(AntonSaburov @ 14.7.2005, 18:07)

В 1.5. убрали xml

???

А можно по-подробнее? JAXP убрали, что ли?

Цитата

А можно по-подробнее? JAXP убрали, что ли?

Я не могу сказать с уверенностью, но когда я стал пытаться собирать наш проект под 1.5, то мне на пакет org.xml.sax вывалили кучу ошибок. И после этого я был вынужден снести. Может я и ошибаюсь. Т.к. глубоко не копал.

Цитата(AntonSaburov @ 15.7.2005, 11:58)

когда я стал пытаться собирать наш проект под 1.5, то мне на пакет org.xml.sax вывалили кучу ошибок

Может, новую версию SAX`а придумали, не совсем совместимую с прошлой?.. Обидно. Лан, будем знать...

Просто вы не умеете её готовить.

Всё у пятёрки нормально с совместимостью. Перешли и радуемся.

В пятой версии библиотеки для работы с XML не убрали. Их просто частично переименовали. Другое дело, что из серверов реально с ней пока работает только Apache Tomcat (v. 5.5), а это не самый быстрый движок, да и с функциональностью у него туго - только основные библиотеки для работы с веб и некоторые апачевские (с Jakarta) расширения. J2EE-совместимые серверы пока JDK 5.0 не поддерживают, за исключением апдейта Sun JS Application Server, однако он в новой версии пока практически бета: пробовал поставить - иногда выдавал ошибку при установке Pointbase. Так что для корпоративных решений ПОКА лучше юзать 1.4.

Цитата

Другое дело, что из серверов реально с ней пока работает только Apache Tomcat (v. 5.5)

вот блин
а какие еще серверы вы пробовали гонять?
JBoss пробовали?

Хм... насколько я помню, JBoss не является сервером приложений в полном смысле, это просто набор библиотек. И вот прикрутить этот набор к Tomcat 5.5 у меня в своё время не получилось... Хотя, возможно, я просто невнимательно смотрел.

Проблемы с совместимостью - это одна сторона вопроса. А какие преимущества даст переход? Мне кажется, что уже в 1.1 было все достаточное для работы.

Может ли кто-нибудь назвать нововведения, которые им были остро необходимы и теперь как только 1.5 признают стабильной, то надо сразу ее и внедрять.

Это сообщение отредактировал(а) COVD - 22.8.2005, 16:15

Кстати, не знаю, почему, но я никогда не видел в работе версии 1.3. Только 1.2 и 1.4. Ну и новую.

сдается мне, как не прискорбно - M$ доволно быстро переберет все лучшее ... и увы и ах ... прийдется ориентрироваться на .asp %((( .... пока ту и там копъя ломать будут по поводу 1.5 и далее, и софт
_корявить_ под эту платформу ...

Это сообщение отредактировал(а) Sleepy_PIP - 22.8.2005, 17:10

Цитата(COVD @ 22.8.2005, 16:11)

Может ли кто-нибудь назвать нововведения, которые им были остро необходимы и теперь как только 1.5 признают стабильной, то надо сразу ее и внедрять.

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

Цитата

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

да и кастинг, как говорят, относительно тяжелая операция. Интересно, кроме удобства, ощутили ли вы еще и прибавку в производительности?

Цитата(COVD @ 23.8.2005, 15:52)

Интересно, кроме удобства, ощутили ли вы еще и прибавку в производительности?

Самой программы? А это важно?
Удобство = производительность программиста, быстрее пишущего и отлаживающего более понятный код, а эта производительность существенна - потому что за равные интервалы времяни, за которые ему надо платить зарплату, он сможет сделать больше работы

Цитата

Хм... насколько я помню, JBoss не является сервером приложений в полном смысле, это просто набор библиотек.

по каким параметрам JBoss не является сервером приложений?

Цитата(sandello @ 29.8.2005, 07:21)

по каким параметрам JBoss не является сервером приложений?

Нету своего сервлет-контейнера у него вроде... Хотя может в последних версиях и появился, но традиционно его ставят вместе с Tomcat`ом...

ИМХО, необязательно, что бы сервлет контейнер был самописный. Главное, что бы был. В JbossAS входит сервлет контейнер. Сейчас это томкат. Когда-то был Jetty (кажется).

Цитата(COVD @ 23.8.2005, 15:52)

Цитата generics - честно говоря, без них с коллекциями работать неудобно - всё время преобразовывать туда-сюда - запутаться можно. да и кастинг, как говорят, относительно тяжелая операция. Интересно, кроме удобства, ощутили ли вы еще и прибавку в производительности?

Никакого прироста производительности самой программы только за счет generics вы не получите, т.к. generic-и являются сплошным обманом трудового народа , а именно - средством препроцессора. Показываю:

Код

import java.util.*; public class Test {   public static void main(String[] args)   {     ArrayList<String> list=new ArrayList<String>();     list.add("Hello world!");     String result=list.get(0);   } }

Компилируем, а затем декомпилируем (jad-ом, с опцией -a - чтобы видеть байт-код):

Код

// Decompiled by Jad v1.5.8e2. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://kpdus.tripod.com/jad.html // Decompiler options: packimports(3) annotate  // Source File Name:   Test.java import java.util.ArrayList; public class Test {     public Test()     {     //    0    0:aload_0              //    1    1:invokespecial   #1   <Method void Object()>     //    2    4:return               }     public static void main(String args[])     {         ArrayList arraylist = new ArrayList();     //    0    0:new             #2   <Class ArrayList>     //    1    3:dup                  //    2    4:invokespecial   #3   <Method void ArrayList()>     //    3    7:astore_1                 arraylist.add("Hello world!");     //    4    8:aload_1              //    5    9:ldc1            #4   <String "Hello world!">     //    6   11:invokevirtual   #5   <Method boolean ArrayList.add(Object)>     //    7   14:pop                      String s = (String)arraylist.get(0);     //    8   15:aload_1              //    9   16:iconst_0             //   10   17:invokevirtual   #6   <Method Object ArrayList.get(int)>     //   11   20:checkcast       #7   <Class String>     //   12   23:astore_2             //   13   24:return               } }

Как видим - никаких generic-ов, честный cast. Для сравнения пишем тот-же код без generics (с явным кастом), компилируем - получаем тоже самое.

Generic-и облегчают работу разработчика и за счет этого упрощают разработку, что косвенно может приводить к улучшению производительности, но сами они производительность не улучшают.

Цитата

был пол-года назад на конференции BEA, где они рассказывали, что они ещё внедрят в Diablo (WLS 9) и там прозвучало, что он будет рассчитан на то, что бы крутиться всё ещё на четвёртом JRockit`е. Они это объяснили так, что пятая JVM ещё не достаточно стабильна и не устоялась, по-этому они пока ждут...

Ребята не сдержали слово - 9-ка вышла и она на JRockit`е 5`ом. Так что зелёный свет Java 5!

2Lerm: Спасибо! Меня интересовал именно этот аспект, потому что приложение уже написано на 1.4 .

2 se la vi :

Цитата

Самой программы? А это важно?

Производительность самой программы важна, когда клиент имеет доступ к нескольким конкурирующим сервисам. Например, клиент запускает одновременно два апплета от разных провайдеров. Естественно, клиент предпочтет продукт, который работает более устойчиво и быстро при прочих равных качествах.


Это сообщение отредактировал(а) COVD - 2.9.2005, 16:09

COVD, ты верно говоришь, но заказчики, как правило, по-другому расставляют приоритеты, что порождает разные схемы написания софта. Есть и такие, при которых код пишется быстро-быстро, тяп-ляп что бы только хоть какт-то в педально-вёсельном режиме работало, а потом, когда к нему возникают притензии по качеству работы - подвергается рефакторингу. При такой схеме и вотлки сыты и овцы целы - всё зависит от специфики заказа...