См. http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html

>Улучшеная производительность

Как всегда. ))))

>Дождались!

Что значит дождались ???
всего лишь beta-b32c
У некторых эти беты уже месяцами стоят ....

Открытое письмо Sun к Eclipse

в javac
-d32
-d64
меня не порадовали
начнется хаос классов для 32 и 64 архитектуры

>-d32
>-d64
>начнется хаос классов для 32 и 64 архитектуры

1 это же компилируемый язык, а не интепретатор
2 ты хочешь что бы они автоматически удвоили размер простых типов ?

Не понял, что удваивать? В Java и так есть 64-битный целочисленный тип - long.

Кто нибудь смотрел?
Контейнеры и итераторы в пакете util уже в дженериках?

> в javac > -d32 > -d64 > меня не порадовали > начнется хаос классов для 32 и 64 архитектуры

Не боись! Это какой-то фуфел в доке. Эти ключи были ещё в 1.4.0, только для hotspot server jvm: The SolarisTM-SPARCTM platform edition of J2SDK 1.4.0 will support 64-bit operation on 64-bit Sparc-v9 platforms when using the Java HotSpot Server VM. With a 64-bit address space, more than four gigabytes of heap memory is available. The Java HotSpot Server VM includes support for both 32-bit and 64-bit operations, and users can select either 32-bit or 64-bit operation by using command-line flags -d32 or -d64, respectively.

> Контейнеры и итераторы в пакете util уже в дженериках?

Да, и ThreadLocal тоже!

Не было бы .Net с его удобнейшим C#'ом и возможностью писать на многих других языках - так бы и не дождались изменений в самом языке. Так бы и кропали на убогенькой Java :(

> Не было бы .Net с его удобнейшим C#'ом и возможностью писать на многих других языках - так бы и не дождались изменений в самом языке. Так бы и кропали на убогенькой Java :(

Естественно. Со времен развитого социализма известно, что конкуренция повышает качество продукции ;-)) А вот насчет убогости, скажем, Явы 1.4 уважаемый, Вы слегка погорячились...

2birdie:
Какое отношение JRE имеет к синтаксису языка?

2Eugeny_Balakhonov:
Не трынди - а? Как можно хвалить эту систему костылей и подпорок? Шаг влево, шаг вправо от MSDN'овского экзампла и уже обнаруживаешь нестандартное поведение стандартных компонентов. Но хрен с ним. Это у них видимо уже никогда не будет исправлено. Это у них в крови. Но вот что, ЧТО же удобного есть в C#? Весь этот язык - одна сплошная насмешка над ООП. VB c Си подобным синтаксисом, понапридумывали кучу новых сущностей, а простая перегрузка метода делается через известное место. Реализовали за каким-то хреном foreach, который ходить умеет только по тем кто имеет getEnumerator... Нахрена, спрашивается синтаксис языка завязывать на API, опять же чем не понравился while? Опять же чем не понравилось использование интерфейсов? Опять же коллекции с данными разных типов возвращают разные типы null'ов... Это и есть, так называемые удобства? А угрёбище под названием delegate? Это вообще ни борщ ни в красную армию - типа вернемся к тому, как это делали в процедурных языках. В общем жуткая смесь, которая хороша как замена VB, но до лаконичности и полноты Java ей как пешком до луны. И до многоязычности... хе хе... пара диалектов слизаных с одного шаблона... извратище.

> Не было бы .Net с его удобнейшим C#'ом и возможностью писать на многих других языках

А вы пробывали писать на managed C++, другой язык для .NET кстати?

Там есть проблемы которые можно обойти только написав часть кода на С#.
Например посмотрите на Enum::Parse и попробуйте распарсить им на C++ строку и присвоить результат парсинга например в Control->Dock

Или поробуйте изменить DataSource у DataGrid (да вообще любое свойство которые вызовет перерисовку визуального компонента) не из главного потока приложения.
Они даже для теоритического обоснования этой кривизны придумали UpdateUI Design Pattern.

>в javac
>-d32
>-d64
>меня не порадовали


Не в javac, а в java ..... чуствуешь разницу ? :)

Это они описамшись в запарке :)

$ java -help
<....>
where options include:
-d32 use a 32-bit data model if available
-d64 use a 64-bit data model if available
<....>

$man javac
<....>
-d directory
Sets the destination directory for class files
<....>

> Или поробуйте изменить DataSource у DataGrid (да вообще любое свойство которые вызовет перерисовку визуального компонента) не из главного потока приложения.

А в Свинге что, не так?

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

eXOR, а вам не кажется, что чисто ОО-подход, как и чисто процедурный, панацеей не являются? Мне, например, кажется более удобным синтаксис делегатов, чем Listener'ов в Яве. Понимаете, и на Яве, и на Шарпе можно писать и процедурно, и объектно-ориентированно. Просто Микрософт облегчил жизнь тем, кто пишет на Шарпе процедурно. А сторонники чистого ОО-подхода могут сами реализовать концепцию листенеров, благо это не так уж и сложно.

>А еще прикольная возможность за которую давно торбили разработчиков сдвинулась с мертвой точки. Теперь системные классы могут шарится между разными JVM, что очень поможет для клиентских программ и обещали далее развивать идею совмесного использования классов (и пользовательских тоже) в разных JVM.

да уж пора ось писать для жабы

дк это какая-то Java3 понимаешь ли

> дк это какая-то Java3 понимаешь ли

Да, хороших изменений очень много. У меня аж настроение поднялось.

>>А вот насчет убогости, скажем, Явы 1.4 уважаемый, Вы слегка
>>погорячились...

Я имел ввиду Java не как технологию, а как сам язык. После С++ чувствуешь себя с каменным молотком в руках :(
Больше всего мне не хватает препроцессора и перечислимых типов. Последнее похоже, наконец, вернули.

Re:

> хреном foreach, который ходить умеет только по тем кто имеет getEnumerator... Нахрена, спрашивается синтаксис языка завязывать на API, опять же чем не понравился while?

Не, итераторы и слайсы - штука хорошая :-). Не надо их обижать

А что мешает написать на Яве листенер процедурно? :))) У Явы достаточно гибкий синтаксис для этого :)

2kwas:
Лично мне больше нравится ОО-подход. Но процедурный подход не является плохим, и если нужно я легко могу думать и его терминами. Одна проблема. Если в рамках одного проекта разные разработчики пишут по разному. ОЧЕНЬ сложно разбираться в таком коде. Java навязывает ОО подход, Java навязывает стиль именования, Java ограничевает свободу, НО. Java, как язык делает подход до определенного уровня единым (конечно если человек упертый, то... но с этим уже ничего не поделать). Еще раз. Я не против процедурного подхода, я против смешивания подходов. И потому, во избежание недоразумений лучше писать на ОО языках в терминах ОО, а на процедурных языках в терминах процедурных языков (инструменты надо выбирать по задаче). Java сделала шаг вперед, после C++, C# шаг назад.

2Eugeny_Balakhonov

>Не было бы .Net с его удобнейшим C#'ом и возможностью писать на многих других языках

Возможность сделать компилятор/интерпретатор для любого языка существует не только для .net, но и для JVM (и есть работающие примеры - JGNAT, Jython, etc.). Другое дело, что за приспособление языка к объектной модели C# или Java нужно платить либо полным извращением исходного языка, либо плохой совместимостью с "платформой". Это м.б. и не страшно, если язык и до того был извратом и в каждой версии менялся вместе с текущей политикой поставщика (как VB и Delphi). Но это неприемлемо в случае достаточно стандартного, стабильного и разумного языка (я не говорю "удобнейший", удобство субъективно по определению). Версии Eiffel и Oberon (Zonnon) для .net - это уже не Eiffel и не Oberon, это скорее C# с другим синтаксисом. А Ada, которую извращать нельзя по стандарту, может быть реализована на .net, только что это ей даст, кроме тормозов?

Так что пресловутая "многоязыковость" .net - обычный рекламный трюк (один из многих), с таким же успехом можно говорить о "многоязыковости Java".

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

Как это ни странно, но именно ООП-подход прекрасно уживается с разными стилями. К примеру, взгляните на тот же $JAVA_HOME/src.zip - интерфейсы классов бесспорно сделаны с претензией на единообразие, но как разнятся стили подходов, заложеных в их реализациях!

Так что, правильный (и даже разумный) ООП-подход ничего не имеет против, если реализация какого-то класса будет процедурной. Да, и вообще, не стоит ставить "телегу впереди лошади". Главное, использовать то решение, которое лучше подходит для задачи. А уж, оформить потом для него объектную оболочку - лишь дело техники :)

>>После С++ чувствуешь себя с каменным молотком в руках :(
А просто посмотреть на дело с другой стороны не пытались?

>>Больше всего мне не хватает препроцессора и перечислимых типов
Точно, а иномарке вам наверное не хватает подсоса...
А че, полезная штука ...

То что в Жабе повыкидывали некоторые (с одной стороны полезные вещи), говорит о том, что кто-то хорошо над этим подумал... И не стоит так с кондачка говорить что это неправильно.. Проиграли в гибкости, выиграли в очень многих местах...

>да уж пора ось писать для жабы

http://jos.sf.net

>к объектной модели C# или Java нужно платить либо полным извращением
>исходного языка, либо плохой совместимостью с "платформой".

Это действительно так, только есть один маленький нюанс - JVM это
специализированная машина для исполнения программ на Java поэтому,
все, что пытались перенести на jvm длагополучно почило в бозе.

.net - изначально проектировалась как многоязыковая среда.

Вот Вы приводите в пример jgnat - так ведь он помер. В 2000 году вышла
последняя версия jgnat1.1p, которая скончалась так и не достигнув
половой зрелости. Тоже случилось и с jython. С другой стороны
Ada# (http://www.usafa.af.mil/dfcs/bios/mcc_html/a_sharp.html -
академия ВВС США ) соответствует gnat3.15 - последней GPL реализации
Ada.

Хотя действительно - делать Ada для jvm или .net - довольно странно,
но если думать об Ada не только как о языке для программирования RT
систем, а и как о супернадежном OO языке общего назначения ( чем она
безусловно является ), то например возможность использования большой
библиотеки классов .net очень неплохая штука. Тем более, что пока в
Ada нет стандартной библиотеки для создания пользовательского интерфейса (если не брать в расчет GtkAda, но она нормально не работает в Windoze), а в .net она есть ... хотя это конечно плохой
пример.

>То что в Жабе повыкидывали некоторые (с одной стороны полезные вещи),
>говорит о том, что кто-то хорошо над этим подумал

Например в Ada c 87 года перегрузка операторов присутствует.
Скорее это говорит о том, что некоторые разработчики ( гослинг )
страдают излишними религиозными предрассудками по отношению к С++.

Ну а если серьезно, почитайте Патрика Нотона, он очень хорошо описывает как все происходило.

>Проиграли в гибкости, выиграли в очень многих местах
дайте угадаю ... в геморрое?


Captain.

>http://jos.sf.net

да сдох этот проект столет назад

>>Больше всего мне не хватает препроцессора и перечислимых типов
>>Точно, а иномарке вам наверное не хватает подсоса...
>>А че, полезная штука ...

...

>>То что в Жабе повыкидывали некоторые (с одной стороны полезные
>>вещи), говорит о том, что кто-то хорошо над этим подумал... И не
>>стоит так с кондачка говорить что это неправильно.. Проиграли в
>>гибкости, выиграли в очень многих местах...

Видать думали не тем местом, раз в 1.5 приходится возвращать назад.
Без enum'ов вообще кошмарные вещи приходится делать: либо эмулировать enum'ы классами, создавая толпу лишних классов в проекте, либо ручками выписывая

public static final int MODE_DEFAULT = 0;
public static final int MODE_FORCE = 1;
....

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

А насчет препроцессора, расскажите как на Java сделать такую простую вещь без препроцессора:

Пишу софтинки для сотовых телефонов. Базис у всех KVM один - J2ME MIDP 1.0. Но дополнительные классы, вроде вывода звука, музыки и т.д. у всех свои. Например у Siemens это набор классов com.siemens..., у Nokia - com.nokia..... Хочется из одних сорцов компилять два разных кода. Как это сделать на Java? На C++ - не вопрос. А тут?

Держать два набора разных сорцов и их синхронизировать? Или руками комментарить то одно, то другое? Закат солнце вручную.

>C# шаг назад

Подсадить всех пользователей сначала на иглу Windows потом всех разработчиков на иглу .NET

Политика монополиста. Есль только мы. Отсальному права на жизнь ни кто не давал.

>Держать два набора разных сорцов и их синхронизировать? Или руками комментарить то одно, то другое? Закат солнце вручную.

Да. Проблема. :((( ant не поможет?

>А насчет препроцессора, расскажите как на Java сделать такую простую вещь без препроцессора:

Можно использовать препроцессор из Си.

>>Но дополнительные классы, вроде вывода звука, музыки и т.д. у всех свои

Блин, и эти люди запрешают мне ковыряться в носу (с).

Интрерфес я надеюсь у всех одинаковый?? к приеру Music_int

String [] stupid = { "com.nokia", "com.siemens" };
Music i_usage_now = (Music_int) Class.forName(stupid[0]).newInstance();

Ну екзепшины я так думаю дописать сами сумеете...

P.S. я вам не зря посоветовал посмотреть на проблему с другой стороны... Неужели вы думаете что до Вас с этим никто не сталкивался??
Кстати, в приведенном случае вам даже билд не надо отдельный делать.. Просто в аргументах передвайте че хотите юзать..

> что пытались перенести на jvm длагополучно почило в бозе.

Однако здоровый могильник ты не находишь?:

http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html

> . Хочется из одних сорцов компилять два разных кода. Как это сделать на Java? На C++ - не вопрос. А тут?

> Держать два набора разных сорцов и их синхронизировать? Или руками комментарить то одно, то другое? Закат солнце вручную.

Прочитать GoF: design patterns.

> Пишу софтинки для сотовых телефонов. Базис у всех KVM один - J2ME MIDP 1.0. Но дополнительные классы, вроде вывода звука, музыки и т.д. у всех свои. Например у Siemens это набор классов com.siemens..., у Nokia - com.nokia..... Хочется из одних сорцов компилять два разных кода. Как это сделать на Java? На C++ - не вопрос. А тут?

Ну-у-у, батенька...

Если в коде нужно подключать разные пакеты, для этого пишется (или берется готовый интерфейс) и используется порождающий паттерн, например, Factory. А сборка весьма просто решается Ant-овским скриптом: в ./build переносится код по маске имени пакета (com.nokia.* | com.siemens.*), да там и собирается.

ant build-nokia - получите сборку для Нокии, ant build-siemens - соответственно, для Сименс, ant build-all - все сразу.

p.s. Сколько раз наблюдаю сишников, ругающих Ява за неудобство и отсутствие тех или иных фич - столько и убеждаюсь, что в 99% случаев люди толком не знают языка или готовых утилит для своих задач. То им enum'а нет (см. J.Bloch "Effective Java", статья 21), то препроцессора(см. выше).

> Можно использовать препроцессор из Си.

Да вы люди вообще охренели. Препроцессор нужен там гдле происходит статическое связывание. В java раздельная компиляция. Продекларируй интерфейс и клади рядом имплементации. Всем курить GoF.

>>Прочитать GoF: design patterns.

читать это все не серьезно .. %)

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

>P.S. я вам не зря посоветовал посмотреть на проблему с другой стороны..

Ага. И сименс засунуть библиотеки для нокии, и, соответственно, наоборот.

ПРОЧИТАЙ ЗАДАЧУ, И ПОДУМАЙ...

>>ПРОЧИТАЙ ЗАДАЧУ, И ПОДУМАЙ...

Ой йо йой %))
как мы огрызаемся...
"засовывать" вы будите в CLASSPATH.. не нужна вам либа, просто не ложите ее если это критично...

>JVM это специализированная машина для исполнения программ на Java поэтому, все, что пытались перенести на jvm длагополучно почило в бозе. .net - изначально проектировалась как многоязыковая среда.

Виртуальная машина .net очень похожа на JVM и можно с таким же успехом сказать, что это "специализированная машина для исполнения программ на C#", а для др. языков она подходит постольку, поскольку они совместимы с C#. То же со стандартными библиотеками .net - их интерфейс описан на C#, использовать их из др. языков возможно и удобно лишь в меру их совместимости с C#. Ядро .net проектировалось не как многоязыковая среда, а как runtime для группы похожих языков. Языки, копирующие объектную модель C# и отличающиеся лишь синтаксисом, со временем увянут (так же, как jgnat и jython), в них просто нет смысла. В конечном счете все, кто использует другие языки на .net все равно перейдут на C# (либо, кто посмелее, уйдет от MS). Но MS необходимо было подслатить эту пилюлю для толпы юзеров VB, C++, Delphi, отсюда и вся болтовня о якобы многоязыковой среде. Уж что-что, а создавать иллюзии MS умеет.

>Видать думали не тем местом, раз в 1.5 приходится возвращать назад.

Ошибки неизбежны при проектировании любой системы. Думали как раз основательно: и к папе-Вирту с его Обероном за консультациями ездили, и UCSD P-system вспомнили основательно. Просто доводят Яву до ума, аккуратно и не спеша, не ломая совместимость. Кое-что (generic types, enhanced for) было малополезно без Collections Framework'а, кое-что (metadata) - не востребовано в 95-м году.

Так что, "Правопорядок определяется не наличием воров, а умением милиции их ловить и возвращать украденное" (с) Г.Жеглов.

btw. А Вы пробовали в .Net VB 2003 создать C#-приложение, а потом его запустить в winXP? И как, ничто не напрягло, типа "Wrong .Net framework version..." (за точность сообщения не поручусь, ибо сабжа под рукой не имею)?

> Без enum'ов вообще кошмарные вещи приходится делать: либо эмулировать enum'ы классами, создавая толпу лишних классов в проекте,

И это 100% правильно, поскольку enum - сишная, процедурная конструкция, и ничто в языке не мешает сделать из него винегрет, а потом долго печально смотреть на ClassCastException в километре по коду. А "толпа классов" (на самом деле - один полностью статический класс) может дать удобное строковое представление, иметь собственный компаратор для эффективной сортировки в списках (если утрудить себя перекрытием toString() и реализацией Comparator) и т.д. и т.п.

Вы будете смеяться (или плакать, уж не знаю), но Блох сказал, что на самом деле конструкция enum в 1.5 создает ne cfve. "толпу класов". Просто рутинную работу переложили на компилятор, что есть Ease of Development. Логично?

Извиняюсь, .Net VB 2003 читать как .Net VS 2003.

>"засовывать" вы будите в CLASSPATH.. не нужна вам либа, просто не ложите ее если это критично...

Во костыли придумал!!! Что-нибудь про "правильность" программы слышал?

>>Во костыли придумал!!! Что-нибудь про "правильность" программы слышал?

Это уже даже не смешно... но с удовольствием (как и другие) послушаю коротенечкую лекцию о "правильных" програмах... заодно со сслыками на какие либо источники.

>Это уже даже не смешно... но с удовольствием (как и другие) послушаю
>коротенечкую лекцию о "правильных" програмах... заодно со сслыками на
>какие либо источники.

Да легко! Вот парочка теорем:

1) Чтобы программный блок был правильным, необходимо, но недостаточно чтоб он имел один вход, и один выход.

2) Если на вход блока поступают правильные данные, и на выходе его правильные данные, такой блок счетается правильным.

3) Если все блоки программы являются правильными, то и программа является правильной.

Где-то так. За точность формулировок зуб не дам, но смысл такой.

В твоем случае (если нет требуемых библиотек), даже если на вход блока подаются правильные данные, то на выходе ВСЕГДА будут неправильные. Твоя программа неправильная. И не надо мне говорить, что эта часть кода ни когда не выполнится. Законы кибернетики не исключают такую возможность.

А источники ищи сам. Не досуг мне к букварям тебя направлять.

> А источники ищи сам. Не хотелось бы хоть глазком взглянуть. Пункт 2) на редкость занимателен.

>Пункт 2) на редкость занимателен.

Этой теореме есть вполне вменяемое доказательство (я его, естественно, не помню). Есть и программно реализованные доказательства правильности кода. Когда-то во времена ЕС видил что-то стибренное от IBM. Кажется это было для кабола.

А книжек по этой теме навалом. Только я их названия не помню. Ибо лекции по теме слушал аш 1987-м году. Многи с ЛОРа тогда еще у папки в яйцах болтались. :)))