Итак, печальная история о том, что такое Java и как с ней бороться.

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

Если в приложении мы хотим загрузить такую картинку (может ещё и со встроенным цветовым профилем, я точной закономерности не устанавливал, но это и не так важно) например в BufferedImage и сделать что-нибудь полезное, то она должна быть преобразована в цветовое пространство RGB, что в общем-то делается автоматически. Но для того, чтобы это сделать в состав JRE входит файл PYCC.pf, содержащий стандартный цветовой профиль для такого преобразования. Файл этот, по идее, должен быть расположен в папке [JRE]\lib\cmm 

И вот тут-то и начинается самое интересное.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4668557
State      11-Closed, Will Not Fix,   bug 
Submit Date     15-APR-2002
This was taken out of JRE 1.2.2 to avoid size increase.
Inclusion of the PYCC.pf is causing 200K size increase
in compressed JRE

То есть "гениальные" авторы Sun JRE решили, что 200 Кб экономии стоят того, чтобы сломать полноценную поддержку JPEG. Решили они это ещё ой как давно и чинить не собираются. Ещё раз: в установке JRE по-умолчанию нет файла PYCC.pf, который необходим для работы стандартными средствами Java с нетривиальными JPEG-файлами.

Ладно, поматерились и подумали, надо всё-таки решать проблему.

Способ первый:
Берём PYCC.pf, кладём в ресурсы нашего приложения, и при первом запуске копируем его в [JRE]\lib\cmm. Всё работает покуда у нас Windows XP, а вот в Висте и 7-ке без админских прав писать в Program Files нельзя (а ведь JRE скорее всего именно там установлено). То есть способ совсем ненадёжный. Есть идея, правда, заставить инсталлятор (который работает с админскими правами) добавлять этот файл в JRE, но это мне тоже кажется ненадёжным -- вдруг следующей обновление Java установит jre в отдельную папку и тогда облом. Правда нынче это не так актуально, ведь начиная с 1.6.0_10 "гениальные" разработчики в Sun решили, что теперь всё по умолчанию идёт в ту же папку jre6, переписывая старые версии. В это есть несомненный плюс, но учитывая "гениальность" разработчиком найдутся и минусы.

Ладно, поматерились опять, поняли, что так просто подпихнуть файл нельзя, да и странно это как-то -- менять что-то в runtime evnironment.

Способ второй:
Читаем документацию, читаем исходники JRE и видим, что поиск цветовых профилей идёт по очереди в трёх разных папках, чьи пути берутся из properties: java.iccprofile.path, затем java.class.path, и наконец java.home + "\lib\cmm"
Отлично! Берём всё тот же PYCC.pf, кладём его в папку приложения или ещё куда и в java.iccprofile.path прописываем этот путь. Всё работает, действительно работает!..
Но вот выходит обновление 1.6.0_17. Обвноление версии в четвёртой цифре, это даже не Minor, это Revision по идее. Но "гениальные" авторы Java исправляя какой-то security flaw (вменяемого описания нет, только "6631533    java    classes_2d    ICC_Profile allows detecting if some files exist " из http://java.sun.com/javase/6/webnotes/6u17.html) сделали так, что теперь стандартные профили берутся только из java.home + "\lib\cmm", то есть повлиять на путь поиска больше нельзя. Непонятно, правда, почему именно так? И где же это написано, что обновление версии в четвёртой цифре может вот так ломать функциональность (мне пришлось опять исходники JRE изучать, чтобы понять в чём же проблема).

Спасибо Sun (или Oracle) за наше счастливое детство!

Наконец текущий workaround:
Раз поиск стандартных профилей происходит относительно java.home, а также поскольку загрузившись один раз этот самый профиль остаётся в статической переменной, то делаем безумную вещь -- сохраняем PYCC.pf в папку приложения + "\lib\cmm", при запуске приложения сохраняем старое значение java.home, заменяем его на путь к приложению, форсируем загрузку стандартного профиля, возвращаем оригинальный java.home. Как ни странно -- работает. Я не понимаю, почему можно менять java.home во время работы приложения, но видимо "гениальные" разработчики Sun считают, что это допустимо.

Извиняюсь за кучу букв и некоторую сумбурность описания, но вот так наболело :(

Можешь распространять приложение с собственной JRE.

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

JetBrains, Oracle, Eclipse и многим другим - не кажется 

О чём это говорит? Платформа Java настолько сыра, крива и нестабильна, что любое очередное обновление может поломать функциональность?   

Хотя я согласен, что некий смысл в этом есть -- пусть за обновлениями Java (а ведь они не только ломают, но иногда и улучшают что-то) следит не пользователь, а разработчик. И при выходе нового полезного обновления делает апдейт своего приложения, заключающийся в поставке нового JRE к ней. Это может быть оправдано, но вот что произойдёт, когда разработчик перестаёт поддерживать программу? Пользователь останется один на один либо с устаревшим JRE, либо с поломанной софтиной. И это совсем не гипотетическая ситуация, тут совсем недавно кто-то искал то ли 1.4, то ли ещё более раннюю версию Java 

Это сообщение отредактировал(а) Дрон - 17.3.2010, 21:04

Если JRE будет в составе вашего приложения (внутри папки), то такой проблемы не будет.


Видимо вы не так поняли. Эта внутренняя JRE будет только для вашего приложения, на систему она влиять никак не будет.

Добавлено через 1 минуту и 27 секунд
Тут проблема только в объединении. Те надо создавать установщик, продумывать методику обновления (мало-ли, захочется обновить JRE для приложения).

Я об этом и говорил. Если приложение ставит свою JRE, то оно остаётся без исправлений безопасности (хотя для обычного приложения они не очень важны) или возможных улучшений засчёт новых версий JRE (например 1.6.0_10 очень сильно улучшило графическое быстродействие). И получается, что разработчик должен за этим следить и делать апдейты своей программы только для того, чтобы обновить JRE, поставляемый с ним.

Кстати, инсталлятор моей софтины и так тащит с собой JRE и устанавливает её, если у пользователя более старая версия. Но устанавливает именно как общесистемную, а не частную. Забавное было бы решение: установить частную JRE (70 Мб) из-за того, что разработчики Sun решили сэкономить 200 Кб на одном файле 

Это сообщение отредактировал(а) Дрон - 18.3.2010, 17:45