← All posts tagged Java

Допилил CheerpJ и JGNAT друг под друга

Посмотреть можно здесь

Пока что вижу: насчёт многозадачности — правда. Я думал, это фишка простого Cheerp, а раз в простом Cheerp нету асинхронизатора, то это всё может работать только на SharedArrayBuffer и не везде. Но нет. Планировщик находится в loader.js от CheerpJ и, насколько я могу судить, работает. В том числе можно динамически подгружать классы, и они грузятся (с поддержкой AOT) по сети, и исполнение зелёного потока продолжается с момента остановки. EmScripten так не умеет, там только синхронным XHR можно с файловой системой работать, и только в Web Workers, в общем, без асинхронизатора это ни о чём.

Вместе со Swing там, похоже, даже движок текста свой подгружается. Антиалиасинг явно получше, чем в браузере. Но время запуска будь здоров. Хотя большая часть сейчас зависит от производителя. Если они там у себя что-нибудь подкрутят, васм внедрят, например, ведь Cheerp умеет, то есть, куда ужаться. Просто начинать с тем, что есть, а оно само будет улучшаться.

А в javax.xml.datatype.XMLGregorianCalendar есть и getTimezone, и getTimeZone. Это не где-то в частной поделке такой бардак, это основной программный интерфейс.

Нет, нельзя давать программистам регистрозависимость. Если неприятность может случиться, она случится.

Bad class file: version 52.0 not supported
Да что ж вам неймётся-то по версиям скакать. Ну что не сидится на одной. Вот чем хорош COM и чем плоха Java, в COM совместимость десятилетиями держится, а тут каких-то несчастных четыре года отделяет, и уже инструментарий начинает отваливаться. В книге «Putting Metaclasses to Work» симуляция была специально реализована на Java, чтобы, как пишет автор, как можно надольше сохранить. В итоге компилятор DirectToSOM C++, библиотека SOM и прочее PE/COFF'ное запускается на современной Windows 10, а симуляция PMtW на современной JVM — нет. И на не очень современной 1.5 — тоже. Вообще надо какую-то древнюю находить, чтоб подошло тютелька в тютельку. Знал бы автор, как жестоко будут насмехаться над его потугами производители. Начиналось за здравие, столько надежд было.

И в Delphi CORBA IDL парсится утилитой не на Delphi, транслируемой в, как показывает практика, долгоживущий PE/COFF, а на Java, и тоже там совместимую версию надо постараться подобрать, собственно, почему эту фичу кроме особенно заинтересованных никто не смог увидеть в действии.

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

CheerpJ как я заметил, уже вышел из закрытых альфа-тестов и находится в бете.

Те же разработчики, что делают Cheerp, транслятор C++ в JavaScript/Asm.js/WASM, делают CheerpJ для Java. Позиционируется он как нормально портированная Java. Никаких ограничений, как в GWT. Поддерживается байт-код. Поддерживаются Swing и Java-апплеты как с оффлайн конвертацией, так и в виде шима. Есть плагин для Хрома.

Думал, в Swift будут утилиты на Swift, а оказалось, что нет (см. #2891656). Ладно, посмотрим, какие есть ещё варианты. У нас же мостов для Java есть целых три штуки. А как там парсинг сделан?

Первым в голову приходит Rococoa. И там парсинг не сделан никак. Согласно документации, надо писать привязки вручную.

Про Apple Cocoa-Java известно мало, потому что он с закрытым кодом, но оттуда можно взять ручные коррекции, написанные прямо в Apple. Похоже, полновесного парсера типа GCC там нет. clang в те времена не было.

Порадовал GNUStep JIGS. Там есть и парсер, и ручные коррекции.

Причина, по которой некоторые языки программирования вообще и Оберон в частности находятся в таком бедственном положении
В переводе про совместимость примечательна сноска
e Текущие реализации Java не поддерживают такое, но новые спецификации ясно требуют, чтобы все наши трансформации поддерживались.В оригинале доклада были ещё номера страниц в спецификации. То есть, как я вижу ситуацию, у индустрии была серьёзная проблема с обеспечением совместимости, и в спецификации Java английским по белому писали, что можно, а что нельзя допускать, и одновременно была целая эпопея со способами вызова из других языков:

* JDK 1.0 native method interface
* Netscape’s Java Runtime Interface
* Microsoft’s Raw Native Interface and Java/COM interface
* Java Native Interface
* Java Native Access

Одновременно несмотря на претензии типо-Java-вости и украденных идей со стороны некоторых адвокатов Оберона я что-то не припоминаю, чтоб было какое-то аналогичное соревнование, как лучше совместить код на Обероне с другими языками программирования. По ключевым словам «Oberon Runtime Interface» и «Oberon Native Interface» ничего не находится. А было ли что красть?

И вообще, это надо ещё сильно постараться поискать, чтобы узнать, как обстоят дела в конкретной реализации, если скомпилировать динамическую библиотеку классов и приложение, а потом к библиотеке применить описанные в докладе трансформации и перекомпилировать её, а приложение — нет. Покажи адвокату Оберона таблицу из доклада — сможет ли он там расставить крестики и галочки для знакомых ему реализаций?

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

Заколебался, но разгрузил X-Wiki от большинства запросов. Теперь, только если историю ковырять, запрашивать ревизию или делать ещё что-нибудь достаточно необычное, запрос пойдёт в J2EE, что можно заметить по времени ответа в 3-7 секунд.

Новый наскоро сделанный движок на Аде не всё ещё делает красиво. Хлебные крошки сделал лишь бы соблюсти приличия. Ссылки для поделиться кривые. Страницы 404 не сделаны. Ну и прочее по мелочи.

Заглянул в список «Кто в онлайне» и не увидел никого с сайта, хотя я интегрировал их. Решил посмотреть, а что там с сайтом. Ну конечно, он опять не открывается! Правильно, а зачем обслуживать посетителей, когда есть другие, более интересные дела, такие, как сборка мусора? javaw.exe ест весь CPU, а страница так и не открылась. Придётся всё же заняться переносом вики на Аду. Достало!

Тщетно пытаюсь починить запрос на своём сайте
По заголовкам — UTF-8, а на деле — Windows-1251. Вот сука! Хоть бы экранировала свой JSON. Никак не могу понять, где нужно что поменять, чтоб стало хорошо. Долго копался в исходниках, там обработки media=json вообще нет, и самой обработки запроса, того, что мне нужно, нет. Вот есть объекты, и вот они стали кривым JSON, где это недостающее звено посередине. Всё от чего–то наследуется, ищи–свищи, где там какой козёл забрёл в огород Windows-1251 на сайте, который насквозь UTF-8 должен быть по идее. Ну вроде нашёл какой–то левый org.restlet.service.*, который вообще из другого проекта подтянулся по зависимостям и не считается с настройками остального сайта. И вот даже нашёл страничку, из которой понятно стало, каким образом media=json срабатывает. Непонятно, что где поменять, чтоб JSON был на самом деле UTF-8. То ли в web.xml поменять (что?), то ли в движке сайта, где делаются настройки для Restlet, то ли в самом Restlet. Ну и лапша!

Директора по безопасности Oracle заколебали покупатели, проверяющие их код на наличие уязвимостей.
Ишь чё придумали, самовольно проверять безопасность. По лицензии можно только верить на слово. Это вам не гнатик, где всё открыто.

Удалось найти Mac OS X Server 1.0, в комплекте с которым на CD разработчика были WebObjects 4.0.1 и Yellow Box 1.0 для Windows (хотелось бы 5.1, но всё же это новее, чем OPENSTEP Enterprise for Windows), вот только без серийника нормально не поставить, можно только разпаковать. Кстати, похоже, это тот переломный момент, когда внутриэппловские фанбои Java настолько вдохновились, что переписали TextEdit с Objective-C на Java, благо у них мост между этими языками вплоть до Mac OS X 10.4 официально поддерживался. В OE/W ещё версия на Objective-C, а тут — на Java.
Против своей воли они всё-таки доказали, что производительность Java как была шлаком, так и остаётся, и пришлось, чтобы не позориться, TextEdit вернуть на рельсы Objective-C, и так оно и стало в современных Mac OS X.

Mежду SOM и Java такого же красочного сравнения не было, хотя одна из причин, по которым SOM перестали заниматься, это, как я предполагаю, ощущение, что Java решит все проблемы, которые раньше решали COM и SOM. Если бы не это ощущение, то Microsoft не удовлетворился бы ущербными COM, Java или .NET'ом, а слизнул бы SOM к себе в Windows в официальную поставку.

Ещё одна вещь, за которую Apple стоит сказать спасибо — это проваленный эксперимент со сборкой мусора в Objective-C. Видимо, фанбои сборки мусора в какой-то момент продавили своё решение, мол, ну пусть Java тормозная, но хоть Objective-C со сборкой мусора вдруг нормальным будет, ведь надо же иногда верить в чудеса. При этом трезво мыслящих людей в Apple хватило, чтобы не сделать это решение безповоротным.
Поступили довольно чисто: есть у исполняемых файлов пометка, нужен ли им сборщик мусора или хватит обычного счётчика ссылок, и если никому не нужен, то, как и раньше, действует счётчик ссылок.
Посмотрели, поигрались, и, судя по тому, что в очередной версии компилятора появился Automatic Reference Counting (аналог того, как Delphi обращается с COM интерфейсами), приняли единственно верное решение, послать эту сборку мусора и её фанбоев куда подальше. Нельзя не отметить мудрость инженеров в этом вопросе. Не всем дано признавать свои ошибки. Судя по тому, как поздно и как криво появился Windows Runtime (чем–то аналогичен SOM) и C++/CX (чем–то аналогичен DTS C++), у Microsoft длина тормозного пути на порядок больше (15 лет вместо 1.5).

А вот товарищи из Netlabs, которые проектировали NOM, видимо, не учли исторический опыт вклинить Java ну хоть на полшишечки, раз сделали сборку мусора изначально безальтернативной.

Можно ли в Gentoo, не прибегая к ручному шаманству, только через Portage, сделать так, чтобы .jar из Gnome автоматом запускались как положено? emerge virtual/jre оказалось недостаточно

Была хорошая переносимая Java. Write once, run everywhere. И на GCJ худо–бедно пашет, и на Jikes статически предкомпилируется. И на Mac OS X запустил — работает. А потом появилась шестая Java.

Вот и YaCy не избежал этой чумы.

Поставить #Kaffe или OpenJDK6 из MacPorts не удалось. Крайне ненадёжная это вещь — сорцовые репозитории.

GCJ в принципе не поддерживает J2SE 6.0. Не видать мне, похоже, шестой джавы на макосе как своих ушей.

Второй день одолевает проблема:

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 16 milliseconds ago. The last packet sent successfully to the server was 0 milliseconds ago.
Caused by:...
Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.

Хоть на стенку лезь, не знаю, что и делать.

Чёрт, мне нравится Resin ( caucho.com ). Сам отслеживает изменения файлов конфигурации, сам перезапускает себя по указанному интервалу после изменения конфига. Сам редеплоит сайт, если изменился web.xml.

Если сайт деплоить не либами и не классами, а исходниками на Java, сам собирает их и сам пересобирает их при изменении И даже HotSwap'ом меняет классы на лету, если ничего этому не мешает. Проекты в WAR'ах редко встретишь в виде исходных кодов, обычно отдельно WAR с классами, отдельно исходники (не пригодные для deploy), зато можно скачать исходники и избирательно подсовывать Resin только те исходные файлы, которые нужно подредактировать.

Практически все действия можно делать через ftp, что нехарактерно для J2EE контейнеров.