Интервью с «отцом» Java - James Gosling'ом

> Exception in thread "main" java.lang.NullPointerException at TestE.main(TestE.java:10)

Похоже, ты не разобрался ;) Мне показалось, что это просто был стеб, и камень был кинут как раз таки в огород C++...

Ну тогда классный троллинг получился:))

> И 875 никак не "ГОРАЗДО больше" чем 1000

Ровно как и C++ никак не C... _ЭТО_ДВА_РАЗНЫХ_ЯЗЫКА_.

Системный программист _всегда_ получает больше прикладного программиста и не ищут их на job.ru и еже с ними... Средней фирме системщики либо не нужны либо при формировании своей инфраструктуры они уже знают что именно они собираются делать и кому они будут высылать предложения. Или если это тяжелая контора - элементарно размещают список вакансий.

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

> Политически правильно использовать Local Storage, к которым меньше претензий со стороны системного секьюрити.

ЭЭЭЭ А можно пояснить что вы имелли ввиду под " Local Storage" и как это кореллирует с тем что жаба лезет в нишу распределенных систем где понятия Local существует на таком низком уровне, котором jvm как бы не место...

Это было к разговору об Application Data. Local Storage - это виндовое понятие. О нем можно прочитать, например, в документации .NET SDK. Кстати, Java 6 (Mustang) в виндовом исполнении использует Local Storage.

> Это было к разговору об Application Data. Local Storage

Ааа а я часом ужо решил что это терминология...

Local Storage для дот-нетовских приложений примерно тоже самое, чем являются cookies для DHTML. Оно имеет меньше ограничений по использованию.

Ошибся в названии. Конечно же речь идет об Isolated Storage... :)

> Ровно как и C++ никак не C... _ЭТО_ДВА_РАЗНЫХ_ЯЗЫКА_.

Ты в этом смысле. Отрицать не буду :) Но... на практике... Объявить все прикладное программирование вне закона? Радикально, но нереально. Бизнесу от голой ОС с драйверами толку мало. Тогда уж ИМХО проще договориться, что это разные классы и просто их не сравнивать.

Хотя путанница в терминологии все еще возможна. Если я правильно понял под системщиком ты понимаешь тех, кто создает нечто низкоуровневое. Я об этом упоминал (там где писал драйвера, кодеки и пр) и не отрицал, что работа высокооплачиваемая. Участвовали ли они в этом анкетировании (среди С++ разработчиков) я не знаю.

Но тем не менее...

> cистемный программист _всегда_ получает больше прикладного программиста

...никогда не говори никогда.

Позиция Systems Architect у меня в голове никак не совмещается с C, но, тем не менее, человек, в общем-то, тоже системщик, таких тоже мало и они тоже высокооплачиваемы. Тем не менее сфера у него вполне себе прикладная. И компании, которые успешно живут только на разработке прикладного ПО вполне реальны.

З.Ы. Мне просто интересно с каким Java ПО ты сталкивался, что вызвало следующие реплики:

> Да она мешает жить, когда ее пихают во все дыры. > Да представь себе! С ней приходится работать... и это полная ЖОПА!

И пр... интересуют конкретные примеры.

Мне просто приходилось сталкиваться как с кривыми поделками (опять же, я вполне спокойно к этому отношусь), так и с очень даже приятными решениями.

> Слии засчитан.

Превед словосчётчикам! Я, правда, не понял, куда это я тебя слил... В канализацию, видимо. Ну, звиняй, если что. А по существу есть что сказать?

> А притом, что ты даже не знаешь про JNI. И зачем и когда это используется.

А зачем МНЕ это знать? Я не жабобыдлокодер. Я пытаюсь юзать их творчество. И замечаю, что оно поголовно страдает проблемами переходного возраста. Ты пытаешься объяснить причину этих проблем (как я понял), но у тебя плохо получается, ты слишком темпераментен. Расклад ясен? Ну вот, когда остынешь и утрёшь слюну с монитора, можно будет попробовать ещё раз :)

> Это уже в прошлом. Не знаю точно, но в Висте с этим могут быть проблемы.

Я свои приложения под вистой тестил, у них с %APPDATA% по-прежнему никаких проблем. Просто сам каталог опять переименовали, но для %APPDATA% это прозрачно. А те долбодятлы, которые hardcoded именно "c:\Documents and Settings\username\Application Data", оказались в жопе - и поделом халтурщикам.

> Политически правильно использовать Local Storage, к которым меньше претензий со стороны системного секьюрити.

Да ради бога. Но трабл в том, что жабе это никак не поможет: %LocalAppData% != %HOMEPATH%

> Объявить все прикладное программирование вне закона?

Ага и раздеть всем печатные машинки ! Нет это идиотизм.

> Если я правильно понял под системщиком ты понимаешь тех, кто создает нечто низкоуровневое.

Не обязательно. Скажем так основы для решения целевых задач.

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

Прикладники должны и обязаны существовать. Но желательно чтобы они еще различали ниши...

> И пр... интересуют конкретные примеры.

Сан Майкросистем... + сторонние конторы которые получают процент с продаж программного обеспечения _вместе_ с их техникой. Это все очень красиво у них звучит - "интегррование" + "готовые решения" - а на деле это отдельный монстр под отдельную задачу (потому-что ну сдыхает жаба на несложных но массивных операциях) + для руления всем этим OMC страшно подумать за ~6 килотонн...

> Мне просто приходилось сталкиваться как с кривыми поделками (опять же, я вполне спокойно к этому отношусь), так и с очень даже приятными решениями.

С приятными решениями столкнуться может быть можно. но весьма маловероятно.

И больше всего ненравится "пропихивание" всего этого добра в соседние ниши...

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

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

Мда, даже не знаю что тебе сказать. Кроме того, что я не могу согласиться с твоими положениями и не понимаю чем вызвана такая позиция. Мне такое отношение кажется странным чтобы не назвать его фобией. Хм, было бы интересно пообщаться вживую, так как кнопки топать - можно умаяться...

> сторонние конторы которые получают процент с продаж программного обеспечения _вместе_ с их техникой

Не считаю это удачным примером. Это бизнес больших корпораций. Политика, подковерные игры и прочая грязь. Ничего общего с такой кристально чистой вещью как "искусство программирования" :) не имеет.

> потому-что ну сдыхает жаба на несложных но массивных операциях

Часто тебе приходилось видеть сдохший eBay в последние годы? Хотя я в принципе не считаю eBay уж очень приятным решением. Но архитектурно система вызывает, как минимум, уважение.

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

Java не особо стремится в ниши, так как она вполне себе язык общего назначения, mainstream, так сказать (хочется ли того кому-то или нет). В нишах находится все остальное, которое может (или не может) быть оттуда выдавлено с переменным успехом. Но ИМХО рассмотрение Java, только как языка быстрого прототипирования - ошибочно. Она давно выросла из этих штанишек.

Диапазон применения достаточно широк. Тут многие сватают ее на server-side, жалуются на ресурсоемкость на desktop'е. Тем не менее небось половина втихаря на мобилках в Java игрушки шпиляют? :)

Из своего опыта система для home gateways (smart home) для управления домашней техникой: ARM 200MHz, 64RAM + 64Flash, и ничего, все прекрасно работает. JVM J9, вроде ME, а вроде как и 1.3 почти в полный рост. Там тебе и web (WAP/HTML/HTML КПК) интерфейс, и SOAP web services, и UPnP. Подключайся как хочешь. Интегрируй во что хочешь.

На desktop, лично я подбираю себе набор Java ПО, с которым я могу работать и под Linux, и под Windows, и под Mac. XXE вот например для подготовки документации. Те, у кого есть/был Palm - скажите что вы никогда не пользовались PWCPP. Не поверю :) Отличнейшая программа, а главное полезна под любой ОС. Eclipse как раз вот не очень нравится, IDEA симпатичнее, но и она со своими тараканами.

Про сервер говорить вообще не буду. Только недавно ветка была. Там вволю нафлеймились. С интересом читал, узнал много нового. В частности про C++ server pages. Вот уж где пример посягания на чужую нишу :)

> Да, кстати, скажите такую вещь. В windows есть такая переменная среды, %APPDATA% называется. Содержит путь типа "c:\Documents and Settings\username\Application Data". Жаба не умеет её читать? ВСЕ нормальные приложения хранят пользовательские данные именно в %APPDATA%, создавая там свои подкаталоги. Но у всех жабоприложений - какая-то медвежья болезнь. Они обсираются прямо в "c:\Documents and Settings\username", не добежав до Application Data. Это как, врождённое убожество или как? Thinkree тоже мне сейчас туда покакал. Откуда растут руки у жабокодеров?

Откуда нужно. Вот из-за таких "чистоплотных" как ты, появляются такие же визгливые как ты и визжат о том, что кросплатформенность - миф. А не подскажешь что есть в Linux %APPDATA%? A в Mac OS? А в VMS?

А то что в Linux весь софт согласно тебе страдает медвежьей болезнью не смущает?

З.Ы. Откуда такая забота о судьбах Windows, на этом сайте? :)

> Откуда нужно.

Т.е. из ж... by design? Я так и думал.

> Вот из-за таких "чистоплотных" как ты, появляются такие же визгливые как ты и визжат о том, что кросплатформенность - миф.

Что-то не уловил связи между уважением к рекомендациям разработчика ОС и мифологичности кроссплатформенности. Можно поподробнее?

> А не подскажешь что есть в Linux %APPDATA%? A в Mac OS? А в VMS?

Думаю, что нет. Так же, как в windows нет HOME, но есть HOMEPATH. HOMEPATH нашли, сыщики? А APPDATA что помешало найти?

> А то что в Linux весь софт согласно тебе страдает медвежьей болезнью не смущает?

Что, весь софт пишет пользовательские данные не в тот каталог, который рекомендуется разработчиками данной ОС? Чё, правда?

> З.Ы. Откуда такая забота о судьбах Windows, на этом сайте? :)

Это не забота о windows. Это яркий пример того, насколько всё коряво и черезжописто в мире java.

> Хм, было бы интересно пообщаться вживую

Далековато расположены... а так - будешь в Ташкенте - захады!

> Мне такое отношение кажется странным чтобы не назвать его фобией

Можешь назвать фобией.

> Это бизнес больших корпораций.

...влияющий на ценообразование элементарных вещей и услуг.

> Java не особо стремится в ниши,

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

> Но ИМХО рассмотрение Java, только как языка быстрого прототипирования - ошибочно.

> Тут многие сватают ее на server-side, жалуются на ресурсоемкость на desktop'е.

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

>Но ИМХО рассмотрение Java, только как языка быстрого прототипирования - ошибочно.

Слабо себе представляю актуальность иного применения.

> вроде ME, а вроде как и 1.3 почти в полный рост

Это вроде как 1.3ME (версия неполная и урезанная) да и 200MHz рисковый процессор достаточно не слабенькая машинка. Плюс стоит заметить что на таких ТТХ роутеры и свичи собирают а уж никак не пульты управления.

> Там тебе и web (WAP/HTML/HTML КПК) интерфейс, и SOAP web services

Это все умеет и заскорузлый мобильник _без_явы_ c куда более скромными характеристиками.

> Те, у кого есть/был Palm - скажите что вы никогда не пользовались PWCPP

Это что за зверь ? (Palm OS 5 Garnet в данный момент).

> На desktop, лично я подбираю себе набор Java ПО, с которым я могу работать и под Linux, и под Windows, и под Mac.

Ну опенсорс практически решил проблему однородного софта...

> В частности про C++ server pages.

ну от JSP это недалеко, а вообще web-webу рознь...

Еще раз бегло просмотрел тему, какая чушь скажу я вам. Сколько раз зарекался не участвовать в религиозных войнах но все же дал себя втянуть. Все заканчиваю :)). Но из всей этой переписки в голове останется фраза iBliss которая на мой взгляд четко отражает весь смысл той кучи букв которые мне пришлось еще раз перечитать.

> Мой юный друк. Не надо ничего качать... спроси у знакомых ...

Как грамотно построено предложение, у первых строках сразу показывается возрастное превосходство (сколько Вам лет, хотя не важно, не трудитесь отвечать, больше я в эту тему не вернусь) и далее следует ИСТИНА. На мой взгляд это беда страны в целом. Не надо ничего читать, не надо ничего учить, думать КАТЕГОРИЧЕСКИ ЗАПРЕЩАЕТСЯ. У нас есть люди которые все знают и они четко укажут дорогу которой следует придерживаться. Зовут их сисадмины :))) Сильно их не ругайте - я сам из них.

За сим заканчиваю, не пытайтесь меня оскорбить, не получится, еще раз повторюсь про эту тему и религиозные войны вообще я забыл.

> А APPDATA что помешало найти?

- то, что аналога APPDATA в других операционных системах нет. Ты знаешь что такое абстракция? Дык вот, абстрагировавшись от ОС, мы приходим к тому, что у нас есть только user.dir (и не важно как его искать в той или иной ОС - через HOME или HOMEPATH).

- то, что в до win95 эру APPDATA еще не было (да и в 95 АФАИР его не было, только в NT4 появился), а Java c user.dir уже была. Не потому ли он и появился чтобы дать аргумент таким как ты? А что делать с ПО, которое работает на 95, да и на XP до сих пор прекрасно бы работало если бы не...

"В W2К Хранить пользовательские данные в user home некошерно!" - огласил Билли. "Покупайте новое ПО хранящие данные в APPDATA!" - завопили производители.

и миллионы таких как ты пошли обновлять ПО, на то которое кошерно. Готовьтесь, следующее кошерное ПО будет на .NET (появится такой же как ты и будет спрашивать почему Java использует CreateFile(), а не System.IO.File.Create() для создания файлов). Оно будет знать про APPDATA, но для кошерности этого будет мало, и вот ты, тяжело вздохнув, пойдешь покупать себе новый комплект того же ПО, только создающего файлы по-другому.

Вообще-то, неплохо на эту тему написал Спольски.

- меня лично не смущает наличие дополнительных каталогов в home dir. Зато я знаю, что ПО которым я пользуюсь, будет мигрировать со мной с компьютера на компьютер. И я могу позволить себе сохранить свои привычке не завися от прихотей производителя. И я найду эти даннные в одном и том же каталоге, а не там где их разрешил разместить производитель.

- ну и в конце концов, как разрешить эту проблему тебе указали, JNI плюс проверка типа ОС. Это возможно, но от этого кода плохо пахнет. И запах этот навевает воспоминания из 96-99 годов, когда приходилось разрабатывать ПО под Windows и писать такой же дурнопахнущий код проверяющий тип ОС (95 или NT) и в зависимости от этого вызывать те или иные методы. Если для Windows это типично, то не надо перекладывать это с больной головы на здоровую.

> Это вроде как 1.3ME (версия неполная и урезанная) да и 200MHz рисковый процессор достаточно не слабенькая машинка. Плюс стоит заметить что на таких ТТХ роутеры и свичи собирают а уж никак не пульты управления.

>> Там тебе и web (WAP/HTML/HTML КПК) интерфейс, и SOAP web services

> Это все умеет и заскорузлый мобильник _без_явы_ c куда более скромными характеристиками.

Ты не понял, там находится web server (Apache), под ним embedded Java servlet container, а то что я перечислил это то, с чего можно доступаться к home gateway. Т.е. там есть есть несколько web приложений: для полноценного ПК (по задумке используется TabletPC, типа такой себе пульт управления, но реально у него функций поболе), для КПК (под ширину экрана 240px), для WAP клиентов. Кроме того, есть доступ не через UI, а через программные интерфейсы: SOAP, UPnP. Т.е., как пример использования SOAP, был сделан клиент для SAT-тюнера Dreambox (такая себе коробочка с Linux на борту, с открытыми интерфейсами). Туда вкатали небольшой плагинчик (правда писался он на C++). Типа, смотришь ТВ, а у тебя на экране message box выпрыгивает "Стиральная машина закончила стирку".

То есть, там был размещен вполне полнеценный серверочек. Не думаю, что мобильнику заскорузлому мобильнику такое под силу...

Кроме того, там еще был и голосовой gateway (в связке с DECT модемом). Звонишь себе домой и имеешь что-то вроде (приятным женским голосом): - Добрый день, вы позвонили себе на кухню. Для того чтобы управлять холодильником нажмите 1, для того чтобы управлять плитой нажмите 2 и пр. пр. пр.

Буржуйство конечно, но на уровне проверить выключил ли ты плиту, или в жаркий день за пол часа до приезда домой включить кондиционер, чтобы охладить квартиру ИМХО имеет право на жизнь.

> Это что за зверь ? (Palm OS 5 Garnet в данный момент).

Ууу, батенька... Это Palm Warez Cross Platform Patcher :)

> Ну опенсорс практически решил проблему однородного софта...

В принципе, да. Но пока что это, в основном, mainstream - офис, Интернет. Остаются ниши, которые я для себя частично закрываю с помощью Java.

> - то, что аналога APPDATA в других операционных системах нет.

И что? Давайте так - либо вы претендуете на нормальную кроссплатформенность (а не на "стартует, не падает - и х с ним") и делаете всё ПО-ЧЕЛОВЕЧЕСКИ, либо вы делаете так, как вам лично удобнее, но про нормальную кроссплатформенность помалкиваете в тряпочку. Вы же пытаетесь усидеть сразу на обоих стульчиках, и мне это лицемерие не нравится. Кстати, а как жаба решала эту проблему в Win9x, где она там-то HOME находила? В корень системного диска срала, что ль?

> Ты знаешь что такое абстракция?

Ага.

> Дык вот, абстрагировавшись от ОС, мы приходим к тому, что у нас есть только user.dir (и не важно как его искать в той или иной ОС - через HOME или HOMEPATH).

Вы приходите, а я - нет. Я лично прихожу к тому, что есть user.dir и appdata.dir, которые на части платформ могут совпадать (но это ведь не так страшно, правда?). Если вы так странно "приходите", то говорите честно: "java - это кроссплатформенное решение для POSIX-систем, которое благодаря некоторым костылям, как ни странно, запускается и под WIndows. Криво, конечно, но запускается". ВОт так будет честнее.

Я бы ещё понял, если бы отдельный каталог Application Data появился в венде внезапно, как снег на голову, в 2000 году, когда java была уже готова (ну, обычная корпоративная леность, инерция мышления и пр.). Но он же там был уже по крайней мере в WinNT4 (1996 год)! Так что оправдания вашим кривым абстракциям я не вижу.

> - то, что в до win95 эру APPDATA еще не было

Дык и HOMEPATH не было. А вот Application Data был. Более того - была поддержка юзеров, для каждого создавался свой профиль со своим Application Data (весь этот срач лежал в каталоге c:\windows\profiles). Но java всё равно сделала собственную кривую абстракцию. "Весь мир - моя нора; где хочу, там и сру".

> А что делать с ПО, которое работает на 95, да и на XP до сих пор прекрасно бы работало если бы не...

Очевидно, использовать "c:\windows\profiles" и "c:\windows\all users"? Не приходило в голову, нет?

> "В W2К Хранить пользовательские данные в user home некошерно!" - огласил Билли. "Покупайте новое ПО хранящие данные в APPDATA!" - завопили производители.

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

> и миллионы таких как ты пошли обновлять ПО, на то которое кошерно. Готовьтесь, следующее кошерное ПО будет на .NET (появится такой же как ты и будет спрашивать почему Java использует CreateFile(), а не System.IO.File.Create() для создания файлов). Оно будет знать про APPDATA, но для кошерности этого будет мало, и вот ты, тяжело вздохнув, пойдешь покупать себе новый комплект того же ПО, только создающего файлы по-другому.

Всё, истерика началась. Бред несёшь. Плачу я за новую версию уже купленного продукта или не плачу - определяет производитель, и это никак не зависит от APPDATA.

> - ну и в конце концов, как разрешить эту проблему тебе указали, JNI плюс проверка типа ОС. Это возможно, но от этого кода плохо пахнет.

Плохо пахнет от виртуальной машины, которая к 2007 году ещё не сподобилась исправить ошибку, очевидную УЖЕ ПРИ ЕЁ СОЗДАНИИ в 199 лохматом году.

> Плохо пахнет от виртуальной машины, которая к 2007 году ещё не сподобилась исправить ошибку, очевидную УЖЕ ПРИ ЕЁ СОЗДАНИИ в 199 лохматом году.

От виртуальной машины плохо пахнет уже потому, что это виртуальная машина :D Технология, устаревшая уже лет 15 назад.

> Дык и HOMEPATH не было. А вот Application Data был.

А толку с того, что он был? А добраться до него как? Если мне не изменяет мой склероз, то методы, которыми его можно было _корректно_ определить появились в shell32.dll, начиная с Internet Explorer 5.0. А когда, о великий очень не слабо знакомый с Windows, был выпущен IE5, не подскажешь? Тогда я скажу - в 99 году.

А до того вопросы реашлись с помощью банального сложения строк, продвинутые - искали ключи в ресстре. Ты серьезно предлагаешь, чтобы JVM зависела от версии установленного браузера? И эти люди запрещают нам ковыряться в носу...

> Плачу я за новую версию уже купленного продукта или не плачу - определяет производитель, и это никак не зависит от APPDATA.

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

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

И говорил я о том, что раз для тебя следование всем заповедям платформы (то, что я называл "кошерность") важнее собственно функционала приложения, то это не мой путь. Завтра мелкомягкие выпустят новую ОС, в которой хранить данные будет принято в другом каталоге. И выустят новый Офис, который будет их там хранить и больше ничего нового. Ты пойдешь его покупать? Смысл? Ответь честно, для повседневного оформления документа тебе бы сегодня хватило функций Word 97? Если нет, то, интересно, чего тебе не хватало, если да, то пользовался ли ты 2000, XP, 2003, 2007? Если да, то зачем? :)

Сначала мы (долго и тернисто) шли от 16 бит, к 32. Ладно тут выгода объективна. Потом "Все на COM/ActiveX". Потом "Все на Internet enabled!" (кто-то пробовал разобрать HTML экспортированный из Word'a?). Скоро перепишут офис на .NET. А теперь вопрос: стали ли от этого документы выглядеть лучше хотя бы у 50% пользователей?

Ну и собственно:

> нормальную кроссплатформенность (а не на "стартует, не падает - и х с ним")

Задекларировано "Write once - run everywhere", а не "Write once - find your application data in the right folder". Кроссплатформенность задекларированная создателями, как ни удивительно, как раз ближе к твоему второму варианту, тот который в скобках. И то что оно не совпадает с твоим пониманием нормальной кроссплатформенности, извини, не показатель, этого никто не декларировал.

> А толку с того, что он был? А добраться до него как?

Ты хочешь сказать, что в вендовой JVM нет ни одной функции чтения реестра (приватной, публичной - мелочи)? Чё, правда? Не верю. А значит, могли зайти в HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders и считать оттуда. Но - похоже, поленились. И до сих пор ленятся.

> А до того вопросы реашлись с помощью банального сложения строк, продвинутые - искали ключи в ресстре.

Не совсем понимаю, что тут продвинутого. Не расскажешь? Функции чтения реестра есть в WinAPI. В чём состояла страшная проблема, стоявшая перед разработчиками JVM? Я ещё раз повторяю: речь не о тех, кто кодит на жабе, от них даже я не буду требовать городить код спецом под венду, чтобы пролезть в реестр. Речь о разработчиках JVM.

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

Похоже, у тебя с логикой непорядок. Работать под рутом тоже можно. А чё, работает же? И документы в корзине можно хранить. Просто это - методы на крайний случай. И от них надо отходить как можно быстрее. Но жаба до сих пор не раздуплилась с APPDATA, а сколько уже лет прошло?

> Ты хочешь сказать, что в вендовой JVM нет ни одной функции чтения реестра (приватной, публичной - мелочи)?

Есть, через registry в Windows JVM реализован Preferences. Но ты правильно говоришь

> Функции чтения реестра есть в WinAPI.

И появились они там с тех пор как появился реестр. Ты же не предлагаешь, мне изменять реестр используя файловые операции и ntuser.dat (я знаю что его открыть не получится, но пока что я не об этом). Потому что, сохранение формата файла реестра и местонахождения файла _не гарантировано_ для будущих версий.

Для этого и делается API, для того чтобы скрыть детали реализации. И я сказал, что есть метод в shell32.dll, для получения полного пути к каталогу "Application Data", но метод этот появился только в 1999 году, причем, как часть нового браузера.

То, что ты предлагаешь сделать - считать значение из реестра напрямую - это то же самое что работать с файлом реестра напрямую. Или... ты хочешь сказать, что MSDN где-то заикается о том, что приведенный тобой ключ _гарантированно_ будет сохранен во всех будущих версиях Windows, и может быть использован для получения искомого значения? Можно ссылочку (желательно свежее 99 года)?

Таким образом, если мы говорим о гарантированном способе получения гипотетического свойства app.dir, то без оговорок (типа а какой у вас браузер) это стало возможным только с Windows 2000. Первым JDK, который не поддерживает ОС старше W2K (т.е. не будет на них работать), стал Java 6, который вышел совсем недавно. Ничего, что я так буквоедствую? :)

> Но жаба до сих пор не раздуплилась с APPDATA, а сколько уже лет прошло?

Исходя из последнего моего абзаца - прошло всего-то пару месяцев. Понятное дело, что можно было с некоторым количеством if'ов в коде, все сделать гораздо раньше. Но, считай это итальянской забастовкой в исполнении Sun, тем более, что community не особо озабочен этим фактом :)

> Работать под рутом тоже можно. А чё, работает же? И документы в корзине можно хранить. Просто это - методы на крайний случай. И от них надо отходить как можно быстрее.

Если нет другой возможности, а работать нужно, то да. А что делать? Вот ты и сам описал положение, в которое были поставлены Windows разработчики (не только разработчики JVM) :) В частности, насчет Application Data с 1995 по 1999 год, и насчет многих других вещей. Я уже разработкой для практически Windows не занимаюсь уже почти 7 лет как, но не думаю, что там что-то кардинально изменилось в лучшую сторону :)

> И появились они там с тех пор как появился реестр.

Т.е. в 1994-95 или раньше (скорее всего раньше, потому что реестр был и в 3.x, просто назначение его было иное).

> Ты же не предлагаешь, мне изменять реестр

Я??? ИЗМЕНЯТЬ реестр? ГДЕ??? Я предлагаю прочитать ОДНО значение в HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders! И присвоить его - я не знаю, чему там - user.appdatadir или х.з. ещё чему. ВСЁ. Тем более, что у меня есть основания полагать: user.dir тоже заполняется чтением реестра.

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

Тебя опять не в ту степь понесло куда-то.

> Для этого и делается API, для того чтобы скрыть детали реализации.

Ты что-то хочешь мне рассказать про историю появления функций RegOpenKey(Ex) и RegQueryValue(Ex)? Слушаю.

> И я сказал, что есть метод в shell32.dll, для получения полного пути к каталогу "Application Data", но метод этот появился только в 1999 году, причем, как часть нового браузера.

Да, этот метод приятнее, слегка проще, но даёт тот же результат. Что дальше?

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

Ты сдурел, что ль? Ты сравнил чтение реестра WinAPI-функцией RegQueryValue с прямым парсингом ntuser.dat???? Слышь, не кури эту гадость больше, а?

> Или... ты хочешь сказать, что MSDN где-то заикается о том, что приведенный тобой ключ _гарантированно_ будет сохранен во всех будущих версиях Windows, и может быть использован для получения искомого значения? Можно ссылочку (желательно свежее 99 года)?

MSDN не даёт гарантий на будущее ни для каких функций. Просто в какой-то момент что-то объявляется obsoleted, т.е. в будущем могут выкинуть. Так что не надо херню лепить.

> Таким образом, если мы говорим о гарантированном способе получения гипотетического свойства app.dir, то без оговорок (типа а какой у вас браузер) это стало возможным только с Windows 2000.

ЛОЖЬ. Прямая ложь. Видимо, очень характерная для жабофилов. Объяснения см. выше. То, что было выведено из этой лживой посылки, я даже не буду читать.

> Ты сравнил чтение реестра WinAPI-функцией RegQueryValue с прямым парсингом ntuser.dat????

А с абстракцией таки у тебя хреново. Поясняю, я сравнил два абстрактных процесса:

- получение данных с помощью прямого доступа к источнику (чтение файла реестра или чтение значения напрямую из реестра); - получение данных с помощью соответствующего API (Reg* в одном случае, SH* в другом случае).

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

> Да, этот метод приятнее, слегка проще, но даёт тот же результат. Что дальше?

Используя твою буквоедскую практику - этот метод был официально задокументирован, все остальное - это workarounds - в сад!

> MSDN не даёт гарантий на будущее ни для каких функций.

Если "на будущее" только для функций, то для ключей реестра гарантии не даются вообще.

> Поясняю, я сравнил два абстрактных процесса:

А API, между прочим, так и возникает: его первую версию предлагают разработчики на основе собственных предположений о том, какие действия программистам наиболее часто придётся выполнять. Потом, на основе накопившегося опыта, по мере надобности, добавляются новые функции. Основная цель - сделать наиболее часто повторяющиеся действия проще. Ну, и ввести дополнительную абстракцию, да. Только я не понимаю, зачем ты здесь наводишь тень на плетень и уводишь разговор в сторону?

Проблема такова. JVM игнорирует рекомендации разработчика платформы Windows касательно каталога для хранения пользовательских данных приложений. Игнорирует злостно, уже многие годы. Веских оправданий для этого игнорирования тебе привести не удалось, хоть ты и пытался. Может, попробуешь ещё? Вот прямо по пунктам: 1), 2), 3). А я потом прямо по этим пунктам выскажусь.

> Использование первого процесса для доступа к реестра у тебя вызывает приступ брызгания слюной

Бред. Всего-то надо задействовать ДВЕ (!!) упомянутые мной выше WinAPI-функции. Где сложность, покажи?

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

Неправда. Пока не было shell32, они могли, скрежеща зубками, использовать эти страшные (для тебя и для них) reg-функции WinAPI. Но с тех пор, как появилась shell32, у разработчиков JVM было время и возможность предпочесть использовать её. Тем более, что у меня есть основания полагать: на win-машине без shell32 нынешние JVM всё равно уже не запустишь. Так где проблема?

> Используя твою буквоедскую практику - этот метод был официально задокументирован, все остальное - это workarounds - в сад!

Снова бред. Оба метода официально предлагались разработчиком платформы. Здесь нет никакой отсебятины. Просто сейчас MS рекомендует shell32-метод. Снова: где проблема?

> Проблема такова. JVM игнорирует рекомендации разработчика платформы Windows касательно каталога для хранения пользовательских данных приложений. Игнорирует злостно, уже многие годы.

Поверь мне, что это не является самой большой проблемой Java, на данный момент. И вряд ли один я так думаю. Иначе, такой request давно бы появился в bug database и собрал бы огромное количество голосов.

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

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

Если ты будешь выступать в роли заказчика, ты запросто можешь потребовать этого и заплатив получишь то, что нужно. Как только таких заказчиков будет много, и программисты начнут сталкиваться с такой задачей часто, они начнут штормить Sun, и возможно когда-то оно появится в стандартном API.

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

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

> Пока не было shell32

Он был с самого начала выхода win95, только функций нужных в нем не было.

> они могли

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

Мелкомягкие тоже "могли"... предоставить API поддерживающий ихние "рекомендации" сразу, а предоставили в составе ОС, почему-то через несколько лет. И то, видать только потому, что их разработчики достали.

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

> Оба метода официально предлагались разработчиком платформы.

Я вот и просил ссылочку на "официально", не дождался. У нас разные понятия об официально. У меня официально - это Platfom SDK или Programer's Guide/Reference. А Troubleshooting/Knowledge Base - это официоз для бедных (типа "Ой! Проблемка. Ну делайте пока так, а мы скоро что-нить придумаем.").

Короче, спор в дальнейшем мне видится бесперспективным. Судя по всему, каждый останется при своем мнении. Судя по тому, сколько времени ты уделил вопросу "Почему им было взападло прочитать одно значение из реестра?", то эта претензия является одной из самых существенных, посему результатом я скорее удовлетворен.

> Ты не понял, там находится web server (Apache)

Я прекрасно понимаю. что там находится апач на предыдущем смарте (P900) у меня тоже был апач (на поиграццо).

> а то что я перечислил это то, с чего можно доступаться к home gateway.

Ну еще одни неосилили (написать свой/адаптировать имеющийся) протокол или на самый худой конец TLV я тут при чем ?

> Туда вкатали небольшой плагинчик (правда писался он на C++). Типа, смотришь ТВ, а у тебя на экране message box выпрыгивает "Стиральная машина закончила стирку".

Т.е. для этого понадобился ip-шный стэк апач и SOAP ? Ужас...

> Не думаю, что мобильнику заскорузлому мобильнику

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

> Кроме того, там еще был и голосовой gateway (в связке с DECT модемом)

IVR. Часто встречается и в автоответчиках ? В 97-98 году легко реализовывалось на базе 486 dx2 (66mhz) и модема Зухель ?

> Буржуйство конечно,

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

> Ууу, батенька... Это Palm Warez Cross Platform Patcher :)

Мммм не знаю не пользовался нынешний нанешний палм относительно недавно...

> Остаются ниши, которые я для себя частично закрываю с помощью Java.

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

Скажем так я за Java Home Edition (кому понравится - возьмет). Но против JEE и ее тесной интеграции с текущими платформами (Во всяком случае то как это делает Сан).

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

Верю. Но зато это прекрасно иллюстрирует подход разработчиков к качеству продукта. С таким подходом вы свои проблемы никогда не решите, только стонать и будете.

> И вряд ли один я так думаю. Иначе, такой request давно бы появился в bug database и собрал бы огромное количество голосов.

Ни разработчики, ни тем более пользователи жабоприложений не замечают это по одной простой причине - крайне низкая квалификация. Работает как-то - и ладно, пипл схавает. И правда, многие хавают. Та же история, что и с windows. Она, как и java, ориентирована на быдло. Тут они друг друга нашли просто.

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

Да и самой M$ это, я думаю, тоже пох. WIndows они просрали, скоро просрут и Windows NT.

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

Я уже рассказал выше, почему так :)

> Я вот и просил ссылочку на "официально", не дождался. У нас разные понятия об официально. У меня официально - это Platfom SDK или Programer's Guide/Reference.

http://www.microsoft.com/technet/archive/winntas/maintain/profiles.mspx?mfr=true

Устроит?

Если нет - жду контрпример, где MS в период с 1995 по 1999 рекомендует какой-то иной путь определения Application Data, кроме реестра. У меня сейчас, к сожалению, нет старых MS SDK.

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

Абсолютно. Разработчики либо вообще не озадачивались этим вопросом, либо попробовали искать инфу, за 5 минут не нашли - и забили. Типа и так пашет, зачем париться? Типа "зачем идти в туалет, если насрать можно в квартире соседа - у меня же всё равно пахнуть не будет".

> Судя по тому, сколько времени ты уделил вопросу "Почему им было взападло прочитать одно значение из реестра?", то эта претензия является одной из самых существенных, посему результатом я скорее удовлетворен.

Остальные претензии к ThinkFree я высказал выше, и тебе нечего было возразить. Поэтому ты так прицепился именно к APPDATA. Других претензий не будет - TF я удалил, как совершенно бесполезную погремушку, а иного java-софта не держу, незачем.

> У меня сейчас, к сожалению, нет старых MS SDK.

Написал и вспомнил про delphi 5, который у меня валялся. Там нашёл "Win32 Programmer's Reference" из MS SDK того времени. Цитата оттель:

Folder Locations

Certain folders have special meanings for the shell. An application can use shell functions to retrieve the locations of these special folders and to enable the user to browse for specific folders.

Some special folders are virtual folders ¾ so called because they are not actual directories on any storage device, local or remote. Virtual folders like the desktop folder, the My Computer folder, and the Network Neighborhood folder make a unified namespace possible by serving as containers for any number of storage devices and network resources. Other virtual folders contain file objects, such as printers, that are not part of the file system. File system directories that the shell uses for specific purposes are also considered special folders. Examples include the Programs folder (which contains the user's program groups) and the desktop directory (which is used to physically store files that have been copied to the desktop folder). The locations of special file system folders are stored in the registry under the HKEY_CURRENT_USER / Software / Microsoft / Windows / CurrentVersion / Explorer / Shell Folders key.

You can use the SHGetSpecialFolderLocation function to retrieve the location of a special folder, which can be virtual or part of the file system. The function returns a PIDL, which the application must eventually free using the shell's allocator. If the folder is part of the file system, you can convert the PIDL to a file system path by using the SHGetPathFromIDList function. For a list of special folders, see the description of the SHGetSpecialFolderLocation function.

To display a dialog box that enables the user to browse for a folder, you can use the SHBrowseForFolder function. An application might use this function to prompt the user for a directory or remote computer. This function can also be used to browse for network printers, even though printers are not considered folders. An application can specify the root folder to browse from. For example, to prompt the user for a program group, you might call SHBrowseForFolder specifying the PIDL for the Programs folder as the root.

Возражения, благодарности, пожелания?

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

А Oracle? Тоже убил бы? А то когда он сжирает 1.4Гб из 2-х на сервере, тоже убить хочется. И ведь написан, ты не поверишь, на C! Ну куда он столько памяти жрет?

>От виртуальной машины плохо пахнет уже потому, что это виртуальная машина :D Технология, устаревшая уже лет 15 назад.

Ой. Скажи это микрософту с хельсенбергом. Им же 6 лет назад пришлось опять изобрести виртуальную машину, этот труп, умерший 15 лет назад.

>Ты хочешь сказать, что в вендовой JVM нет ни одной функции чтения реестра (приватной, публичной - мелочи)? Чё, правда? Не верю.

Нету. Ибо на соляре это не нужно. Приходится покупать отдельные библиотеки, работающие с реестром через JNI

> А Oracle? Тоже убил бы? А то когда он сжирает 1.4Гб из 2-х на сервере, тоже убить хочется. И ведь написан, ты не поверишь, на C! Ну куда он столько памяти жрет?

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

>> Ты хочешь сказать, что в вендовой JVM нет ни одной функции чтения реестра (приватной, публичной - мелочи)? Чё, правда? Не верю.

> Нету. Ибо на соляре это не нужно. Приходится покупать отдельные библиотеки, работающие с реестром через JNI

Как же жаба user.dir определяет?

> А Oracle? Тоже убил бы?

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

> Ну еще одни неосилили (написать свой/адаптировать имеющийся) протокол или на самый худой конец TLV я тут при чем ?

> Т.е. для этого понадобился ip-шный стэк апач и SOAP ? Ужас...

> IVR. Часто встречается и в автоответчиках ? В 97-98 году легко реализовывалось на базе 486 dx2 (66mhz) и модема Зухель ?

И все таки, ты наверное системщик в первом понимании этого слова. Именно системный программист, призванный находить самые оптимальные решения некоторой задачи, но (!)... на низком уровне. Есть такая замечательная вещь "История одного байта" (если вдруг не встречал, то например, здесь http://www.rsdn.ru/Forum/Message.aspx?mid=119868&only=1). Думаю, тебе это близко по духу. В принципе, мне где-то тоже, так как в 95-96 годах я сам этим занимался.

Но, когда смотришь на задачу глазами системщика в смысле архитектуры - все видится несколько иначе, ценности другие.

Выхватив пример интеграции тюнера и домашнего gateway, ты уже забыл о том, что есть web интерфейсы. Суть как раз в том, чтобы предоставить возможность интегрировать данный компонент в любую другую систему (в данном случае систему smart home) с минимальными затратами. Вот для этого и такое количество интерфейсов. Да, каждая из приведенных задач решается с меньшим количеством ресурсов (аппаратных, а не людей/времени), но ценность именно в комплексе.

Был уже флейм насчет полезности XML, где-то около года назад, где я описывал все тоже самое, только с точки зрения зачем мне понадобился SOAP, где мне предлагали использовать ASN.1 или написать свой протокол. Там я пытался изложить чем это хуже в современных условиях (http://www.linux.org.ru/profile/azakharchuk/view-message.jsp?msgid=1343241&am...). Изобретать свои протоколы (адаптация имеющихся такой же свой, только мнее трудозатратный для тебя), когда планируется интеграция с компонентами, которые ты не можешь предвидеть, в принципе недопустимо. Т.к. с т.з системщика, который будет оценивать стоимость интеграции с твоей системой и конкурентами, предпочтет открытый известный протокол, для которого есть готовые инструменты.

Хм, как мы плавно отъехали от Java в сторону :)