первое что нужно сделать это определиться кто будет дальше поддерживать яву а кто нет

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

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

Nativnye compilery est' ono - JOVE i JET No ono nado?

iz vsego vysheskazannogo soglasen s peredelkoj SWING'a

Про XML - не согласен категорически. Сделать жабу еще тормознее - кому это нужно! Все-таки name=value парсится на порядок быстрее, память жрет меньше и просто проще для восприятия. Так, воообще, можно далеко зайти - сказать, что все данные будут хранится только в СУБД. XML - замечательная вешь, но не надо ее пихать во все дыры!

Про простые типы данных - это очень правильно! Даешь!

Про загрузку классов - может, рихтовка и нужна, но не очень. Не нужно бардака в приложениях делать - и проблем с лоадерами будет меньше. А если свой лоадер пишешь (как, например, в jEdit) - разбирайся в том, что делаешь.

Пишу на жабе 6 лет - знаю, о чем говорю.

10. Убрать все устаревшие классы, методы, поля и интерфейсы

убрать яву как устаревший элемент IT

11. proper tail recursion 12. oop a-la clos

Яву уже не уберут. Как и Кобол. Ибо количество вбуханных бабулек перешло некий предел.

А если по существу - совсем это неплохая вещь. Да, есть детали, нуждающиеся в пересмотрении. Но основные идеи вполне здравы и разумны (хотя и не революционны).

Хотеть то можно ;)

Хороший такой язычек под названием Java был года так 4 назад. Апплеты -просто супер! Изучение объктно-ориентированной парадигмы при переходе от C к Smalltalk - выше всяких похвал!!!

А потом появился монстр JSP/JSTL. потом J2EE. А потом WSTK. (Кстати сановцы сами признали, что цепочные XML преобразования-то глючат - о чем я неоднократно говорил на форуме, а меня убеждали, что все работает ;))

Вот ссылочка:

http://java.sun.com/webservices/docs/1.0/tutorial/doc/JAXPXSLT9.html#72462

"Note: This output was generated using JAXP 1.0. However, the first filter in the chain is not currently translating any of the tags in the input file. Until that defect is fixed, the output you see will consist of concatenated plain text in the HTML output, like this: "Title of my (Docbook) article Title of Section 1. This is a paragraph."

Хоть и неверующий, но возблагодарю Господа, что сейчас мне лично на Java 2 работать не приходится и закажу панихиду по безвременно почившему монстру доктора Франкенштейна (sorry, доктора Гослинга)

Хммм... Интересный списочек. А в .NET это все уже с самого начала есть. Ко всему было бы неплохо добавить пунктик - сделать яву официальным стандартом, а не личной собственностью sun microsystems. Но мне кажется что сановцы скорее удавятся чем так сделают.

... и first-class functions (как необходимая добавка к clos), и first-class continuations всех возможных видов ...

.net зачяточно

Наиболее серьезная проблема Javы это запуск кода в стеке - пока
не будет решена эта проблема серьезно говорить о использовании явы
вообще не приходится. Тем более согласно стандартам Posix исполняемый
код сгенерированый jit компилятором следовало бы помещять в разделяемую
память с установленным аттрибутом "права на выполнения", а вовсе не в
стек.

Другая проблема надо чтото делать с обработкой событий при наследовании классов

Niks, а ты вообще политическая проститутка.
.NET лучше явы, блин, идиоту понятно, что лучше, ибо делали, ее не 10 лет назад, а 3 года назад, когда уже было известно о все достоинствах и недостатках ява.

У дотнет есть мультиплатформенная GUI библиотека? Тот-то же.
Вообще о мультиплатформенности говорить смешно: почему-то все вспоминают поделие шлюхи и мрази Иказы. В .net мультиплатформенны только6 программы, которые скаладывают 2+2 и пишут Hello World.

Linux тоже как десктоп хуже чем виндовс и что? теперь посетителям этого сайта садиться на windows?
Java - это политически правильный язык.

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

А что не так с этой самой обработкой событий?

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

2oduvan:

swing (english): http://java.sun.com/docs/books/tutorial/uiswing/index.html http://developer.java.sun.com/developer/onlineTraining/GUI/Swing1/shortcourse...

na russkom: http://www.javapower.ru/java/main.htm

ciao, ado

А причем тут я? Я в жизни не буду писать ничего под вонючей лицензией GPL. Она ЧМО и ацтой!

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

а на microsoft.com написано, что Linux одна большая природная дыра в секурности. И кто хоть что-то заботится о безопасности, от linux должен бежать сломя голову.

Не, писать на Java удобно. Особенно мне понравились веб-приложения на JavaServlets. Жаль что только в ней слишком много урезали от С++ ;)
Препроцессор, операторы, передача ссылок на указатели... Вот чего не хватает очень :(
Microsoft в своем C# поступила много мудрее - все нужное сохранила и даже добавила много чего удобного вроде свойств. А в блоке unsafe вообще на чистом С++ писать можно :) Отличный простор для оптимизации кода.

Да и увлеклись в Java слишком уж классами. До чего доходит - время текущее получить в виде отформатированной строки и то приходится через создание объекта узнавать :( Не могли статических методов наделать для таких случаев.
Понятно почему она такая задумчивая и прожорливая до памяти...

Препроцессор - дело хорошее. Но в некоторых местах были бы гайки (если надо, могу привести примеры). Короче, препроцессор плохо ложится в ООо с динамическим связыванием.

За то, что убили операторы - низкий им поклон. До земли. Глюков на этой почве в С++ коде не перечесть!

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

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

Кстати, а как вы представляете статический метод по получению сегодняшней даты (в разных форматах и локалях) без конфликта с идеями Оккама? Очень плохо, когда одну и ту же вешь можно делать разными способами. Вот за что нужно бороться - это за быстрый new. Тогда и new Date не будет напрягать.

И вообще - в Java не "слишком увлеклись классами". До smalltalk ей далековато в смысле чистоты реализации ООо.

2Oleksiy: По пунктам, пожалуйста, что из перечисленного есть в .NET?
Убрали все устаревшие классы?
Или просто пр#$%#еть захотелось?

Eugeny Balahonov: посмешил старика ;-) типа тебе не хватает C++, ну и пиши на нем. В Java от его отстойных фишек отказались.

вы тут начали обсуждать чегото не ответив на главный вопрос
а у явы есть будущее ???
и если есть то какое ??

Я уже ответил - есть будущее. По необходимости. В силу вбуханных средств. Оно светлое. В меру понимания света такими силами как Сан, ИБМ, проект Апач и пр. Возможно, с учетом мнения простых нас (хотя, скорее всего, без).

>первое что нужно сделать это определиться кто будет дальше >поддерживать яву а кто нет
Что значит кто ее будет саппотить? Будет SUN, IBM этого вполне достаточно!!!
Лично я плевать хотел кто ее будет поддерживать!?

>А я лично хотел бы видеть нативный компилятор под разные платформы - >вот тогда бы этому языку цены бы не было, а то пока они процессоры >свои выпустят, который запускает Джавовский байт-код!
А знаеш чего я хочу ? ;)......................

2anonymous (*) (2002-08-13 15:34:47.558)
Вот еще: на заборе Х** написан, а там ...

>Препроцессор, операторы, передача ссылок на указатели... Вот чего не >хватает очень :(
Это очень хорошо, что нет этого г@вна.

>Microsoft в своем C# поступила много мудрее - все нужное сохранила и >даже добавила много чего удобного вроде свойств.
мудро? Язык как нада упрощать! а не лепить в него что попало (как это получилось с С++)

>Передача по значению - да, местами напрягает. Но жить можно. Боюсь, >введение ссылок слишком бы осложнило язык.
Бросайте немедленно пить! В Яве можно и по значению и по ссылке!

>И вообще - в Java не "слишком увлеклись классами".
Да, есть такая беда. Но с другой стороны сохраняется совместимость со старым кодом.

НеТ - А зачем он? Пошел он куда подальше...

Ну я тут почитал немного и вот написал там внизу: 1) Нету у Жавы будучего - Жава лажа вот вам пример сел я както запрограмировать на жаве свой компютер ну шоб кльово так пахал (как винда хотябы) и он нифига не пашет та жаве я уже все перепробовал жава отстой однозначно кругом одни класы, тонны класов какихто тормозных, ничего не понятно как он (жав) их всех в стек запихивает (вместо стека авторитетно предлагаю пользовать в жаве3 хештейбл - работает рульно - проверил) класов стока шо даже для опытного мастака найти место где чтото свое дописать - просто фанарь - я 2 дня исках но панахадил тока секурные дыры. Они там везде даже в иксемель и в кнопках на окнах

кароче пока лоадеров нормальных не будет с хештейблами всесто простого типа "бит" я этой фигньой свой компютер не буду програмировать!!!

Да уж посмеялся я от души почитав ваши коментарии :) Я заметил что большинство даже не прочитали саму статью, да и вообще мало представляют себе что такое Java. svu я бы посоветовал почитать книги по XML и XSLT, а то в выражениях "Все-таки name=value парсится на порядок быстрее, память жрет меньше и просто проще для восприятия" мало здоровой аргументации и здравого смысла. А вообще говоря про статью - в общем очень правильно пишет!

Спасибо за совет. На XML и XSLT я уже года 3-4 пашу. И все тормозят. XML парсеры и XLST процессоры тормозят.

Если нужна аргументация за простоту парсенья name=value по сравнению с XML - извольте, я могу взять в руки команду ls и сравнить размеры классов и библиотек, занятых этими делами. Не убеждает? Хотя я думал, программистам (я именно для них писал) это очевидно. А может, будем кусками сишного/жабского кода перекидываться?

Про память - Вам известно, сколько ее жрет DOM приличного документа? Попробуйте посмотреть. И возьмите Properties, полученные при чтении a.properties c тем же кол-вом параметро-тегов (не того же размера, а с тем же кол-вом!)

Вот про простоту восприятия - да, это личное. Допускаю, что есть люди, для которых дерево проще хэша.

Пить не брошу. Не имею возможности. Ибо не пью. А переменные в жабе передаются только по значению. Ссылка на официальные источники нужны?

Или, для примера, сделайте так:

String s = "a"; myMethod( s );

Чтобы s поменяла свое значение - справитесь? String приведен для примера - годится любой примитивный тип данных. Значение _переменной_s_ не поменять никогда. Можно поменять что-то в _объекте_, на который она (переменная) указывает. Например, если s сделать StringBuffer-ом, можно сделать append - но при этом _переменная_ не меняется.

>>Препроцессор - дело хорошее. Но в некоторых местах были бы гайки
>>(если надо, могу привести примеры). Короче, препроцессор плохо
>>ложится в ООо с динамическим связыванием.

Почему плохо ложится? Причем тут динамическое связывание и препроцессор? Вот задача - пишу я длинную программу на Java и хочется мне сделать отладочный вывод в лог-файл. После отладки нужно удалить весь отладочный код. В C++ это делается комментированием 1 строки с #define DEBUG_CODE, а в Java что делать?
Или я хочу опционально исключать при компиляции часть функциональности программы?
Почему Microsoft все таки умудрилась сохранить препроцессор в C#?

>> За то, что убили операторы - низкий им поклон. До земли. Глюков на
>> этой почве в С++ коде не перечесть!

Странно, у меня обычно глюков от этого не было никогда. Рад, что в C# операторы живы и здравствуют.

>> Передача по значению - да, местами напрягает. Но жить можно.
>> Боюсь, введение ссылок слишком бы осложнило язык.

Чем усложнило бы?
Ну ввели бы 1 ключевое слово, к примеру Ref
Например

function void foo(ref int a, ref int b, ref Object o) {
...
}

Как в Object Pascal
Procedure foo(var a:Integer; var b:Integer)

Очень бедово без них, когда надо возвратить из функции несколько значений переменных. Приходится извращаться опять через временный объект, какой-нить там List или Set или массив. :( А это опять - минус в производительности программы.

>>Блоки unsafe - это, мне кажется, сознательная подножка
>>разработчикам. Типа - "вы тут поиграйтесь, а я за это не отвечаю".

Да нет, это позволяет в необходимых "узких" местах взять так сказать бразды правления в свои руки и написать как можно более оптимальный код, не полагаясь на разум сборщика мусора и т.д.
А то создал объект, и черт знает когда у него finalize() вызовется :)
Иногда есть необходимость за всем следить самому.

>> Кстати, а как вы представляете статический метод по получению
>> сегодняшней даты (в разных форматах и локалях) без конфликта с
>> идеями Оккама?

static String getCurrentDate(String format)

Зачем нужны такие идеи, которые приводят к невозможности писать эффективный код? Элементарный пример - нужно писать файл, каждая строка которого начинается с времени, когда эта строка писалась.
Создавая вагон новых объектов Date (или как в Java 2 - GregorianCalendar) засоряешь пул памяти Java-машины объектами, которые живут не более секунды. При интенсивной работе сборщик мусора может не запускаться очень долго, память потребляемая машиной растет и растет. Потом наконец очухивается сборщик и все встает клином пока оный сборщик "интеллектуально" трясет пул памяти на предмет вычищения его от такого обилия мусора.
Ну хотя бы этому GregorianCalendar сделали бы возможность обновлять время, которое он описывает! Что-то вроде метода update(). Тогда можно было бы обходится 1 экземпляром класса.
В утиль такие идеи!

Опять же в С# не зациклились идеей "все - класс" и дают решать подобные проблемы приемлемым способом.

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

Тут я согласен. В Perl все можно сделать минимум десятком способов ;)
Это приводит к весьма трудночитаемому коду, если сам не являешься гуру в Perl. Да и к странным ошибкам, когда описка в коде оказывается вполне используемым выражением на Perl, но делающим нечто совершенно отличное.

>> Вот за что нужно бороться - это за быстрый new.
>> Тогда и new Date не будет напрягать.

Как ты представляешь себе реализацию "быстрого new"? Ну есть у машины некий пул памяти, где ею она самостоятельно управляет. Скажем запросил ты выделить память в 8К. Как минимум надо для начала быстро найти свободный блок подходящих размеров и занести в таблицу данные о его выделении. Кроме этого надо заботится о фрагментации памяти, удалении старых объектов. Вот вообще непонятно зачем сборщик удаляет объекты когда-нибудь потом, а не сразу по достижении счетчиком ссылок значения "0", как это сделано в MS COM+ (на самом деле тут все несколько сложнее, но суть такая)? Тогда бы не понадобился сборщик мусора, жудко тормозящий работу машины при запуске. Понадобился бы только какой-нить ПОСТОЯННО РАБОТАЮЩИЙ фоновый поток, дефрагментирующий память. И не было бы этих судорожных рывков и распухания пула памяти.

>> И вообще - в Java не "слишком увлеклись классами". До smalltalk ей
>> далековато в смысле чистоты реализации ООо.

Боже! Неужели все можно еще хуже сделать? Ну незачем совать ОО во все дыры?! Нужно сохранять оптимальный баланс!

>> посмешил старика ;-) типа тебе не хватает C++, ну и пиши на нем. В
>> Java от его отстойных фишек отказались.

Да уж, Java напоминает процесс преобразования литературного британского английского в жаргон Гарлема. Когда вроде можно говорить, но более-менее сложную мысль высказать сложно ;)

Слава богу в C# не допустили полного вырождения языка, а удалили только то, что действительно вредно - например множественное наследование.

>> Пить не брошу. Не имею возможности. Ибо не пью.

Жаль что ты не в Москве, пиво научил бы пить ;)

>> А переменные в жабе передаются только по значению. Ссылка на
>> официальные источники нужны?

Нужны.
Потому что в Java простые типы передаются по значению, а сложные (объекты) - по ссылке.
Например

foo(5) - передача значения по значению. В функции создается новая переменная, в которую копируется значение - 5, ведь int в Java вовсе не объект, а простой тип.

А вот в твоем примере:
>> String s = "a"; myMethod( s );

наблюдается следующее - s - это УКАЗАТЕЛЬ на объект. Или ССЫЛКА. Как не назови - все едино. При передаче myMethod( s ) в области видимости метода создается новая переменная, в которую КОПИРУЕТСЯ ССЫЛКА на объект. Сам объект остается неизменным, его значение "а" НЕ КОПИРУЕТСЯ. Объект String изменить нельзя, поэтому твой пример явно неудачный. Если передавать StringBuffer, то пример станет гораздо более подходящим.

function foo(StringBuffer s)
{
s.append("b");
}

...

StringBuffer s = new StringBuffer("a");
foo(s);
// тут в s имеем "ab" - неправда ли передача по ссылке?

Посмотрим еще на твой пример myMethod()
внутри метода s - не сам объект класса String, а всего лишь УКАЗАТЕЛЬ на этот объект. Получить статическое объявление экземпляра, как в C++, в Java нельзя. Можно иметь только указатель на объект.
Вот в твоем примере и передается УКАЗАТЕЛЬ по значению, а объект - по ссылке.
В С++ можно было бы передать указатель на указатель:

myMethod(string** s)

и править его как *s = new string("b");
А в Java - нельзя, что очень прискорбно и часто неудобно.

>> Я заметил что большинство даже не прочитали саму статью, да и
>> вообще мало представляют себе что такое Java. svu я бы посоветовал
>> очитать книги по XML и XSLT, а то в выражениях "Все-таки
>> name=value парсится на порядок быстрее, память жрет меньше и
>> просто проще для восприятия" мало здоровой аргументации и здравого
>> смысла.

Хорошо, давай порассуждаем. Сначала выберем какой все таки парсер мы рассматриваем - SAX или DOM? Я так понимаю все же DOM, потому как что имеем после прохода SAX-парсера определяет сам пользователь.
На выходе парсера имеем дерево объектов. В Java это дерево Node.
Чтобы получить скажем значение attr1 в XML-документе

<tag1>
<tag2>
<tag3 attr1="aaa">
bbb
</tag3>
</tag2>
</tag1>

Cколько нужно провести операций, чтобы получить значение? Попробуй написать код самостоятельно :) Хотя бы обход готового DOM-дерева, вышедшего из-под пера парсера. Добавь к этому опциональную проверку DTD или преобразование X-Path...

Парсер name=value пишется в 3 строки (привести код?) и на выходе мы имеем хэш-таблицу. Я думаю не надо доказывать что поиск в хэш-таблице гораздо быстрее, чем спуск по DOM-дереву?

P.S. Я решаю эту проблему так: написал класс XMLReader, имеющий метод
getNodeValue(String name), где имя - путь в DOM-дереве, разделенный точками:
getNodeValue("tag1.tag2.tag3(attr1)") вернет aaa, а
getNodeValue("tag1.tag2.tag3.#text") вернет bbb

Раз запрошенные значения узлов кэшируются в TreeMap и повторный поиск по DOM-дереву не нужен. Таким макаром я поднял производительность своей БД на XML-документах раз в 10 :) Я в ней храню локализованные сообщения и другую конфигурацию программы.

Рассмотрим таки SAX парсер, чтобы предвосхитить возможные возражения.
Опять же - попробуй реализовать SAX-парсер в 3 строки. Не получится, хотя он гораздо проще DOM-парсера. И добавь к нему проверку по DTD или XML Schema ;)

name=value значительно быстрее XML, но XML значительно надежнее, так как позволяет логичнее распологать информацию и осуществлять автоматическую проверку целостности при чтении файла.

Препроцессор приводит к головной боли в versioning классов. Определить, какой класс с какими опциями скомпилен - тяжко, невозможно. Да и вообще, в фундаментальные идеи ОО это плохо укладывается. Версия класса должна быть одна для всех приложений. И управляться тот же логгинг должен динамически, из конфигурации (что блестяще _и_быстро_ демонстрирует log4j). А Микрософт вообще С# сделали очень эклектичным - он еще менее ОО, чем жаба (хотя и больше, чем С++). Одни только указатели чего стоят! Короче, препроцессор - не совместим с ОО ИДЕОЛОГИЧЕСКИ:) Хотя на практике иногда хочется...:)

Про операторы - Вам не случалось путать конструктор копирования с оператором присваивания? Завидую. Как свидетельствует практика, на эти (и другие) грабли операторов люди очень любят наступать, делают это часто и со вкусом.

Слово ref - его ведь и в компиляторе, и в байткоде поддерживать надо (если делать дело эффективно). Может, я ошибаюсь, но в стековых машинах (типа жабы) это проблематично. Да, бывает, когда этого хочется.

Про String getCurrentDate() - а Вы не боитесь создания такого кол-ва строк? А почему боитесь даты? Кстати, у Вас всегда есть System.currentTimeMillis:) Хотя update для GrigorianCalendar мог быть быть хорошей идеей - независимо от всего остального.

Объекты не уничтожаются при достижении "0" именно из-за производительности. Много объектов уничтожить за раз дешевле, чем по одному. Наоборот, иногда хочется, чтобы gc подождал и не работал - на критичных участках кода.

Про баланс ОО и производительности - да, есть такая проблема. Сан нашел свою точку решения. Не всем она нравится. Микрософт - свою. Мне она не нравится совсем:) До такой эклектичности дойти - просто ужас!

Про аналогию с жаргоном - не понял. Кто был литературным британским? Это убогий С++, где до сих пор с манглингом не разобрались и где ОО соседствует с атавизмами ассемблера? Если С - то это вообще к ОО отношения не имеет. Это "литературный французский". Если smalltalk - да, java может считаться жаргоном. Но тогда С# - просто мычание парализованного.

Учили меня пить пиво. Даже тут, в Ирландии - Гиннесс. Не помогло.

Цитирую меня любимого (с усилением важного термина): "_ПЕРЕМЕННЫЕ_ передаются по значению". _УКАЗАТЕЛЕЙ_ и _ССЫЛОК_ в жабе нет. Переменная у нас s. А не объект, который за ней стоИт. И передаете Вы, все-таки переменную. Ее, родимую, в стек и кладете (а не объект StringBuffer). И забрать оттуда обновленной не могете.

Не будем о терминах спорить, а? Кажется, мы оба понимаем, о чем говорим.

>> Про String getCurrentDate() - а Вы не боитесь создания такого кол-
>> ва строк?

Боюсь, поэтому сейчас извращаюсь с StringBuffer чтобы обходится 1 выделением памяти, как сделал бы на С++.
А если даже строками оперировать, то вдобавок к толпе строк имеем такую же толпу календарей. Очень приятно.. Гм...

>> А почему боитесь даты? Кстати, у Вас всегда есть
>> System.currentTimeMillis

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

>> Хотя update для GrigorianCalendar мог быть быть хорошей идеей
>> независимо от всего остального.

И не только в нем хотелось бы видеть update ;) Например в File чтобы узнавать, что файл изменился...

>> Про аналогию с жаргоном - не понял. Кто был литературным
>> британским? Это убогий С++, где до сих пор с манглингом не
>> разобрались

с чем-чем? По русски или по-английски плиз, а не на жаргоне ;)

>> и где ОО соседствует с атавизмами ассемблера?

В том то и дело, что в С++ можно использовать как самый
низкоуровневый код, так и взлетать к вершинам ОО и полной абстракции.
Привидите please на Java невоспроизводимый адекватно на С++ код :)
Ну жудко любопытно :) На С++ можно писать 100% ОО код, ни разу не спустившись к линейному, исключая функцию main() (одну на всю программу!).

>> Цитирую меня любимого (с усилением важного термина): "_ПЕРЕМЕННЫЕ_
>> передаются по значению". _УКАЗАТЕЛЕЙ_ и _ССЫЛОК_ в жабе нет.

Настаиваю, что
int a = 5; - переменная типа int с значением 5
String s = "aaa"; - ссылка на объект типа String, который содержит значение "aaa".
a - САМА содержит значение 5, а s - только УКАЗЫВАЕТ на область памяти, в которой содержится ОБЪЕКТ типа String, содержащий значение "aaa". Тем то ссылки и отличаются от простых переменных. К чему это приводит я описал выше.

>> Переменная у нас s. А не объект, который за ней стоИт. И передаете
>> Вы, все-таки переменную.

В этом случае я передаю ссылку на объект

>> Ее, родимую, в стек и кладете (а не
>> объект StringBuffer). И забрать оттуда обновленной не могете

Конечно, потому как в методе имею уже копию ссылки, переданной методу.

Вообще ты слишком долго пишешь на Java :) Если и писал на С++, то все забыл. Там эти отличия надо понимать, а в Java - не надо, потому что альтернативы все равно нет и пока не придвидится.

Насчет С#:
В нем имеются практически все конструкции Java (читая некоторые листинги с ходу и не скажешь что это - Java или C#), но кроме того многое полезное сохранено из С++ и даже из Object Pascal.
Иначе говоря С# написан с учетом недоработок и просчетов в Java, что дает ему несомненное преимущество. Посмотрим что появится в Java 3 :)

Если нужен препроцессор для явы - так выбери какой нравится (хоть сишный)! А то, что это не средство ЯЗЫКА java - это разумно и правильно.

Да, переменная указывает на объект. Но передаете вы все-таки именно значение этого указателя. Дело, вообще, не в том, какие мне или Вам термины нравятся. А в том, какие используются в официальном описании языка. И там написано:

No more pointers (http://java.sun.com/docs/white/langenv/Simple.doc2.html#4107)

Так что давайте говорть в терминах объектов и переменных, если говорим о жабе. ОК?

С++ - не забыл. Но _сильно_ предпочитаю C (док-во на http://gswitchit.sourceforge.net/). Он не претендует на ОО и просто делает свое дело. Кстати, проблемы с манглингом - это то, как переводятся имена с++ в имена с (что необходимо для линкера). Разные компиляторы это делают по разному. Вот, например, вышел gcc 3 - и пошло-поехало. С родным С таких проблем нет.

Про то, что С# сильно тянут с Java - я знаю, и про похожесть листингов верю.

Да, С# несколькими годами моложе. Им было легче. Посмотрим на Java 3, если случится.

Я действительно не люблю эклектику. Был бы соц. заказ - перешел бы на smalltalk, наверное... Или на что еще поООее.

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

Да, на жабе нельзя написать ничего, что было бы не переносимо на С++. Проблема в том, что на С++ можно очень легко написать ТАКОЕ и ТАК, что ни прочитать, ни поддержать, ни отладить... Обычно всякий язык провоцирует некий образ мысли. И образ мысли жабы как-то более предсказуем и адекватен. Дров (в чисто языковом смысле) на ней наломать сложнее, мне кажется.

Короче - сделайте нам из жабы C#. Только вот беда, CLI у них нету. Даже если сделают - будет в 10 раз тормознее.

2 svu (*) (2002-08-13 21:28:34.652): Жабе 11 лет. И за одиннадцать лет она не стала столь же пригодной для программирования как C#. Бедняги из Sun уже не знают куда бы ее пихнуть. Напомнить для чего она изначально разрабатывалась? :0)

Она пригодна. И была (правда, сегодня лучше:). И кол-во софта под нее и на ней - лучшее тому док-во. А приоритеты сменились - что же тут странного? Жисть вносит свои коррективы.

Про пригодность С# - не буду обсуждать, реально не использовал (и как-то не тянет).

Кстати, поддержка жабы апачевским проектом (и кол-во софта на jakarta.apache.org) - это не док-во пригодности?

Вставлю свои три копейки.

Указателей, в том смысле, в котором они есть в C++, в Java нет.

Достоинство Java не скорость кода, а переносимость и скорость написания
логики для "бизнес приложений". А вот в них как нигде требуеться поддерживаемость, читабельность и гибкость. Отсюда и "успех" java именно в узкоспециализированных, зачастую закрытых, проектах. Потому как бабки платят за то чтобы "быстро"..

Насчет C#.
Фиг его знает. Вообщето очень мало знаком. Но то что реализовывался он с позже и с "оглядкой" на Java делает его более изящным.. Но если туда можно вставлять куски C++ кода.. ну его нафиг. Привет дебагеры, указатели в потолок и мемори лики, файлы с кодом в 500К....
короче, то от чего ушли в java.

>>> А почему боитесь даты? Кстати, у Вас всегда есть
>>> System.currentTimeMillis

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

Я правильно понимаю, что

GregorianCalendar c;
c.setTimeInMillis (System.currentTimeMillis());

должно работать с одним instance календаря?

То что действительно вредно.

Eugeny Balahonov:действительно вредно - например множественное наследование.

Почему-то далеко в кадждом OO языке это считается вредным. Почему же оно вредно ? Тем, что разработчики языка поленились это сделать?

Нет, тем, что реализовывать _эффективно_ такие вещи очень трудно (если возможно). И образ мысли разработчика они усложняют. Так что в этом месте к жабе претензий обычно не предъявляют. Интерфейсов вполне достаточно.

Чорт, знай и люби родное API. Про эту функцию я не знал - не доводилось заниматься таким извратом. Обычно жил на new Date. Спасибо за инфу.

>> Если нужен препроцессор для явы - так выбери какой нравится (хоть
>> сишный)!

Ну это в Linux его отдельно можно вызывать, а как, к примеру в Sun Forte Или в JBuilder засунуть этот сишный препроцессор, работая в Windows? Да и в Linux не так-то и просто! Если знаешь, расскажи и покажи, рад буду поучиться!

>> Да, переменная указывает на объект.

Значит это указатель. Простой тип ведь не на что не указывает? Он САМ СОДЕРЖИТ данные! Тем то они и отличаются.

>> Но передаете вы все-таки именно значение этого указателя.

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

>> Дело, вообще, не в том, какие мне или Вам термины нравятся. А в
>> том, какие используются в официальном описании языка. И там
>> написано:
>> No more pointers
>> (http://java.sun.com/docs/white/langenv/Simple.doc2.html#4107)

Да, но там только иное имеют ввиду. Что невозможно САМОМУ создать указатель на что либо и вручную присвоить ему какое-то значение.
Нельзя написать в Java
Object o = 0x3232;
Нельзя получить указатель на статически объявленную переменную простого типа. Нельзя получить указатель на указатель. Можно пользоваться только готовыми указателями на объекты. А они именно указатели. Например

SomeObject a = new SomeObject();
SomeObject b = a;

a и b ссылаются на один и тот же экземпляр SomeObject. Если бы они не были ссылками, то во 2-й строке получился бы новый экземпляр объекта и для него была бы инициирована операция присваивания.
В Java просто нельзя по-другому, поэтому на это не обращают внимания, говоря "No more pointers" ;)

>> Кстати, проблемы с манглингом - это то, как переводятся имена с++
>> в имена с (что необходимо для линкера).

Элементарно. Сколько раз делал
Ключеовое слово extern "C" заставляет делать имена в стиле С. Объект С++ преобразуется в линейную форму а-ля С несколькими строками кода :)
И отлично используется в чистом С-коде. Без каких бы то не было проблем. Привести пример?
У Microsoft так вообще весь COM так написан, ведь интерфейс DLL в явном виде объекты не поддерживает.

>> Разные компиляторы это делают по разному. Вот, например, вышел gcc
>> 3 - и пошло-поехало. С родным С таких проблем нет.

Что там с gcc 3 я не знаю, это не проблемы языка, это проблемы компилятора. Кстати GCC (GNU Compiler Collection) это не только С и С++, это еще Fortran и как ни странно Java ;)
У Microsoft как раз проблем нет с С и С++ ;)

>> Да, С# несколькими годами моложе. Им было легче. Посмотрим на Java
>> 3, если случится.

Да, будем надеятся, что Java 3 будет достойным ответом на С#. Иначе после обретения .Net'ом полноценной многоплатформенности, Java просто не жить...

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

Производительность важна везде. В веб-приложении тоже (которое я пишу) и даже особенно. Или получается Java вообще ни на что не пригодна? Сам язык имеет массу недостатков, но технология мне очень нравится.

>> Дров (в чисто языковом смысле) на ней наломать сложнее, мне кажется

Тут полностью согласен :) Сложную конструкцию в ней возвести трудно.

>> Короче - сделайте нам из жабы C#. Только вот беда, CLI у них нету.
>> Даже если сделают - будет в 10 раз тормознее.

Самый интересный момент, что на Windows С# оказывается гораздо шустрее, чем Sun JRE на ней же :) Я правда не видел как оная работает на Solaris, но думаю с GUI не быстрее чем в Linux :)
Интерфейс по крайней мере в программах не тормозит, да и памяти кушает меньше. Более полных тестов пока не проводил, а надо бы :)
Я думаю CRL и FrameWork в ближайшее время перенесут с Windows на другие платформы. Microsoft не делает из спецификаций секрета и готова предложить пакет документации по написанию CRL всякому за разумные деньги ;) Думаю не заставит себя ждать CRL для Linux/FreeBSD

>> Бедняги из Sun уже не знают куда бы ее пихнуть. Напомнить для чего >> она изначально разрабатывалась?

Ну мобильные телефоны с Java машиной заявлены Nokia и Siemens и даже начали продаваться :)

>> Почему-то далеко в кадждом OO языке это считается вредным. Почему
>> же оно вредно ? Тем, что разработчики языка поленились это сделать?

Потому что это приводит к жудко запутанной библиотеке классов.
Лучше уж использовать агрегацию или интерфейсы.