файл отрицательного размера

Зашёл в джиру, попробовал отправить комментарий к тикету, а там грабли:

Перегрузил страницу, попробовал отправить снова — та же ошибка. Ещё несколько раз попробовал, страница успешно перегружается, а комментарий запостить не дают.
Причём грабли эти подложили лично мне, у всех остальных нормально работает. Я вообще-то софт на жабе не люблю, там большинство разработчиков примерно как на похапе, но джира вроде более-менее приличная, и тут корпоративный сайт хостится на atlassian.net, у самих разработчиков-то должно работать..

Оригинал этой записи в личном блоге.

Ребёнок попросил поставить игрушку, увиденную у подруги. Игрушка нашлась быстро, оказалась она кроссплатформенная. Написана на джаве, работает под виндой, линуксом, MacOS, iOS, андроидом и даже FreeBSD.
Скачал с сайта производителя. Ну она, правда, под опенсорсным JRE не заработала, захотела родной оракловый. Поставил. Завелась, но только в демо-режиме. А чтоб в нормальном режиме поиграть, надо заплатить производителю денюжек. А меня это напрягает.

Покопавшись в интернетах, обнаружил офигенный рецепт. Оказалось, что рекомендованный производителем метод запуска java -jar игрушка.jar запускает не саму игрушку, а только launcher. А этот launcher, в свою очередь, запускает уже саму игрушку в виде ещё одного экземпляра джавы с явно указанным классом из другого jar’а, маршрутами к библиотекам, ресурсам, логам и прочими параметрами.

И вот когда она запустилась, с помощью ps ax можно посмотреть все эти параметры, записать их в файлик и использовать его вместо родного launcher’а.

А хитрость в том, что если из списка параметров убрать –demo, то игрушка внезапно начинает работать в нормальном режиме. Офигенная защита.. Похоже, Java влияет на моск почище, чем PHP.

Оригинал этой записи в личном блоге.
Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме.

Послало меня начальство учиться JBoss’у. Зачем — не знаю, моего мнения никто не спрашивал. Ну ничего не поделаешь, надо — так надо. Прослушали первую лекцию, приступили к лабораторной работе. Организаторы для всех учеников подняли виртуальные машины, положили туда все нужные файлы, написали подробную инструкцию. Всего-то надо распаковать этот самый JBoss из дистрибутива, скопировать дефолтную конфигурацию, подправить логин/пароль для доступа, запустить, зайти в admin console.

Казалось бы, ошибиться негде. Но… лично у меня конкретно эта admin console не запускается, ругаясь exception’ами на много экранов, общий смысл которых сводится к тому, что /usr/lib/jdk1.6.0_30/jre/lib/amd64/xawt/libmawt.so не может найти libXtst.so.6. Причём в целом JBoss работает, в JMX console даже можно зайти, а admin console никак не запускается. Лично у меня. У всех остальных всё работает. Виртуальные машины и дистрибутивы у всех совершенно одинаковые, под копирку сделаны. Клиентские машины у кого под виндой, у кого под линуксом.

Показал преподавателю. Он офигел. Зашёл на мою виртуальную машину, запустил тот же JBoss с той же конфигурацией, и… у него всё работает. Попробовал я ещё раз со своей машины… Опять не работает.

Впрочем, отгадку я нашёл довольно быстро. А вам слабо?

Оригинал этой записи в личном блоге.
Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме.

Вот только jboss’а мне не хватало для полного счастья :(

Оригинал этой записи. Комментировать можно тут или там.

Дорогие товарищи программисты на вот ей самой, а скажите, если мне захочется написать программу под J2ME, то что мне нужно будет, чтобы ее собрать?
И есть ли какие-нибудь тестовые среды исполнения и отладки, чтобы не сразу в телефон заливать?
И есть ли оно в пакетах под дебиан?
Вот, например, J2SE есть от Blackdown, а про J2ME непонятно.

Пытался поставить 9i на debian testing. Получил:
Error occurred during initialization of VM
Unable to load native library: /tmp/OraInstall2005-11-04_05-49-12PM/jre/lib/i386/libjava.so: symbol __libc_wait, version GLIBC_2.0 not defined in file libc.so.6 with link time reference

Погуглил.
Because it's an undocumented export of glibc 2.2 that should never have
been used by applications, and is no longer present in glibc 2.3. Sun
stupidly used it in JDK 1.4.0 (and perhaps earlier versions?), which
therefore doesn't work with glibc 2.3. This is fixed in JDK 1.4.1.

На машине установлен JDK 1.4.2, но я так понимаю, инсталлятор пользуется своей устаревшей версией.
Что делать?
Даунгрейдить libc не предлагать.

Может, можно как-то заставить инсталлятор использовать другую java-машину?