11 апреля 2011 в 16:15

Расширяем возможности Java-приложения из песочницы

Здраствуй, Хабражитель!

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

Итак, сегодня я приведу здесь библиотеки, которые могут Вам помочь решить часто возникающие вопросы вроде «Как сделать это на Java?» по разным узким направлениям разработки.

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

To choose or not to choose?


Думаю во многих приложениях встает необходимость выбора/открытия/сохранения файла из/в файловую систему — наверное, это одна из самых широко используемых частей. Стандартные средства J2SE предлагаю для этого свой кросс-платформенный инструмент — JFileChooser. Сам по себе он выглядит «более-менее», но отличается от нативных диалогов, которые предложит Вам Ваша операционная система (далее ОС). К тому же под Linux и MacOSX он представляет собой некое «наколенное» решение, которое вообще не понятно как просочилось (и до сих пор присутствует) в последние версии JDK.
Есть также и другой стандартный вариант — AWT'шный FileDialog. На Windows он практически идентичен стандартному выборщику файлов, но на других ОС он полностью сдает свои позиции и еще хуже JfileChooser'а. Так что же делать?

Тут на помощь придет наработка от Eclipse — SWT. В их наборе присутствует «аналогичный» FileDialog, который впрочем на каждой отдельной ОС вызывает нативный диалог для выбора файлов, который можно нехило кастомизировать при желании на свой вкус. Также дополнительно есть еще и DirectoryDialog для выбора сугубо директорий. На мой взгляд, если Вам необходимо быстрое и достаточно опрятное решение — это наилучший вариант. Единственный минус — придется тащить за собой достаточно громоздкие библиотеки SWT (впрочем, вероятно ваше знакомство не ограничится только этими двумя диалогами, тогда игра точно стоит свеч).
Существует еще и небольшая накрутка над SWT непосредственно к FileDialog/DirectoryDialog в библиотеке Native Swing — о ней я расскажу чуть позже.

Grab and run!


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

При помощи библиотеки JIntellitype (под Windows) или же JXGrabKey (аналог для Linux) возможно это сделать.

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

Увы, но аналогов данных библиотек для MacOSX я не нашел (даже малейших упоминаний об их существовании) — буду рад дополнить, если кто наведет на нее.

Дабы немного разбавить текст, приведу небольшой пример по использованию JIntellitype:

// Некий ID для вашего хоткея, для дальнейшего добавления события
int id = 0; 
// Путь к библиотеке (обязательно абсолютный)
JIntellitype.setLibraryLocation ( "С:\\lib\\JIntellitype.dll" ); 
// Регистрация хоткея
JIntellitype.getInstance ().registerHotKey ( id, Jintellitype.MOD_CONTROL, KeyEvent.VK_SPACE );
// Регистрация действия
JIntellitype.getInstance ().addHotKeyListener ( new HotkeyListener() {
	public void onHotKey ( int i )
	{
		if ( id == i )
		{
			// Обрабатываем событие по хоткею
 		}
	}
} );


Все достаточно просто и понятно (работа с JXGrabKey абсолютно аналогична).
Есть лишь один нюанс по использованию данной библиотеки — при создании какого-либо хоткея (как например в данном случае CTRL+SPACE) он будет заблокирован для всей системы. Т.е. его будет получать только лишь Ваше приложение. По крайней мере такой нюанс был замечен под windows, не уверен насчет Linux версии. Именно поэтому я дописывал дополнительный обработчик, выключающий определенный хоткей при необходимости:

// id – тот самый ID, который использовался при создании хоткея
JIntellitype.getInstance ().unregisterHotKey ( id );


Важно знать, что для 32/64-битной версии JVM (именно JVM, а не вашей ОС) потребуются 32/64 битные сборки нативных библиотек соответственно. Это важный момент, так как для всех других библиотек с нативной частью он также действителен.

Flash in the night


Думаю, данная тема может быть весьма заезжена, но все же опишу те проблемы, которые я встретил при попытке запуска Flash-роликов в Java-приложении.

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

Итак, перейдем к вариантам.

Native Swing – да, в наборе данной библиотеки также есть и возможность встраивать Flash в Ваше приложение (реализовано на основе функционала SWT). Опробовал под Windows и Mac — непосредственно пример от разработчика корректно исполняется на обоих. Под Linux не все так гладко (вероятно из-за проблем с Flash-плагинами) — без танцев с бубнами корректировки библиотек в системе и настройки плагинов запустить Flash не удастся.
Также возникают непонятные проблемы с путями при наличии установленного в браузере прокси (вероятно для отображения используется браузерный Flash-плагин и соответственно прокси влияет на его работу). Впрочем пару раз успешно запустить разные Flash-ролики под Windows мне таки удалось. Есть также возможность «общения» с самим Flash-роликом стандартными средствами библиотеки.

JFlashPlayer – отдельная платная библиотека, реализующая работу с Flash-плеером исключительно под Windows. Работает вполне стабильно и быстро. При необходимости использования Flash специально для win платформы, думаю, будет наилучшим выбором, так как напрямую работает с Flash API и не требует никаких дополнительных громоздких библиотек.

Draw it… I said draw it now!


Итак, дабы не задерживаться на «обилии» Flash-реализаций в Java перейдем к наиболее развитой части, а точнее — к библиотекам, дополняющим список возможных к открытию/редактированию/записи форматов изображений. В данной области — кто на что горазд. Понаписано много разного — от небольших классов, до целых огромных коммерческий библиотек.

Итак, что же исходно умеет читать J2SE и чему бы хотелось его «обучить»?
Посмотрим список: gif (сложности с анимированными gif'ами), png, jpeg, bmp, wbmp
Что бы хотелось: gif (анимированные), apng, tiff, psd (возможно что-то еще?)

Начнем по-очереди…

Анимированные gif'ы – здесь имеется пара проблем, первая — возможность считывания отдельных фреймов (и последующей корректной записи их) и информации об задержке между ними, вторая — корректное сохранение полностью прозрачных пикселей gif изображения.
Первая проблема быстро решается использованием дополнительных библиотек (gif4j, Imagero, отдельные Decoder/Encoder), которые позволяют считывать/записывать фреймы и информацю о них.
Решения второй проблемы я нигде не нашел, поэтому дописывал вручную, исходя из спецификации gif формата — необходимо находить неиспользуемый в изображении цвет и помечать его «прозрачным» для данного фрейма gif'а, что в дальнейшем говорит рендереру изображения о прозрачности всех пикселей с данным цветом. Впрочем для непосредственной записи я использовал приведенный выше Encoder.
Если кого-то это заинтересовало, могу отдельно снабдить работающим кодом, просто он слишком громоздкий, для показа здесь.

Apng (анимированные png) – достаточно новый формат, впрочем даже учитывая это, уже есть обертка для работы с ним (как минимум для чтения). Собственно найти сам код возможно тут JavaPng.
На данный момент apng формат изображений полноценно умеет отображать только Firefox (3.6+), Opera (9.5+) и некоторые отдельные приложения в виду своей специфики, впрочем изображения в данном формате могут быть весьма полезны в некоторых случаях.

Tiff, psd и некоторые другие — под tiff/psd и множество других менее популярных форматов я нашел единую библиотеку Imagero. Подробнее о всех поддерживаемых форматах проще прочитать прямо у них на главной странице. Больше всего меня, конечно, интересовала поддержка PSD формата, если быть точным — насколько широк спект возможных операций со слоями/изображениями, какие данные можно вытащить, какие версии файлов возможно считать/записать и прочее. После некоторого времени удалось выяснить, что возможно считывать слои, информацию по ним (расположение, название, цвета и пр.), считывать изображения с каждого слоя отдельно, а также узнавать некоторую другую информацию. Впринципе этого более чем достаточно, чтобы на базовом уровне иметь возможность отобразить PSD изображение в своем приложении.
Файл, который я проверял этой библиотекой был сделан в Adobe Photoshop CS3, поэтому я не уверен, что форматы более новых версий будут читабельны.

Time to surf


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

Итак, перейдем сразу к вариантам реализаций, которые я встречал…

JDIC (Java Desktop Integration Components) — наверное одно из самых давних решений. С самого появления в библиотеке была возможность встраивать браузер текущей ОС в Ваше приложение. Также в библиотеке было (и есть до сих пор) достаточно много проблем и ошибок. Да сама библиотека обновляется очень редко (вроде на данный момент она уже прилично устарела). Впрочем в одном нашем старом проекте до сих пор висит встроенный через JDIC браузер и вполне себе работает. Встраивать библиотека умеет Firefox и IE (насчет второго точно не скажу, ибо у нас не получалось заставить его работать). Работает под Windows/Linux.

Native Swing – да, опять и снова, в данной библиотеке собрано много всего интересного включая возможность встраивания нативного браузера текущей ОС. Работает стабильно и без проблем под всеми наиболее известными ОС (Windows/Linux/MacOS) — лично проверял на разных вариантах. Собственно, сама библиотека просто использует функционал SWT и делает немного более человечными различные компоненты и возможности (в данном случае возможность исползования браузера).

Lobo Browser — еще один достаточно устаревший проект. Сам браузер реализован полностью на Java, впрочем его работоспособность оставляет желать лучшего. Большинство современных сайтов/приложений он «не тянет» (просто заваливается при рендеринге страниц). Думаю может быть полезен в некоторых отдельных случаях, когда нужно вставить в приложение какие-либо незаурядные странички (к примеру формы с регистрацией, или отправкой письма), на большее он скорее всего не способен.

WebRenderer – одна из коммерческих разработок в этом направлении. Собственно сам браузер использует движок от FF3. С большинством современных сайтов и приложений справляется на ура. Поддерживаемые ОС — Windows, Linux, MacOSX и пара других. Насчет Mac/Linux не скажу, но под Windows я пробовал этот вариант — работает вполне приемлемо. Кстати, браузер также умеет воспроизводить Flash-ролики и Java-апплеты, что не может не радовать. Встает немного другой вопрос — насколько он актуален, учитывая что HTML5 уже на дворе, а данный движок поддерживает только предыдущую версию. Возможно производители со временем перейдут на новую версию Firefox и этот вопрос уйдет сам собой.

JWebPane – ну и в завершении немного фантастики… Уже давно (с далекого 2008 года) ожидается выход swing-ового JWebPane компонента, который должен раз и навсегда решить проблему «Где взять браузерный компонент на Java?» так как он будет: полностью написан на Java, поддерживать современные стандарты Html/JS, рендеринг средствами Swing и множество других интересных моментов и возможностей. Впрочем, исходя из некоторых статей и сообщений — на данный момент ставки делаются на JavaFX (который некоторые весьма негативно воспринимают) и поэтому работы по данному компоненту и некоторым другим интересным направлениям банально отложены (или же вообще заброшены?).

Такая вот ситуация на «фронте» Java-браузеров. Брать ли надстройки для использования полноценных браузеров или же «костыли» в виде неких готовых решений — выбирать Вам, у обоих вариантов есть известные плюсы и минусы и свои тонны проблем и косяков. Или же можно ждать и надеяться на JWebPane, если Вы достаточно оптимистичны ;)

Showtime


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

На ряду с вопросами о браузерах, Flash и прочих нативных вещах в Java, зачастую интересуются возможностью воспроизведения видео. Итак, рассмотрим какие есть варианты…

JMF – вероятно первое что вспоминается на тему данного вопроса. Сам по себе JMF не может воспроизводить современное видео — ему необходимы плагины, которые бы распознавали различные форматы. Без них он фактически бесполезен. Понятное дело нашлось немало энтузиастов, дописавших эти самые плагины, но со временем их поддержка и обновление, вероятно, стали невозможны или же просто были заброшены.

Fobs4jmf – собственно при поиске тех самых плагинов для JMF, в свое время, я наткнулся на данную библиотеку, которая по факту является плагином для JMF и оберткой для ffmpeg. Впрочем, подтверждая мои слова, — библиотека не обновлялась с далекого 2008 года. Даже учитывая это, достаточно большую часть современного видео она все еще может воспроизводить (лично попробовал и убедился в этом), хотя на том что не удается воспроизвести намертво падает JVM.

Native Swing — в наборе данной библиотеки есть также и интересный вариант, позволяющий встраивать Windows Media Player в Ваше приложение и управлять им и его настройками. Возможное к воспроизведению видео в данном случае будет ограничено установленными на Вашей машине кодеками, которые умеет использовать WMP. И, понятное дело, это Windows-only решение.

VLCJ (Java Bindings for VideoLAN) — как можно понять из названия — эта библиотека является оберткой к кросс-платформенному видео-плееру VLC. Сам по себе данный плеер не опирается на установленные в системе кодеки, а всегда имеет «всё с собой». Соответственно при использовании его в связке с Java-приложением можно быть полностью независимым от системы, установленных кодеков и некоторых других нюансов. Впрочем для сборки своего Java-приложения под разные ОС, понятное дело, понадобится взять необходимые нативные библиотеки из установленного VLC и корректно задать пути к ним при инициализации vlcj:

String path = "C:\\MyProject\\lib";
NativeLibrary.addSearchPath ( "libvlc", path );
System.setProperty ( "jna.library.path", path );


Нативные библиотеки можно просто поместить в свой проект/инсталлер приложения и всегда иметь под рукой. Далее можно сразу же приступать к использованию Embedded плеера:

Canvas vs = new Canvas ();

MediaPlayerFactory factory = new MediaPlayerFactory ();

final EmbeddedMediaPlayer mediaPlayer = factory.newEmbeddedMediaPlayer ();
mediaPlayer.setRepeat ( false );
mediaPlayer.setEnableKeyInputHandling ( false );
mediaPlayer.setEnableMouseInputHandling ( false );

CanvasVideoSurface videoSurface = factory.newVideoSurface ( vs );
mediaPlayer.setVideoSurface ( videoSurface );

someContainer.add ( vs, BorderLayout.CENTER );

mediaPlayer.playMedia ( "C:\\video\\SomeVideo.avi" );


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

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

So what?


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

SWT (stable) (dev)
Лицензия: EPL
Совместимость: Windows/Linux/MacOSX и другие
Кросс-платформенная: Да, но для каждой отдельной ОС и архитектуры необходимо использовать отдельный набор библиотек

Native Swing (stable)
Лицензия: LGPL
Совместимость: Windows/Linux/MacOSX
Кросс-платформенная: Да

JIntellitype
Лицензия: Apache License 2.0
Совместимость: Windows
Кросс-платформенная: Нет

JXGrabKey (stable)
Лицензия: LGPL 3.0
Совместимость: Linux
Кросс-платформенная: Нет

JFlashPlayer (demo)
Лицензия: Commercial
Совместимость: Windows 98/Me/NT4/2000/XP/Vista
Кросс-платформенная: Нет

Gif4J (demo)
Лицензия: Commercial
Совместимость: All java-supported platforms
Кросс-платформенная: Да

Imagero (stable)
Лицензия: Free for non-commercial use
Совместимость: All java-supported platforms
Кросс-платформенная: Да

JavaPNG (stable)
Лицензия: GPL 3.0
Совместимость: All java-supported platforms
Кросс-платформенная: Да

JDIC (stable | win32 libraries)
Лицензия: LGPL 2.1
Совместимость: Windows/Linux
Кросс-платформенная: Да, но для каждой отдельной ОС и архитектуры необходимо использовать отдельный набор библиотек

Lobo Browser (stable)
Лицензия: GPL
Совместимость: All java-supported platforms
Кросс-платформенная: Да

WebRenderer (demo (требует регистрация))
Лицензия: Commercial
Совместимость: Windows/Linux/MacOSX/Solaris/AIX
Кросс-платформенная: Да, но для каждой отдельной ОС и архитектуры необходимо использовать отдельный набор библиотек

JMF (stable)
Лицензия: SCSL
Совместимость: All java-supported platforms
Кросс-платформенная: Да

Fobs4JMF (stable)
Лицензия: LGPL
Совместимость: Windows/Linux/MacOSX
Кросс-платформенная: Да, но для каждой отдельной ОС и архитектуры необходимо использовать отдельный набор библиотек

VLCJ (stable)
Лицензия: GPL 3.0
Совместимость: All java-supported platforms
Кросс-платформенная: Да, но для каждой отдельной ОС и архитектуры необходимо использовать отдельный набор библиотек

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

Все данные по библиотекам и их актуальности были перепроверены мной за последние 2-3 дня и если я где-то ошибся или что-то недосказал — буду рад дополнить или исправить.

Update 1: Добавил ссылки на загрузку библиотек (JDIC недоступен для загрузки с офф. сайта, поэтому выложил отдельно на ifolder)
Автор: @mgarin
ALEE Software
рейтинг 39,27
Компания прекратила активность на сайте
Похожие публикации

Комментарии (25)

  • 0
    Отличная подборка, в избранное!
  • –1
    > JIntellitype (под Windows) или же JXGrabKey (аналог для Linux)

    А Вы уверены что не наоборот?
    • +1
      На главной JIntellitype же даже дана ссылка на JXGrabKey как аналог под Linux, просто её можно и не заметить. Так что уверен :)
  • 0
    Спасибо! А Native Swing можно использовать в Свинг приложениях? Ведь SWТ и Swing не смешиваются…
    • 0
      Да, можно. И SWT легко и просто и Native Swing.
      Проверил лично на очень большом проекте полностью реализованном на Swing — все стабильно работает.
      Только не думаю, что ради 1 кнопки стоит с собой SWT тащить (правда ради нормальных диалогов и некоторых фич вполне можно, как мне кажется).
      • 0
        Интересно. Не думал, что это так просто.
        Как же Event Dispatcher thread и всякие такие штуки?
        SWT же их учитывать не будет.

        Я когда то по ошибке смешивал AWT и Swing — все плохо было. Одни компоненты поверх других и вообще бардак
        • 0
          Ну, AWT это вообще другая история :)
          Он уже морально устарел и со Swing его использовать точно не стоит

          А про «Event Dispatcher thread и всякие такие штуки» — действительно смешивать интерфейсы лучше не стоит. Но когда речь идет об отдельных окнах с разным интерфейсом или же отдельных диалогах — все достаточно культурно.
          Насчет смешивания самих интерфейсных частей — я еще посмотрю потом, самому интересно что будет.
          • 0
            > Он уже морально устарел и со Swing его использовать точно не стоит
            Я бы даже поправил себя — его впринципе не стоит использовать ;)
    • +1
      Приходится и на оборот в swt встраивать swing. Для рисования графиков в swing есть teechart, jfreechart…, а вот для swt нет ничего.
      Есть еще WebKit for SWT open-life.org/blog/java/611.html
      • 0
        Насчет WebKit — спасибо за информацию — раньше не встречал никакой информации о нем.
        Вероятно потому, что пока-что с SWT вплотную много не работал.
        • 0
          Прочитал подробнее и посмотрел сайт проекта:
          «The WebKit for SWT project has been discontinued and downloads are no longer available»
          Увы, проект закрыт и найти даже устаревшую библиотеку где-либо я не смог.
          Возможно у Вас где-то сохранилась копия самой библиотеки?

          Хотя смысла о ней говорить вероятно нет, учитывая что проект закрыт (причем, вроде, достаточно давно) и обновлений не ожидается…
    • 0
      Кстати, Native Swing потому так и назван, что позволяет использовать интересные фичи SWT в обычных Swing-приложениях. Что-то до меня поздно дошла суть вопроса правда :)
  • +1
    На данный момент apng формат изображений полноценно умеет отображать только Firefox (3.6+) и некоторые отдельные приложения в виду своей специфики, впрочем изображения в данном формате могут быть весьма полезны в некоторых случаях.
    Опера 9.5+ вполне себе тоже понимает.
    • +1
      Не знал, действительно поддерживает :)
      Спасибо что подсказали — подправил в статье.
  • +1
    «JDIC
    Лицензия: LGPL 2.1
    Совместимость: Windows/Linux
    Кросс-платформенная: Да, но для каждой отдельной ОС и архитектуры необходимо использовать отдельный набор библиотек»

    недавно использовал данную библиотеку, реализации для 64-разрядной JVM, что и логично ввиду архаизма ее — нет, но жаль что она не поддерживается, удобна в использовании…

    З.Ы. Да, и еще, что бы найти «отдельный набор библиотек» нормальной сборки, потратил не менее получаса
    • 0
      > реализации для 64-разрядной JVM, что и логично ввиду архаизма ее — нет
      Думаю вполне возможно пересобрать ее под 64x из исходников

      > что бы найти «отдельный набор библиотек» нормальной сборки, потратил не менее получаса
      Думаете, есть смысл разместить дополнительно ссылки к разным версиям библиотек?
      • +1
        когда искал не было возможности исходники собирать, нужно было просто jar подсунуть в проект, поэтому думаю есть смысл, тем более что jar-файлов на странице проекта так и не нашел(ни одной версии).

        а уж для тех кто только «сел грызть гранит» Java и понятие Ant и т.п. не знакомо — собрать из исходников что-то будет проблематично :)

        да и к чему эта дисскуссия, все равно jdic не поддерживается
        • 0
          Насчет «собрать из исходников» я говорил конкретно про Ваш случай — если Вам она все еще необходима в 64-разрядном виде — это возможно.
          А насчет тех кто только обучается — согласен, добавлю чуть позже ссылки на доступные версии библиотек :)
    • 0
      Разместил ссылки на скачивание библиотек в статье.
      Извиняюсь, что вышло с задержкой.
  • +1
    Добавлю еще пару библиотек.

    Для сложных операций с имиджами можно использовать ImageJ (http://rsbweb.nih.gov/ij/) — функционал, близкий к GIMP, плюс ГУИ. Недостаток — использует старый PixelGrabber API, поэтому не отличается производительностью.

    Для ГУЯ можно использовать SwingWT — это обертка над SWT, которая предоставляет API от Swing-а (http://swingwt.sourceforge.net/) (соответственно скорость, быстрая загрузка, etc...). Поддерживается только подмножество Swing.

    Не упомянут еще QTJambi — java-фронтенд для QT (в настоящее время не поддерживается).

    Substance Look And Feel — симпатичный и настраиваемый L&F.
    Flamingo Suit — набор виджетов как в MS Office (оба эти проекта сейчас хостятся на GitHub).

    Не обойду стороной и новый JavaFX. В нем, учтены все прежние недостатки Swing, все упрощено, декларативный стиль, и интегрирован функционал SceneGraph (модель визуальных объектов, похожая на Flash). Позволяет быстро и безболезненно наклепать GUI. Можно встраивать существующие компоненты Swing. Обратное пока делается с геморроем. JFXtras — библиотека, расширяющая возможности JavaFX полезным функционалом и виджетами.

    Кстати, одним из способов проигрывать видео можно тоже назвать JavaFX.

    Под конец, многие java-девелоперы хотят, чтобы их продукт выглядел как нативная апликация и был независим от JVM. Помимо платного Excelsion JET можно порекоммендовать связку GCJ+SWT(SwingWT). Он хоть и уступает в производительности, но компенсирует за счет быстрого старта и нативного SWT.
    • 0
      ImageJ действительно упустил, но она уже достаточно старовата и, действительно, тормозная. Как-то давно пробовал ее как вариант для написания редактора изображений — в итоге отказался и сделал все по-своему.

      Насчет SwingWT, QTJambi, LaF, Flamingo и JavaFX — это все не совсем соответствует содержанию данного топика. Я сейчас как-раз делаю новый топик по UI в Java-приложении — там всё это и много больше будет включено и описано.

      JavaFX как вариант для проигрывания видео, все же, я исключаю, так как речь идет о J2SE (конкретнее даже — о Swing-интерфейсе) и использовать там JavaFX будет весьма накладно или даже невозможно.

      > Под конец, многие java-девелоперы хотят, чтобы их продукт выглядел как нативная апликация и был независим от JVM.
      > Помимо платного Excelsion JET можно порекоммендовать связку GCJ+SWT(SwingWT).
      > Он хоть и уступает в производительности, но компенсирует за счет быстрого старта и нативного SWT.
      Это впринципе абсолютно другая тема и как мне кажется, нет смысла прибегать к разным исхищрениям, чтобы использовать Java для разработки Windows only приложения. Врочем это отдельная тема для холивара, думаю не стоит его тут разводить.
  • +1
    Еще есть mozSwing — FF3 браузер держит win, linux, macos, solaris. Flash проигрывает и много чего умеет, есть доступ к XPCOM. Один минус проект старый и мертвый, есть еще мой jBrowser — на базе mozSwing (переработанное api), планирую Gecko 2 — html5 привет :)
    • 0
      Да, про mozSwing совсем забыл, хотя даже тут как-то видел Вашу статью о нем. Вы все еще занимаетесь им? :)

      P.S. Обидно, что есть достаточно много интересных и нужных проектов в этой области, но они очень быстро теряют обороты и схлопываются. А так как браузеры и прочая нативная кухня (да даже само JDK) постоянно меняется — без поддержки библиотека банально становится неработоспособной через год-другой.
      • 0
        Пока занимаюсь) Как ни странно мне пишут люди из других стран, а нашем соотечественникам он не очень нужен :) Хочу на xulrunner 2.0 переделать (FF4) не знаю хватит сил.
        • 0
          Чтож, буду надеяться, что у Вас хватит времени и сил :)
          А насчет потребности — думаю просто наши соотечественники не очень любят писать кому-либо лишний раз.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка