Java программа не видит переменных окружения с точкой в имени

 Столкнулся с интересной проблемой когда внедрял сборку контейнеров под ARM64 процессоры. Есть программа на Java контейнер которой использовал образ "eclipse-temurin:17-jre-alpine" в качестве базового. Для этого базового образа отсутствует вариант для платформы linux/arm64 и стоял вопрос что безопаснее сделать:

• перейти на "eclipse-temurin:17-jre-noble" который использует Ubuntu вместо Alpine
• перейти на "eclipse-temurin:21-jre-alpine" который влечёт обновление Java с 17 на 21

Разработчик выбрал первый вариант (перейти на "eclipse-temurin:17-jre-noble"), т.к. обновление версии Java выглядит рискованным (может повлечь неожиданные эффекты в какой-либо из библиотек) и требует полного цикла тестирования которое провести сейчас нет возможности.

Я также считал что замена Alpine на Ubuntu при сохранении версии Java является менее рискованным, хотя и повлечёт увеличение размера образа контейнера и возможные риски из-за замены musl на libc (хотя я не особо верю в вероятность таких неприятностей). Забегая вперёд, мы потратили несколько часов разбираясь почему программа перестала запускаться.

Реверс инжениринг программы Test Controller

Эта статья появилась из комментария к моему обзору Test Controller на Хабре:

VC8145 не заработал, пишет что таймаут. В конфигурационном файле для него в общем-то и менять нечего. Но, насколько я понял из конфигурационного файла, он если и заработает, то умеет читать только число с основного дисплея (это я и сам умею:)). Поскольку официальной документации протокола я не нашел, мне было бы интересно посмотреть, как читаются данные с дополнительного дисплея, но увы...

Мне стало любопытно как Test Controller работает с мультиметром VC8145. Конфигурация для VC8145 действительно "скромная":

#idString Vici,VC8145
#name Vici VC8145
#handle VC8145
#driver VC8145
#port comfixedbaud
#baudrate 9600N81Rd
#help VC8145

#interfaceType DMM
#interface readValue 0

Есть только метаданные и указание драйвера VC8145, который реализован в TestController.jar. Однако узнать как он реализован несложно - Test Controller написана на Java и если автор программы не ставил цель скрыть исходный код, то достаточно загрузить этот файл в любой декомпилятор Java. Например в Java Decompiler.

Решил проблему с медленным запуском jenkins slave на Raspberry PI 3

Продолжение истории с jenkins, предыдущие посты тут и тут.

Пакеты openfire 4.0.2 для Debian не работают с java 7

Попробовал обновить openfire с 4.0.1 до 4.0.2 в Debian Wheezy. Обновление проходит без проблем, но клиенты не могут подключиться к серверу.

В логе openfire следующее:

2016.04.01 14:35:18 org.jivesoftware.openfire.nio.ConnectionHandler - Closing connection due to exception in session: (0x00000002: nio socket, server, /x.x.x.x:50558 => /y.y.y.y:5222)
java.lang.NoSuchMethodError: java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
at org.jivesoftware.openfire.roster.Roster.broadcastPresence(Roster.java:628)

[пропущен кусок лога]

at java.lang.Thread.run(Thread.java:745)

В багтрекере openfire есть несколько записей на эту тему (OF-965, OF-1115, OF-1116). Причина в том, что openfire 4.0.2 скомпилирован с использованием java 8.x, а в Wheezy доступна только java 7.x. Тут более детально описан источник несовместимости.

Я могу понять позицию разработчиков openfire на счет EOL java 7, но в этом случае нужно изменить зависимости пакета и обновить документацию - тогда никаких вопросов не будет. А пока же заявлена поддержка java 7, но работать будет только с java 8.

UPDATE: Собрал openjdk-8 под Debian Wheezy. Установил на тестовый сервер и попробовал удалить старый openjdk-7 - фиг вам. Оказывается он еще и в зависимостях пакета прибит гвоздями:

$ apt-cache show openfire | grep Depends
Pre-Depends: openjdk-7-jre-headless | openjdk-7-jre | oracle-java7-jre

Перепаковывать лениво - остановил openfire и прописал в /etc/default/openfire нужный JAVA_HOME. После этого все заработало.