JAVA+Swing в 2013. Стоит ли?

в 7:50, , рубрики: java, swing, интерфейсы, кроссплатформенная разработка, метки: , , ,

На Хабре Swing не любят. Поиск по «Swing» дает либо нейтральные, либо негативные упоминания. Вот некоторые из них:

  • «Java-апплеты (доразвивались до смертельной болезни под названием Swing)»
  • «Swing — мягко говоря не самый оптимальный UI фреймворк»
  • «Swing был ужасен»

Я не возьмусь утверждать, что Swing — идеал. Это неправда. Однако я постараюсь описать те плюсы и минусы с которыми пришлось столкнуться.

Почему Swing

Я работаю со Swing с перерывами пару лет. В основном, по вечерам. Пишу программу Visual Watermark для групповой защиты фотографий. Java версия у меня появилась в 2011. Мне захотелось сделать порт под Mac и вылизать интерфейс, но писать отдельную программу под каждую платформу у меня не было никакой возможности.

В начале 2011 UI-библиотеки для кросс-платформенной разработки были в таком состоянии:

  • QML был весь в багах: меню появлялись под компонентами, демка падала, поддержки в QtCreator не было. Ускоренная отрисовка появилась только в Qt5 прошлой осенью.
  • Qt не подошел, т.к. был целиком на “нативных” компонентах, а часто требовалось где-то изменить отрисовку.
  • Juce подходила по функционалу, не глючила и не падала. Стоила приемлемых денег да еще и с открытым кода. Отпугнул меня C++. Это замечательный язык на котором пишут огромное количество умнейших людей. Учитывая мой маленький опыт и размер задачи, сложность C++ – это перебор. Плюс, выяснилось, что Xcode не умеет рефакторить C++.
  • Adobe Air не поддерживает multi-threading.
  • Mono+GTK Мне кажется, что к эту комбинация могла бы решить мои проблемы. В тот момент отпугнул очевидный косяк с неработающими горячими клавишами в GTK. Судя по MonoDevelop, он не пофикшен до сих пор.
  • JavaFX не было под Mac.
  • SWT намного легче, чем Swing и в целом хорош. Не стал писать на SWT потому, что смотрел я его самым последним. Уже было потрачена уйма времени и я закончил эксперименты на первом попавшемся баге («плавали» кнопки по высоте на тулбаре).

На тот момент Java была частью Mac OS X, имела отличный Native Look & Feel, а JRE под Windows весила всего 12 мегабайт. Я был наивно уверен в успехе. В итоге, после 2 или 3х месяцев работы я оказался с первой версией программы на Java Swing.

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

Qt перешел под крыло фирмы Digia. Выпуск бета-версии под iPhone и Android дает надежду на дальнейшее развитие библиотеки.

JavaFX стала библиотекой с открытым кодом в феврале этого года. Её совместимость с OpenJDK планируется на JDK 9. Когда выйдет 9ка неизвестно. Релиз 8ой версии запланирован на начало 2014 года.

О хорошем

Начну с хорошего. Вдруг подумаете, что я тоже в Swing-хейтеры записался?!

Вся отрисовка hardware-accelerated. Любое Swing-приложение отрисовывается на GPU, от разработчика ничего не требуется. Это делает возможным анимации в приложении. В том числе, когда приложение полноэкранное или развернуто на 24’’ мониторе.

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

Java – это managed код. Вы избавляетесь от кучи возможных багов, «доступных» только для C++-разработчиков. Риск Access Violation сведен к минимуму. Хотя это совершенно не означает, что у вас не будет других багов. Утечек памяти, например.

Отличная среда разработки. Eclipse, Intellij IDEA, NetBeans – выбор огромный. Везде есть рефакторинги, форматирование кода, авто-комплит, поддержка unit-тестов,

Очень много библиотек. LayoutManager’ы, работа с нативными объектами, строками, вебом – всего не перечислить. Это огромный козырь Java как платформы.

Очень много ответов на вопросы. Вот, например, доля вопросов на StackOverflow по каждой из UI-библиотек.

JAVA+Swing в 2013. Стоит ли?

Примерно каждый сотый вопрос на StackOverflow – это вопрос о Swing. На практике, это означает, что большинство проблем уже решены. Скорее всего, один-на-один с проблемой вы не останетесь.

О плохом

Предыдущая часть похожа на сладкий пресс-релиз. Исправляюсь. Вот с чем вы можете столкнуться.

Не фиксятся критичные баги. File.exists не работает с момента релиза JDK7 и фикса нет до сих пор. Даже если баг критический, вы можете ждать фикса годами.

Ситуация может стать еще хуже, если вы планируете использовать нативный код. Я столкнулся с ситуацией, когда использование модальных окон (например, открытие OpenFileDialog) приводит к зависаниям на некоторых компьютерах. При том, что Java Native Foundation используется согласно примерам в документации. И баунти на StackOverflow мне не помог:-)

Баг с file.exists можно обойти с помощью классов из java.nio. Это новый API, который был призван решить проблемы производительности с развесистыми папками.

Что нужно сделать:

  1. Запустить приложение с параметром –Dfile.encoding=UTF-8
  2. Вместо File.exists используем Files.exists(Paths.get(fileName))
  3. Вместо File.listFiles используем 
    try (DirectoryStream<Path> ds = Files.newDirectoryStream(folder)) {
   for (Path file : ds) {
       // do something
   }
} catch (IOException e) {
   e.printStackTrace();
}

Или фиксить этот баг самостоятельно и проталкивать закладку через серию ревью.

Swing – только hardware accelerated. Это значит ваше приложение не будет работать в VMware, Parallels или через удаленный рабочий стол. Если вы не готовы с этим мириться, то смотрите в сторону SWT.

Нет 32-битных билдов под Mac. Официальная сборка только 64 бит. К сожалению, я не знаю в чем причина этого решения. Могу лишь гадать, что дело в каких-то багах.

Некоторое время Henri Gomez поддерживал 32-битные и universal билды. Готовые билды можно было скачать с его странички на code.google.com. К моему сожалению, нехватка времени и новая работа заставили Генри свернуть этот проект. Попрощавшись, он выложил свои билдежные скрипты на GitHub:
https://github.com/hgomez/obuildfactory

С их помощью можно собрать OpenJDK под Mac и Linux. Здорово, но не совсем. С помощью этих скриптов 32-битная версия под Mac не собирается. Внутри JDK огромное количество конфигурационных файлов, в которых зашита сборка строго 64-битной версии для Mac. Изменишь ключ в главном файле и получишь неработоспособную сборку. Каким образом Henri Gomez собирал 32-битные билды мне неизвестно.

Включайте JRE в дистрибутив. Мнение руководителей Oracle о дистрибуции приложений: “standalone self-contained инсталлятор с bundled JRE для целевой платформы – это более удачная модель распространения приложений” (источник). Наиболее вероятная причина этого решения – огромное кол-во уязвимостей в апплетах: Java приняла знамя решета у Flash.

Наиболее жестко поддерживает это ограничение фирма Apple, которая удалила Java в версии Mac OS 10.7 Lion. Также они принудительно отключают ее при установке новых системных обновлений.

JRE 7 весит около 100 Мб. В архиве получается около 50. К сожалению, размер JRE от апдейта к апдейту растет и нам проблему распухшего дистрибутива придется решать.

Не все объекты BufferedImage используют аппаратное ускорение. Только для BufferedImage.TYPE_INT_*. Поэтому, начиная с JDK7, работать с TYPE_4BYTE*, TYPE_3BYTE нецелосообразно.

При доступе к данным растра BufferedImage, картинка перестает рисоваться через GPU. Зачем это сделано понятно: пользователь меняет данные, метода “закончил менять” нет и не понятно когда их пере-заливать в видео-память. По крайней мере, это логично.

В Visual Watermark я использовал C++ библиотеку для загрузки изображений и нужно было полученные пикселы превратить в объект BufferedImage. Менять по-одному пикселу очень медленно и пришлось писать напрямую в буфер растра картинки. Как только я вызвал у растра getData(), все мои картинки перестали ускоряться. Покопавшись в коде DataBufferInt, я нашел решение этой проблемы с помощью reflection и написал небольшой класс-помощник:

import java.awt.*;
import java.awt.image.*;
import java.lang.reflect.Field;

import sun.awt.image.SunWritableRaster;
import sun.java2d.StateTrackableDelegate;

// Standard library prevents image acceleration once getData() method is called
// This class provides a workaround to modify data quickly and still get hw-accel graphics
public class AcceleratedImage {
	// Returns data object not preventing hardware image acceleration
	public static int[] getDataBuffer(DataBufferInt dataBuffer) {
		try {
			Field field = DataBufferInt.class.getDeclaredField("data");		
	        field.setAccessible(true);
	        int[] data = (int[])field.get(dataBuffer);
	        return data;
		} catch (Exception e) {
			return null;
		}
	}
	
	// Marks the buffer dirty. You should call this method after changing the data buffer
	public static void markDirty(DataBufferInt dataBuffer) {
		try {
			Field field = DataBuffer.class.getDeclaredField("theTrackable");		
	        field.setAccessible(true);
	        StateTrackableDelegate theTrackable = (StateTrackableDelegate)field.get(dataBuffer);
	        theTrackable.markDirty();
		} catch (Exception e) {
		}
	}
	
	// Checks whether current image is in acceleratable state
	public static boolean isAcceleratableImage(BufferedImage img) {
		try {
			Field field = DataBuffer.class.getDeclaredField("theTrackable");
	        field.setAccessible(true);
	        StateTrackableDelegate trackable = (StateTrackableDelegate)field.get(img.getRaster().getDataBuffer());
	        if (trackable.getState() == sun.java2d.StateTrackable.State.UNTRACKABLE)
	        	return false;
	        field = SunWritableRaster.class.getDeclaredField("theTrackable");
	        field.setAccessible(true);
	        trackable = (StateTrackableDelegate)field.get(img.getRaster());
	        return trackable.getState() != sun.java2d.StateTrackable.State.UNTRACKABLE;
		} catch(Exception e) {
			return false;
		}
	}
		
	public static BufferedImage convertToAcceleratedImage(Graphics _g, BufferedImage img) {
		if(!(_g instanceof Graphics2D))
			return img;	// We cannot obtain required information from Graphics object
		Graphics2D g = (Graphics2D)_g;
		GraphicsConfiguration gc = g.getDeviceConfiguration();
		if (img.getColorModel().equals(gc.getColorModel()) && isAcceleratableImage(img))
			return img;
		BufferedImage tmp = gc.createCompatibleImage(img.getWidth(), img.getHeight(), img.getTransparency());
		Graphics2D tmpGraphics = tmp.createGraphics();
		tmpGraphics.drawImage(img, 0, 0, null);
		tmpGraphics.dispose();
		img.flush();
		return tmp;
	}
}

Использовать его нужно вот так:

DataBufferInt dataBuffer = (DataBufferInt)bufferedImage.getRaster().getDataBuffer();
int[] data = AcceleratedImage.getDataBuffer(dataBuffer);
// Меняем данные
AcceleratedImage.markDirty(dataBuffer);

Я не проверял этот код для изображений, которые уже были выведены на экран.

Нет встроенной анимации и полу-прозрачности. Объект javax.swing.Timer делает две вещи:

  1. Можно сделать анимацию компоентов.
  2. Из-за простоты класса, делать ее очень долго.

Есть библиотека Timing Framework, которая позволяет создавать анимации проще. Анимацию можно сделать вот так:

Animator viewAnimator = new Animator.Builder()
		.setDuration(duration, TimeUnit.MILLISECONDS)   //  Устанавливаем длительность анимации
		.setStartDirection(Direction.FORWARD)
		.setInterpolator(new AccelerationInterpolator(0.3, 0.7))    //  Заставляем двигаться с ускорением
		.setRepeatCount(1).addTarget(new TimingTargetAdapter() {
			@Override
			public void timingEvent(Animator source, double fraction) {
				// Меняем состояние
				repaint();
			}
			@Override
			public void end(Animator source) {
				// Делаем что-то по окончанию анимации
			}
		}).build();
viewAnimator.start();

Чаще всего используется анимация положения и полу-прозрачности. Если с контролем положения в Swing все OK, то полу-прозрачность стандартные компоненты не поддерживают. Проблема не в возможностях графического движка, а в том, что компоненты не имеют свойства getAlpha/setAlpha.

Java-приложение не будет запускаться в Mountain Lion из-за GateKeeper. Чтобы решить эту проблему вам нужно подписаться на программу Mac Developer за $99/год. В замен фирма Apple выдаст вам сертифакт для подписи кода и проблема уйдет.
Подписать бандл с приложением можно вот так:
codesign –s “Developer ID” –f “path-to-my-app.app”

В сумме

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

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

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

Автор: ivann

Источник

* - обязательные к заполнению поля

Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js