Roman Elizarov's blog

EГЭ и злая империя Microsoft

Sun, 07 Jun 2009 04:35:07 GMT

Шокирует то, что этот сайт не работает в FireFox. Вообще, в Российском интернете это очень частое явление. Почему именно в нашей стране в школах учат почти исключительно продуктам Microsoft и такая большая степень промытия мозгов, что "вэб дизайнеры" в подавляющей массе не подозревают о существовании других браузеров?

JavaOne 2009: Day 3

Fri, 05 Jun 2009 03:53:06 GMT

Сегодня мне удалось послушать одну исключительно полезную и грамотную техническую сессию. Cliff Click и Brian Goetz на пару рассказывали о сложностях оптимизации производительности в современных архитектурах. Подробно, с примерами. На редкость грамотная и интересная презентация. Как только они выложат слайды online, я обязательно скину в своем блоге ссылку на них, как и на несколько других интересных презентаций с этого JavaOne.

А вечером IBM рассказывала про Apache Harmony. Я и не знал что они этим глубоко занимаются. Делали упор на модульность, которую в Sun-овскую реализацию еще только планируют прикрутить (и по этому поводу было аж несколько презентаций от Sun). Также IBM зачем-то воткнула речь про свою технологию кэширования информации в кластере. Там было упоминание о том, что мол на рынке есть и другие такие продукты, но никакого реального сравнения с конкурентами представлено не было. В общем, бесполезный маркетоидный рассказ получился.

Вот и всё. Для меня это был последний день на JavaOne. Труба зовет на TradersExpo.

JavaOne 2009: Day 2

Thu, 04 Jun 2009 16:20:49 GMT

На General Session рассказывали про успехи Java на мобильном фронте. На сцене представители Orange и SonyEricsson клятвенно обещали объединяться с индустрией и бороться с фрагментацией платформ которая, как известно, корень всех проблем в мобильном Java мире. Тот факт, что они открыто признали фрагментацию уже радует. Посмотрим, что у них получится с борьбой.

Обещали поддержку Java Store и JavaFX на разных устройствах. Как всегда, в маркетинге Sun Microsystems не все дома, и похоже они хотят как-то завязать между собой Java Store и JavaFX. Надеюсь, что разум возобладает и, несмотря на маркетинг, для Java Store будет все-равно какие именно Java приложения в нем размещены. Концептуально идея у них такая: разработчик отправляет приложение в Java Warehouse, где его проверяют, сертифицируют и т.п., а уже оттуда оно становится доступным на всех устройствах. С точки зрения маркетинга Sun, устройства делятся на три категории: Desktop, Mobile, TV. Они это называют "all screens of customer's life". Собственно, хитом шоу было одно и тоже JavaFX приложение работающее на всех 3-х устройствах. Desktop-ом у них был MacBook, в качеcтве Mobile выступала специальная версия HTC Touch Diamond с поддержкой JavaFX (кстати, её здесь продают), а в качестве TV выступало уже упоминавшееся мной устройство от LG.

JavaOne 2009: Day 1

Wed, 03 Jun 2009 02:55:56 GMT

Итак, началась ежегодная конференция JavaOne. На открытии конференции, как всегда, рассказали о миллиардах десктопов и мобильных устройств с Java ;) Не забыли упомянуть и о Blue Ray дисках. Показали телевизор LG (начинает продаваться в Корее через месяц), который нативно умеет запускать JavaFX приложения с весьма неплохой производительностью (полупрозрачные менюшки и приложения живенько бегали поверх Full HD видеоряда).

Анонсировали Java Store (пока в глубокой бете), который позволит программистам легко распространять и продавать свои приложения. В общем, модный тренд не обошел стороной и Java. Они пока еще не выбрали конкретную модель оплаты (в бете всё бесплатно) и спрашивают мнения разработчиков о том, какая модель будет лучше всего. Порадовало то, что сразу предусмотрен режим preview, когда можно запустить приложение не покупая и не устанавливая его.

Естественно, они не смогли промолчать про покупку Sun Microsystems компанией Oracle. Из-за требований закона, как публичная компания, они не могут официально комментировать еще не завершенную сделку. В этом году нет стенда Oraclе, нет презентаций от Oracle. Но в конце открытия на сцену пригласили Лари Эллисона, который попытался успокоить всех Java разработчиков. Он сказал, что ничего не поменяется, но будет больше инвестиций в Java, в том числе, и на клиентской стороне (упоминал JavaFX и OpenOffice).

ACM ICPC World Finals

Tue, 21 Apr 2009 08:48:22 GMT

ACM ICPC World Finals проходит прямо сейчас! Болейте за команды своих вузов! Официальная страница соревнований: http://cm2prod.baylor.edu/

Видеотрансляция соревнований: http://icpc09.csc.kth.se/live/

Официальная таблица результатов: http://icpcdmt.csc.kth.se/scoreboard/index.html

Таблица результатов в подробном виде: http://zibada.ru/pcms/finals/

Меньше чем через 4 часа определятся новые чемпионы мира по программированию. Однако, в последний час таблица результатов "замораживается" и победители будут объявлены только через 7-8 часов на церемонии награждения.

UPDATE: В этом году результаты объявили уже через 45 минут после окончания соревнования. Золотые медалисты (первые четыре места):
на 1-м месте команда СПбГУ ИТМО,
на 2-м команда Tsinghua University,
на 3-м команда СПбГУ,
на 4-м команда Саратовского ГУ.

О программном коде

Mon, 20 Apr 2009 20:26:34 GMT

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

UPDATE: Пост исключительно о программном коде. Упоминание программиста было лишним.

Дилемма заключённого

Sat, 29 Nov 2008 19:52:47 GMT

В последнее время много пишут про кризис. Кто-то с пессимизмом пишет про то, как всё будет плохо; другие критикуют власть и пишут, что она должна была делать, чтобы всем было лучше; третьи спрашивают, что же им делать, чтобы спастись или дают советы про то, как спасти себя. Я пока ни разу не видел, чтобы кто-то написал о том, что должен сделать каждый, чтобы всем было лучше. Это очень странно, ибо еще с досоветских времен в России было сильно коллективистское мышление -- забота в первую очередь о своем коллективе, а уже потом о себе. Похоже, что с ростом благосостояния общества неизбежно побеждает индивидуализм. Например, мои социальные установки существенно более индивидуалистичны, чем установки моих родителей. В этом не было бы ничего плохого, если бы не тот факт, что многие экономические процессы работают по принципу дилеммы заключённого.

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

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

Вот мои три "коллективистских" антикризисных совета для каждого под лозунгом "что должен сделать каждый, чтобы помочь стране":

Минимизируйте потребление импортных товаров и услуг, заменяя их отечественными ~~(даже если они худшего качества)~~ либо уменьшая частоту их потребления. UPDATE: это не значит что надо потреблять отечественный хлам в ущерб себе. По многим позициям можно перейти на отечественные товары без потерь, а многие другие можно без потерь сократить (реже менять сотовый телефон, например).
Переведите все свои сбережения в рубли.
Положите все свои сбережения в банк или в несколько банков (по 700 тысяч рублей в каждый), если у вас их много.

Какой эффект могут произвести эти действия? Не радикальный, но значимый. По разным оценкам, Россияне держат "под матрасом" в валюте от 5 до 80 млрд. долларов. Такой физический спрос на рубли способен заметно подвинуть курс рубля к доллару, а самое главное вынести на маржин колах спекулянтов, которые играют сейчас против рубля. Что же касается импорта, то в 2007 г. только автомобилей было ввезено на 20 млрд. рублей, так что России есть куда "подвинутся" по импорту, чтобы сохранить положительный платежный баланс.

Внимательный читатель обратит внимание, что если подобным советам последуют во всех странах, то из-за замедления мировой торговли всем придется не сладко. Но я не знаю аналогичного глобального рецепта сохранения хорошей жизни во всем мире. Дело в том, что ситуация, происходившая во всем мире последние 10 лет, была "unsustainable" и всем очевидно, что процесс, который не может продолжаться вечно, не будет продолжаться вечно.

Как избежать утечек памяти из-за потери подписчиков в GUI приложениях

Thu, 20 Nov 2008 07:40:28 GMT

Написать этот пост меня cподвиг вопрос в ru_java от and_bel.

Всем кто когда-либо писал большие, сложные, многооконные GUI приложения, где разные окна работают с общими моделями данных, должна быть знакома ситуация: открываем и закрываем какое-либо окошко несколько раз и видим что потребление памяти увеличилось. Классическая утечка памяти, которая у пользователей проявляется как "тормоза" после длительной работы с приложением, а потом и вылет из-за нехватки памяти. Причина таких утечек обычно банальна и проста -- визуальные компоненты приложения должны подписываться к модели данных чтобы получать нотификации об её изменениях и отображать их на экране (классический шаблон Model-View-Controller, только Controller нас сейчас не интересует). Программист забыл отписаться от нотификаций при закрытии окна -- вот вам и утечка. В приложениях написанных на базе Swing ситуация осложняется тем, что при написании отдельных компонентов не очень понятно в какой момент надо отписываться -- стандартных методов типа close или destroy для компонентов не предусмотрено. Можно ли построить дизайн приложения таким образом, чтобы уменьшить вероятность появления таких ошибок?

Один из подходов заключается в явном управлении за жизненным циклом всех окон и компонентов внутри них. В некоторые GUI каркасы такое управление встроено изначально, а в Swing можно прикрутить что-нибудь свое или чужое. Это решает часть проблемы. У вас появляется метод типа close или destroy куда надо написать код отписывания от всех моделей данных. Далее, в компоненте вашего приложения нужно следить чтобы для каждого addXXXListener в инициализации компонента был парный ему removeXXXListener в методе закрытия. Такое дублирование это явно нехороший запах в коде, показывающий непродуманность дизайна.

Мы избавились от этого дублирования в несколько шагов. Сначала, через максимальное абстрагирование и повторное использование кода мы добились, чтобы моделей в приложении было бы существенно меньше чем компонентов. Там где это возможно, используется универсальная модель -- иерархическое дерево контекстов хранящее пары key-value. Её фундаментальное отличие от классических классов типа BeanContext в том, что любое поддерево можно отцепить от контекста приложения вызвав на корне поддерева setParent(null). При этом, все указатели для нотификации о событиях идущих от корня дерева к этому поддереву автоматически обрываются.

Каждое окно или панель приложения создает свой собственный подконтекст в этом дереве. Все компоненты этого окна или панели подписываются на нотификации используя исключительно свой контекст, который окно или панель передает им в конструкторе. А отписываться им вообще не надо. При закрытии окна или панели пользователем вызывается setParent(null) на его контексте, автоматически отписывая все компоненты от идущих снаружи нотификаций.

Cross-platform Browser for Java

Wed, 15 Oct 2008 14:10:13 GMT

У нас есть большое Swing приложение в которое надо интегрировать HTML страницы. Именно интегрировать, а не открывать во внешнем браузере.

Когда эти страницы были простыми, нам хватало встроенной в Swing поддержки HTML. С ней, конечно, масса проблем, если у клиента не быстрый интернет, ибо там всего 4 штуки "image loader" потока, которые забиваются и любая подгрузка иконок в приложении умирает (там используются те же потоки). Но это мы научились обходить. Реальные сложности наступают, когда мы хотим интегрировать полноценные web страницы (JavaScript, современный CSS и всё такое).

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

Сейчас же проблема поддержки Mac встает ребром. Отсюда вопрос: возился ли кто-нибудь с JDIC в течение последних двух лет и есть ли какие комментарии на эту тему? Может там всё радикально улучшилось за два года? А может есть какие-нибудь проверенные альтернативные решения?

P.S. Я знаю что Sun хочет решить эту проблему в JavaFX и, может быть, в Java 7. Но мне-то эту проблему надо решать уже сейчас.

The Road to Java.next

Mon, 13 Oct 2008 07:20:11 GMT

В последнее время всё чаще обсуждается вопросы "Как должен развиваться языка Java?" и "Что придет на смену Java?". В качестве примеров т.н. Java.next языков приводятся Scala, Groovy и множество других экспериментальных и реальных языков. Изучение этих языков, в свою очередь, подпитывает желание добавить ту или иную фичу в Java. Наиболее конструктивная критика Java заключается в том, что для множества реальных задач приходится писать слишком много "boiler plate code". Например, всем известен такой шаблон:

InputStream in = openStream(); try { // ... do something with in. } finally { in.close(); }

Многие хотели бы вместо этого куска когда писать что-то похожее на вот такой код (a la C#), преимущество которого особенно заметно при работе с несколькими ресурсами одновременно:

using (InputStream in : openStream()) { // ... do something with in. }

И вот тут программисты делятся на два лагеря. Одни говорят: давайте добавим в язык Java "cильные" closures (например, по BGGA) и дадим возможность программистам самим менять синтаксис языка, то есть определять конструкции вроде "using" в соответствии с их project-specific потребностями. Другие говорят, что добавить closures это значит дать обезьяне в руки гранату. Читаемость кода существенно упадет из-за огромного количества специальных конструкций которые программисты создадут для своих целей. Давайте добавим конкретные расширения языка once-and-for-all аналогично указанному выше "using" и, тем самым, решим 90% самых острых проблем.

Похожая дискуссия разгорается и вокруг JavaBean properties и шаблонных методов getXXX и setXXX. Современные Java IDE умеют их генерировать (как и другие шаблоны), но пишем-то мы код один раз, а читаем потом десятки раз. Как же сделать Java код более читабельным? Нужно ли для этого добавлять в язык более универсальные или более простые, понятные и конкретные механизмы?

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

Я не знаю ответа на эти вопросы, но я знаю путь который можно использовать для поиска ответов. На этот путь меня натолкнуло вот это обсуждение The Road to Java.next. Вкратце идея такова: вместо того, чтобы добавлять новые синтаксические конструкции в язык, давайте добавим их в наши IDE. Ничто не мешает современному IDE автоматически выявлять шаблоны кода и заменять их на более простые синтаксические конструкции исключительно на экране, в то время как в исходниках они будут оставаться в своем развернутом виде. Это позволит, например, пользоваться конструкцией using в любой версии Java и проверить её применимость на практике не внося необратимых изменений в сам язык Java.

Конечно, не любое потенциальное расширения языка поддается такому эксперименту. Речь идет об исключительно синтаксических конструкциях. Например, очень легко реализовать на уровне IDE т.н. CICE closures, чтобы вот этот код:

executor.submit(new Runnable() { public void run() { action(); } });

на экране вашего IDE выглядел бы как:

executor.submit(Runnable() { action(); });

В то время как BGGA closures не представляются как простая синтаксическая трансформация.

Но это лучше чем ничего, учитывая что синтаксические шаблоны и их эквивалентные замены могли бы втыкаться пользователем в конфигурацию IDE а также включаться и отключаться по желанию. Что по этому поводу думают программисты? Будет ли это полезно? А что думают люди которые работают над созданием Java IDE? Можно ли это реализовать?

Cross-compile Java bytecode to Objective-C

Fri, 15 Aug 2008 15:11:23 GMT

Перед Devexperts стоит задача перевести некий объем бизнес-логики написанный на Java для мобильных приложений на iPhone, где основным языком разработки является Objective-C. Начнем с кода который рисует красивые графики на нашем собственном классе типа Canvas. Речь о GUI в целом сейчас пока не идет -- его мы разрабатываем "с нуля" используя нативные элементы управления на iPhone.

Объем кода для перевода на Objective-C достаточно большой, чтобы у нас не возникало безоговорочного желание написать всё с нуля, так как нам же потом этот код и поддерживать. Хочется вносить все будущие изменения в один code-base. Более того, таких проектов предвидится несколько, то есть в перспективе придется переводить на iPhone несколько различных библиотек и приложений.

Возникла идея разработать кросс-компилятор с Java bytecode в Objective-C и ограничиться пока ref-counting GC, так мы знаем что у нас нет циклов в графе объектов. Занимался ли кто-нибудь чем-нибудь подобным? Нет ли для этого готовых решений? Если готовых решений нет, то на следущей неделе мы официально откроем вакансию на позицию "Senior Developer" под этот проект. Если кому интересно -- пишите.

Google Code Jam 2008: Round 3, Статистика

Tue, 12 Aug 2008 07:51:03 GMT

Закончился 3-ий отборочный раунд Google Code Jam 2008. Дальше будут onsite полуфиналы, которые пройдут в офисах Google по всему миру.

Уже есть первая статистика соревнований как по языкам программирования, так и по странам. Последняя особенно лыботытна. Вот некоторые факты:

По результатам квалификации, наибольшее число прошедших программистов из Индии -- 1016 человек. По результам 3-го раунда из них осталось 11 человек.
На втором месте по этому показателю США -- 949 человек прошло квалификацию. По результам 3-го раунда из них осталось 55 человек.
На третьем месте по этому показателю Китай -- 856 человек прошло квалификацию. По результам 3-го раунда из них осталось 108 человек.
Россия же была представлена лишь 373 программистами по результатам квалификации (4-ый результат). По результам 3-го раунда из них осталось 70 человек (2-ой результат).

Из этого грустный вывод: в России как всегда много умных (в данном случае программистов), но они не готовы и палец о палец ударить ради ~~престижа страны~~ чего-либо (UPDATE: см. дискуссию о мотивации). Я лично знаю несколько хороших программистов, которые имели все шансы пройти 3-ий раунд, но они просто забили болт.

Полное солнечное затмение в Новосибирске

Sat, 02 Aug 2008 12:26:12 GMT

Посмотрели полное солнечное затмение под Новосибирском. Почти "once in a lifetime event", ибо следующее полное затмение проходящее над сколько-нибудь населенной территорией будет еще очень не скоро. Погода как будто специально для всех постаралась -- небо над "Обским Морем" было абсолютно чистое. Осмысленные фотографии было сделать практически невозможно без специальной техники и подготовки. Такое событие сложно целиком передать в виде одного неподвижного кадра. Моя жена снимала на видео (слева снизу в кадре), и может быть после монтажа получится интересный ролик. В общем, отпуск удался на славу!

UPDATE: Следующее затмение можно будет посмотреть 22 Июля 2009 года прямо в Шанхае. Продолжительность затмения фантастические 5+ минут. А вот после этого уже действительно долго ждать.

Google Code Jam 2008: Qualification

Thu, 17 Jul 2008 06:12:53 GMT

Сегодня проходит квалификационный раунд Google Code Jam 2008. Для прохождения к отборочным раундам достаточно сдать определенное число правильных решений из предложенного набора задач до конца сегодняшнего дня. Количество участников проходящих в первый раунд никак не ограничено.

В результате 3-х отборочных раундов с 25 Июля по 9 Августа будут отобраны полуфиналисты, которые будут участвовать в очных соревнованиях в своем регионе (Asia Pacific, Americas, EMEA). Кульминацией события будет финал 14 Ноября с призом в $10k за первое место.

Фундаментальное отличие этих соревнований от других подобных программистских соревнований в том, что решать задачи можно используя любые языки программирования и технологии. Оценка зачет/незачет выставляется на основе отосланного участником файла с ответом на предоставленный организаторами файл с исходными значениями для набора тестов. Исходный код, который использовался для получения ответа, или описание инструментов и порядка их использования также отсылается, но это нужно организаторам исключительно с целью борьбы с мошенниками. Можно вообще решать всё на бумажке, только на каждый файл (содержащий примерно сотню тестов) дается 4 или 8 минут, в зависимости от его сложности. Таймер начинает тикать как только файл был скачан, то есть предполагается, что к этому времени вы уже придумали решение и написали весь необходимый вам код.

По следам JavaOne: Что ждать от Java 7 (Часть 3: Pluggable Type Systems)

Mon, 07 Jul 2008 13:04:00 GMT

В докладе про Upcoming Java Programming-Language Changes есть упоминание про JSR 308: Annotations on Java Types. Вкратце, идея состоит в том, чтобы разрешить указывать аннотации во всех местах Java кода где есть упоминание типа данных (включая определения локальных переменных, фактические и формальные параметры типов, операторы приведения типов и т.п.). Это позволяет создавать свои собственные системы типов путем расширения существующих типов данных аннотациями. Вместе со специализированной версий компилятора javac, реализующего эти расширения, авторы JSR 308 предлагают т.н. "checkers framework", позволяющий писать дополнения к компилятору для проверки ваших собственных аннотаций. Предлагаются готовые решения для проверки кода на предмет соответствия Nullable/NonNull, Readonly/Mutable/..., Interned. То есть, операция @NonNull String s = compute() будет приводить к ошибке компиляции, если тип результата метода compute не аннотирован как @NonNull.

Использование этого механизма ограничено лишь вашей фантазией и требованиями создаваемых вами приложений. Предположим что вы пишете код, который рассчитывает расстояния, скорости, времена и т.п., храня их в переменных типа double. Код сложный для отладки и вы рискуете запутаться в единицах изменениях. Вам нужны гарантии, что километры не складываются с секундами и т.п.. Вы можете создать подходящую систему типов, проаннотировать все ваши double переменные, и написать checker, чтобы убедиться в корректности вашей программы. Можно добиться того, что при наличии в вашей программе @Kilometers double a и @Seconds double b, выражение a + b давало бы ошибку компиляции.

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

Концептуальная сторона такого подхода к разработке приложений и языков описана в замечательной работе Pluggable Type Systems, автором которой является Gilad Bracha. Для общего ознакомления можно посмотреть его слайды. Рассматривая достоинства и недостатки языков со строгой типизацией по сравнению с динамическими языками, он призывает к созданию языков, семантика выполнения которых не зависит ни от какой системы типов, но позволяющих подключать любые системы типов, которые нужны программисту в той или иной предметной области.

По следам JavaOne: Что ждать от Java 7 (Часть 2: Concurrency)

Wed, 11 Jun 2008 05:55:03 GMT

Доклад Brian Goets Concurrency Features in JDK 7 открывается весьма пессимистичным графиком, который наглядно показывает конец роста частоты и начало "multicore era" (по графику видно что это примерно 2003 год). Он рассказывает про парралелизацию вычислений с помощью библиотеки fork-join, которая войдет в Java 7. Это всё еще низкий уровень для прикладного программиста, однако именно такая реализация на низком уровне позволяет эффективно использовать множество ядер для вычислений не затыкаясь на общих локах в очередях заданий, и обеспечивает локальность доступа к памяти в этоху широкого распространения NUMA архитектур. Эффективность этого подхода так же обоснована в докладе Гоэтза.

В конце доклада он рассказаывает про библиотеку ParallelArray, которая построена поверх fork-join, и позволяет декларативно (sql-like образом) производить filter-map-reduce операции над массивами данных прозрачно распараллеливая их на множество ядер. Действительно удобной для использования эта библиотека станет только при добавлении в язык Java замыканый (closures).

По следам JavaOne: Что ждать от Java 7 (Часть 1: Closures)

Mon, 09 Jun 2008 06:23:10 GMT

Сразу оговорюсь, что скоро ждать Java 7 не нужно. Компания Sun Microsystems ударилась в конкуренцию с компанией Adobe и направила все свои лучшие силы на развитие технологии JavaFX. В этом посте я не буду углубляться в обсуждение этого факта и предсказывать победителей, скажу лишь что core Java, в том числе и Java 7, тоже в чем-то от этого выиграет (или проиграет -- это как посмотреть). Сейчас же я поговорю о тех планируемых улучшениях, которые ни как не связаны с технологией JavaFX.

Наиболее радикальным и фундаментальным изменением которое могло бы произойти в Java 7 была бы поддержка в языке Closures. Смотрите доклад Нила Гафтера Closures Cookbook. Более подробная информация, включая прототип реализации находится на www.javac.info. Лично мне не нравится предложенный авторами синтаксис, но даже с таким синтаксом язык Java безусловно улучшится. Я могу назвать массу мест в своем собсвтенном коде, где можно было бы сократить boilerplate код, если бы в языке была поддержка closures. Однако, с большой вероятностью closures в Java 7 все-таки не появятся. Соответсвующее предложение еще даже не зарегестрировано через JCP.

По следам JavaOne: Challenges in Multicore Era

Sat, 07 Jun 2008 07:44:30 GMT

Пора начать серию постов по следам лучших презентаций на прошедшем JavaOne. Все, кто хочет сам порыться в материалах конференции, приглашаются на JavaOne Online.

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

Доклад Challenges in Multicore Era, представленный Azul Systems и Sun Microsystems, это короткий и содержательный отчет о текущей ситауции в индустрии и академическом мире, который рассказывает текущее положение вещей и формулирует нерешенные проблемы. Основная цитата:

The hardware, the OS, and the JVM are ready for large numbers of cores.
The languages, the tools and the programming community at large are not ready for large concurrent programs.
So... good luck, guys!

Для тех кто всеръез увлекается многопоточным программированием с созданием non-blocking алгоритмов (только такие алгоритмы масштабируются на десятки и сотни ядер) очень рекомендую Toward a Coding Style for Scalable Nonblocking Data Structures который также можно посмотреть. Это досточно технически-сложный материал понятный по слайдам только тогда, когда уже всё знаешь.

Java + OpenGL

Tue, 27 May 2008 21:27:42 GMT

У кого-нибудь есть опыт OpenGL на Java? Отзывы? А желание этим заниматься full-time? Есть предложение по работе в Devexperts. Могу рассказать подробности лично.

Список книг которые должен прочитать каждый Java программист

Tue, 27 May 2008 10:47:48 GMT

Здесь собран список лучших, по моему мнению, когда либо написанных книг про Java. Книги расположены в порядке их важности (первыми указаны наиболее фундаментальные).

0. Java Language Specification 3rd Edition by James Gosling et al это самая главная книга, книга номер "ноль" этого списка, известная также как JLS. Она доступна в HTML виде здесь. В третьей редакции описывается 5-ая версия языка. Я считаю, что каждый Java программист должен прочитать JLS хотя бы раз. Необходимо знать все возможности предоставленные языком для того чтобы использовать их самому и для того чтобы понимать код написанный другими. JLS это аналог JavaDoc или другой документации для используемых вами библиотек. Однако, в отличие от библиотечных классов, для которых документация обычно доступна из вашей среды программирования, по языку контекстная документация в средах программирования не предоставляется, поэтому JLS нужно читать практически "от корки до корки" хотябы на уровне оглавления и общего содержания каждого пункта. JLS является обязательной литературой при подготовке к сдаче экзамена на Sun Certified Java Programmer (SCJP)

1. Effective Java 2nd Edition by Joshua Bloch рассказывает как именно надо использовать язык Java, чтобы писать хорошие и понятные другим программы. Это сборник практических советов и шаблонов которые должны быть в репертуаре каждого Java программиста. Во второй редакции своего бестселлера Блох рассказывает об эффективном использовании всех возможностей 5-ой версии Java. Даже программист с многолетним опытом откроет в ней что-то новое и уж точно получит удовольствие от систематизации всех основных знаний про программирование на Java.

2. Java Concurrency in Practice by Brian Goetz et al необходима всем, кто пишет многопоточные приложения на Java. Её не нужно читать если вы пишете простые приложения а для бизнес-логики используете J2EE или другие каркасы приложений которые изолируют программиста от многопоточности. Однако, как только вам необходимо оптимизировать производительность или скорость реакции вашего приложения, то в современном мире от многопоточности вам не уйти. В этом случае книга Гоэтза будет вашим лучшим помошником.

3. Java Puzzlers: Traps, Pitfalls, and Corner Cases by Joshua Bloch, Neal Gafter это интересная книга которая состоит из интеллектуальных загадок исключительно на языке Java. Она раскроет перед вами все граничные случаи языка Java, научит как не надо программировать, чтобы ваш код был понятен. Книжка не обязательна для прочтения, но очень рекомендуется для подготовки к SCJP и для собственного удовольствия.

Последний день JavaOne

Sat, 10 May 2008 16:40:41 GMT

На закрывающей речи выступал James Gosling и показывал различные технологические новинки. Можно посмотреть полный webcast или прочитать краткий отчет в его блоге. Я стал жертвой рекламы и под впечатлением от презентации купил себе Livescribe Pulse SmartPen. Игрушка фантастической прикольности, плюс SDK позволяющий писать для неё приложения на Java. Насколько же она удобна в повседневной жизни покажет практика. Потом поделюсь впечатлениями.

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

Третий день JavaOne

Fri, 09 May 2008 15:46:30 GMT

Некоторые подробности про New I/O в Java 7 - JSR 203. Обещали закрыть практически все мыслимые проблемы и недоработки ввода-вывода в Java. Можно будет получать нотификации об изменениях файлов, работать с символическими ссылками, безопасно ходить по дереву каталогов, эффективно копировать и перемещать файлы (с копированием прав при желании), работать напрямую с правами файлов и другими специфичными для платформы атрибутами файлов. Можно будет писать свои реализации файловой системы. На сетевом уровне обещают перевести все операции с сокетами на channels, то есть все операции (включая доступ к нестандартным параметрам соединения) можно будет делать без обращения к классу Socket.

The Garbage First Garbage Collector (aka G1) -- единственный доклад (по признаю авторов) в названии которого 50% мусора :) Он ждет нас в Java 7 как замена CMS. Очень, очень грамотный алгоритм. Будем надеятся, что они смогут довести до ума реализацию (там еще есть над чем поработать). Доклад проводился совместно с CBOE -- они один из крупнейших клиентов Sun, а вся биржевая система CBOE написана на Java. Потрясает воображение их тестовая система, на которой они и откатывают различные нововведения типа новых алгоритмов GC. Собственно, внутри Sun разработчики проводят только различные микро-тесты и синтетические тесты, в то время как сотрудничество с CBOE позволяет им прогонять свои алгоритмы на реальных системах.

Cliff Click упростил доказательство своей революционной реализации ConcurrentHashMap, которая обгоняет последний на 10% даже на машинах с малым числом процессоров (16-32), а на машинах с количеством процессоров приближающемся к 1000 вообще не имеет равных, в силу того что алгоритм полностью Lock-Free. В этом году Cliff Click продемонстрировал как используя такой же подход написать параллельный Lock-Free BitSet, и "почти" FIFO очередь которая масштабируется на тысячи процессоров. Код доступен в SourceFourge как часть high-scale-lib.

Второй день JavaOne

Thu, 08 May 2008 16:08:22 GMT

Слушал много сессий :) Neal Gafter рассказывал про Closures , Alex Buckley про модульность, Cliff Click cделал очень веселый рассказ про data races.

К сожалению, Cliff Click подтвердил что "state of the art and state of the practiсe" в отладке data races это визуальные инспекции кода, аккуратное документирования и т.п. В общем, читайте замечательную книгу "Concurrency in Practice" by Brian Goetz. Процесс абсолютно не масштабируемый, но ничего лучше сейчас просто нет. Единственный инструмент каторый как-то может помочь на практите это FindBugs. Его автор "Mr. Skip-List" Bill Pugh, как всегда, сделал шикарный доклад с примерам про то как казалось бы абсолютно идиотские ошибки (типа метода equals который всегда возвращает false), после добавления их описания в FindBugs, были обнаружены в десятке мест в JDK, Glassfish, TomCat и других больших проектах.

Слушал доклад про Transactional Memory. В то время как существуем масса реализаций STM (software transactional memory), они все создают существенные накладные рассходы. Однако есть и перспективное направление развития -- Hardware Transactional Memory. Именно здесь нас скорей всего ждет прорыв в направлении масштабируемого многопоточного программирования. Но сначала должны появиться массовые процессоры поддерживающие транзакции с памятью на аппаратном уровне.

Открытие JavaOne

Tue, 06 May 2008 21:53:02 GMT

На открытии показали красивое JavaFX демо-приложение "Connected Life" (агрегатор facebook, flickr, etc) работающее под JavaSE. Показали как используя Java 6u10 можно загрузить аплет, а потом "вытащить" его из браузера и сделать desktop приложением. Его же показали работающим на JavaME телефоне, и его же работающем на эмуляторе Android-а. НЕ показали работающим его под iPhone (что было вполне ожидаемым). А еще оно подвизало из-за тормозного интернета здесь, в Moscone, что навело на грустные мысли о неумении основной массы программистов писать networked/connected графические приложения (HINT: проблема в однопоточности современных GUI frameworks в комбинации с блокирующими примитивами работы с сетью и с внешними сервисами).

Показывали интеграцию JavaFX с HD-видео (2D приложение в которое было заинтегрировано видео) и 3D (куча виртуальных эранов играющих видео летали по сфере). Красиво, но были видны моменты когда срабатывал GC.

Пообещали что JavaFX Desktop выйдет осенью 2008-го, а mobile версия весной 2009-го.

Еду на JavaOne

Mon, 28 Apr 2008 10:23:50 GMT

5-го Мая улетаю в командировку в США. Первая остановка в моем маршруте будет на JavaOne. Буду писать здесь обо всем интересном, что доведется там увидеть.