вівторок, 23 жовтня 2007 р.

Суперпакеты и Джава Модуль

JSR 294 Improved Modularity Support (superpackages)

Улучшенная поддержка модульности – суперпакеты

Позволяет объединять пакеты в суперпакеты и управлять доступом к ним (в основном для «скрытия деталей реализации»). Позволяет осуществлять доступ только к опубликованным API. Это предотвращает возможность потребителя зависеть от внутренних деталей и позволяет изменять некоторые аспекты реализации без затрагивания потребителей.

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

Суперпакеты будут встроены как в компилятор (javac) так и в виртуальную машину Джава.

superpackage example.bar.lib {     
// member packages
member package example.bar.lib;
// member superpackages
member superpackage example.bar.lib.net, example.bar.lib.xml;
// list of exported types
export example.bar.lib.Table;
export superpackage example.bar.lib.net;
}


JSR 277 Java Module System


Недостатки JAR:

Поддержка версий в JAR файлах служит для определения зависимостей от расширейний Джава (опциональных пакетов), но не версии самого Jar файла. Также нет надежного механизма для выражения, получения зависимостей одного JAR файла от другого. Ссылаясь на JAR файл, кроме всего прочего, необходимо указать его в classpath. Если путь к JAR файлу может изменится во время распространения конечному пользователю, разработчикам необходимо исправлять все эти ссылки для JAR файлов как части установочного процесса.

Разработчики также нашли что достаточно тяжело распространять Джава расширения из-за того что легко могут возникнуть проблемы с определением версий и коллизий области видимости (namespace). Джава расширения на данный момент могут устанавливатся только на указанную JRE; невозможно организовать так чтобы установленное расширение разделялось несколькими JRE.

Все эти недостатки призван исправить JAM.

Спецификация определяет формат распространения и репозиторий для коллекций Джава кода и соответствующих ресурсов. Также определяет механизмы нахождения, загрузки и интеграции во время выполнения. Определяет новый архив развертывания называемый JAM (Java Module). Java Module это JAR файл который содержит другие JARы, ресурсы и метаданные. JAM может специфицировать какие части модуля публичные (public) а какие скрытые (hidden). JAMы может специфицировать зависимости от других модулей.

Архитектура:

  1. Формат распространения (Джава модуль) и его метаданные как единица доставки – для упаковки коллекций Джава классов и связанных ресурсов. Метаданные содержат информацию о модуле, классах и ресурсах которые находятся в модуле, и зависимости от других модулей. Метаданные также содержат список всех экспортируемых элементов для защиты классов и ресурсов от того чтобы они были использованы за пределами модуля не по назначению;

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

  3. Репозиторий для хранения, поиска и получения модулей с поддержкой версионности и изолированности.

  4. Поддержка времени выполнения в загрузчике приложения и загрузчике классов поиска, загрузки и проверки целостности модулей.

Пример:

  1. Запуск модулей используя Java launcher

//Запустить найстаршую версию com.wombat.webservice

java -module com.wombat.webservice

//Запустить com.wombat.webservice версии 1.2.0 или старше

    java -module com.wombat.webservice:1.2.0+

  1. Импортировать пользовательский модуль

ImportModule(com.sun.java2d, @VersionConstraint(”1.7.0”))

  1. Пример модуля

@Version(“1.0”) // module annotation

super package com.wombat.webservice { // module name

// импорт модуля не ниже версии 1.0

@VersionConstraint(“1.0+”)

import org.foo.xml;

.....

}

суботу, 20 жовтня 2007 р.

Когда выйдет Consumer JRE?

Consumer JRE будет обновлением для Java SE 6, что означает что оно будет доступно намного быстрее чем если б оно было частью одного из больших релизов таких как Java SE 7. Но до сих пор еще много работы, и она еще не сделана. Запланированная дата релиза Consumer JRE начала 2008, также команда пытается сделать работу как можно быстрее. Из-за размеров и типа изменений в этом релизе, в особенности Java Kernel, этот релиз потребует широкого тестирования чтобы быть уверенными что он настолько согласовано настолько, насколько ожидается.

Команда выпустить некоторые фичи как только они будут доступны, так что вам не прийдется ждать начала 2008 чтобы получить все то что обсуждалось.

PS. на этом оканчивается обзор этой статьи – будем ждать выхода финальной версии – благо осталось не долго ;) Далее продолжим обзор новых фич которые появятся в Java 7

Nimbus Look and Feel

Metal look and feel показаный на изображении был хорошим в свои дни:





















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




















Но эти кросс платформенные look and feels устарели, и Swing приложения требуют более современного вида. Конечно другие look and feels также доступны, и достаточно неплохие, и разработчикам необходимо исследовать эти продукты и проекты на возможность использования их в своих приложениях. Но в то же время, Swing разработчики должны иметь приличный look and feel в самой платформе. Nimbus это как раз тот look and feel

Изображения это примеры Nimbus look and feel на данный момент:
















SwingSet2 использующий Nimbus Look and Feel:

















Для более подробной информации по Nimbus можно посмотреть Jasper Potts's blog.


Graphics Performance on Microsoft Windows

Команда Десктоп разработчиков переписывает графическую реализацию на Виндовз чтобы иметь преимущества от Direct3D для выполнения операций начиная с обычной заливки прямоугольников и их копирования, это то сейчас получает пользователь по умолчанию, до прозрачности, градиентов, произвольных преобразований, и других более сложных 2D операций. Как результат: простые и сложные Swing приложения должны более быстро выполнятся в среде Виндовз.

Swing выполняет свою отрисовку через Java 2D API и таким образом зависит от скорости отрисовки Java 2D. Начиная с J2SE 1.4, платформа Джава начала использовать нативные функции для ускорения аппаратного обеспечения через DirectX на Виндовз но только для базовых операций заполнения и копирования прямоугольных областей и горизонтальных и вертикальных линий.

Такие простые примитивы очень важны для отрисовки Swing, из-за того что большая часть пользовательского интерфейса состоит из таких примитивов, и возможность кэшировать второй (задний) буфер Swing как изображение VRAM позволяет очень быструю двойную буферизацию. Но пользовательский интерфейс становится более сложным, и возможность ускорить более сложные операции, такие как прозрачность, градиенты и операции масштабирования становится очень важной.

Команда Java 2D продолжила работу над отрисовкой с помощью DirectX, которая теперь имеет возмость ускорять большое количество операций с помощью нативных библиотек Direct3D на Виндовз. Тем не менее эти улучшения производительности не включены по умолчанию из-за комбинации проблем связанных со скоростью и надежностью. Тем временем, 2D команда также реализовала отрисовку с помощью OpenGL с еще более расширенными возможностями, но этот механизм также не включен по умолчанию из-за проблем связанных с надежностью на некоторых платформах.

Сейчас Java 2D команда переписывает механизм отрисовки DirectX чтобы копировать возможности которые уже есть в OpenGL механизме, с исправлением ошибкоустойчивости которая сделает его более жизнеспособным отрисовщиком по умолчанию. Эта фича должна быть активирована по умолчанию, пердоставляя возможность Swing очень быстрого аппаратного ускорения через графический процессор. Это должно ускорить работу для нынешних Swing приложений, но оно позволить намного более сложным и мощным Swing приложениям запускаться достаточно быстро, даже если содержит более более богатые и динамические, анимированные эффекты в ихнем графическом пользовательском интерфейсе.

Installer Improvements

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

Текущий диалог установки:
















Новый диалог установки:














середу, 17 жовтня 2007 р.

Deployment Toolkit

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

На сегодняшний день основной механизм для автоматического определения Джава на пользовательской системе был ActiveX элемент называемый Auto-Install, выпущенный в J2SE 5.0. Этот механизм был ограничивался только браузером МС ИЕ, и только если пользователь разрешал выполнение ActiveX-контролов. Остальные способы заключались в том чтобы перенаправить пользователя на java.com для установки Джава платформы и надеяться на то что он вернется на ваш сайт.

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

Плагин к браузеру которые представляет высокий уровень определения, установки и запуска остается, но сейчас он портирован также на ФФ на Виндовз. Но если плагин не может быть использован, тогда JavaScript решение также существует которое хостится в основном на сайте Sun. Он содержит маленький кусок кода которые запускается на стороне разработчика, которые позволяет делать намного больше чем текущий ручной подход.

Плагин может определять версии Джава с точностью до версии апдейста, и автоматически может запускать установку новой версии, запуская приложение когда установка завершится. Решение на JavaScript не столь мощное, но тем не менее позволяет определять версию Джавы до уровня семьи – например J2SE 5.0, Java SE 6 и так далее. JavaScript версия не может запускать Джава установщик напрямую, но может перенаправить пользователя на соответствующую страничку загрузки и далее вернуть на оригинальную страничку и запустить приложение после завершения установки.

Java Kernel

Проект Java Kernel связан с проблемой времени на запуск для тех пользователей у которых не установлена подходящая JRE. Например если ваше приложение требует наличие Java SE 6 у пользователя, и он у них не установлен, они должны его установить перед запуском приложения. В зависимости от размера JRE и ширины канала доступного пользователю, время загрузки и установки может занимать от десяти секунд до десяти минут. Проект Java Kernel уменьшит это время значительно, позволяя приложению устанавливать только то что ему необходимо для запуска.

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

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

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

Основные работы выполняемые Java Kernel:

  • Загрузка базовой функциональности которая необходима каждому приложению: Виртуальная машина, сборщик мусора, политики безопасности.

  • Загрузка дополнительных зависимостей которые специфицирует приложение

  • Загружать любой из Class not found ошибки.

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

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



вівторок, 16 жовтня 2007 р.

Consumer JRE - Quickstarter

Что такое Consumer JRE?


Consumer JRE состоит из нескольких важных частей. Одна из целей это как можно быстрее реализовать необходимые функции и войти в состав одного из ближайших обновлений Java 6 SE. Также необходимо чтобы изменения не влияли на API. Например можно добавить функциональность для увеличения скорости загрузки не влияя на API или функциональность которую использует приложение. Но нельзя добавить новое API для анимации в качестве обновления текущей версии.

Основные части:

  • Quickstarter. Радикально уменьшает время загрузки для приложений и апплетов.

  • Java Kernel. Уменьшает время на установку и запуск когда у пользователя не установлен JRE.

  • Deployment toolkit. Позволяет быстро определять и инсталлировать JRE.

  • Installer improvements. Улучшения в установке.

  • Graphics performance on Microsoft Windows. Позволяет осуществлять графическую акселерацию для простых и сложных 2D объектов.

  • Nimbus look and feel. Выпуск нового кросс-платформенного look and feel.

Quickstarter

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

Существует две возможности запуска Джава приложения: горячий и холодный старт. Горячий старт это время которое занимает запуск Джава приложения когда вы недавно его запускали на вашей системе и остались кэшированные данные. Холодный старт, с другой стороны, соответствует времени затраченному для первого запуска Джава приложения после перезагрузки системы.

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

Холодный старт с другой стороны занимает неоправданно большое количество времени. Необычно видеть когда загрузка апплета занимает от 5 до 10 секунд (иногда даже больше). Такая задержка может быть допустима для больших десктопных приложений, таких как IDE которые работают целый день и включаются только утром. Такое время загрузки для апплетов недопустимо и ограничивает их жизнеспособность как легковесного пользовательского контента.

Проблема находится на уровне ОС. Но это не такая уж и сложная проблема, это показатель того что платформа Джава столкнулась с базовыми физическими ограничениями на уроне ОС и железа. Файлы которые составляют полную Джава платформу большие по размеру. Например, в недавней версии Java 6 SE файл rt.jar занимает более 40 МБ. Если к этому еще добавить различные jar, нативные библиотеки, файлы ресурсов которые загружаются вне зависимости от кода приложения, то получается большой объем данных которые необходимо считать.

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

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

Исправление заключается в том чтобы использовать преимущества дискового кэша для того чтобы страницы памяти на диске которые платформа должна считать при загрузке уже были загружены ранее. За счет чего это может быть получено? Платформа не может магически предварительно загружать страницы прямо перед запуском. К сожаления, Виртуальная машина Джава в данный момент не имеет возможности «смотреть» в будущее чтобы определять когда пользователь будет запускать джава приложение. Но предварительную загрузку платформа может проводить немного ранее, например при загрузке Виндовз или во время авторизации. Все страницы могут оставаться горячими в дисковом кэше пока позволяет состояние памяти.

Следует заметить что такой подход не тоже самое что загрузка полной Джава машины. Такой подход будет решать некоторые проблемы но в мене эффективной манере, закрывая память в менее дружелюбный к ОС способ. Подход Quickstarter будет работать с дисковым кэшем сам по себе, позволяя ОС использовать системную память и дисковый кэш как ей удобно.

Оригинал http://java.sun.com/developer/technicalArticles/javase/consumerjre/