dcevm port for jdk8u40

I decided to instrument my JDK build with DCEVM hotswap patch for JDK hotspot. But I found that where was no a patch version for the recent Early Access (according to the mercurial history it should not be changed significantly before the release). I thought that the patch could be applied pretty easy but sources of jdk8u20 and jdk8u40 were dramatically changed. By this reason I spent some time porting the sources to the new hotspot implementation and now you can try it out. Just apply the patches in the next order to the hotspot workspace and build it  
  1. light-jdk8u40-b19.patch
  2. light-jdk8u20-deopt-cp.patch
  3. dmh-field-accessors-java8u40.patch
  4. gc-java8u40.patch
  5. arguments-java8u40.patch
  6. distro-name.patch
  Patches as a zip archive

32bit java на 64bit OS

Я опять забыл про использование 32-битного дистрибьютива Java на 64-битной системе. Если в такой конфигурации у вас не хватает динамически загруженных библиотек, скорее всего, в вашей системе их просто нет. Вам нужно установить дополнительные 32 битные пакеты. Чтобы посмотреть какие библиотеки загружены, я пользуюсь следующей комбинацией комманд.
> jps
> lsof -p | awk ‘{print $9}’ | grep ‘.*so’ | less

В моём конкретном случае, я сравнил библиотеки загруженные 32-битной Java и 64-битной при запуске IDE Idea.

Подборка документанции по Remote Desktop Connection

Freetype для сборки jdk на MacOSX

Сегодня узнал, что на маке есть возможность узнать место библиотек и заголовочных файлов freetype. К сожалению, об этом нет ни слова в README-build для OpenJDK. host:jdk7u denis$ freetype-config –cflags -I/opt/local/include/freetype2 -I/opt/local/include host:jdk7u denis$ freetype-config –libs -L/opt/local/lib -lfreetype -lz -lbz2 Таким образом, для сборки OpenJDK можно указать ALT_FREETYPE_LIB_PATH=/opt/local/lib ALT_FREETYPE_HEADERS_PATH=/opt/local/include ALT_BOOTDIR=`/usr/libexec/java_home -v 1.6` make

Closable и AutoClosable в Java

Начиная с jdk5 в Java появился интерфейс Closable. Основная идея интерфейса предоставлять единообразный способ закрывать уже ненужные ресурсы. При этом в jdk7 появилась возможность лаконично объявлять и инициализировать ресурсы, не думая о том, когда и где ресурс нужно будет закрыть.

static String readFirstLineFromFile(String path) throws IOException {
    try (BufferedReader br =
                   new BufferedReader(new FileReader(path))) {
        return br.readLine();
    }
}

Код выше взят из официального урока по языку Java. Таким образом, появилась приятная возможность ограничить зону видимости (scope) и жизненный цикл таких ресурсов, как файлы и потоки ввода вывода. Более того, вызов метода close() такого интерфейса идемпотентный, то есть не произойдёт ничего страшного, если вы вызовите метод несколько раз. Зачем и когда это может произойти? Если вы используете поток ввода-вывода, помещаете (wrap) его в другой поток или Reader/Writer, то согласно документации, при закрытии объекта-обёртки закрывается и ресурс, который в него завёрнут. Если же вы создали поток или другой ресурс выше по стеку, то не можете быть уверены, будет ли он явно или неявно закрыт. Вот здесь и полезна возможность вызывать метод close() несколько раз. Если к моменту возвращения к мест создания ресурса, вы явно или неявно уже его закрыли, то повторный вызов метода просто не будет иметь эффекта. Зачем же нужен интерфейс AutoClosable? На самом деле, любой Closable, начиная с jdk7 является AutoClosable. Но с AutoClosable снято одно ограничение. Метод close() может бросать любое исключение, а не только IOException. С другой стороны, в отличие от Closable, вызывать close() на AutoClosable можно только единожды.

Проблема 32-битной отладки

Уже несколько раз забывал причину появления неочевидной ошибки при запуске отладки из только что созданного проекта в Visual Studio. --------------------------- Microsoft Visual Studio --------------------------- Unable to start program . The 32-bit version of the Visual Studio Remote Debugging Monitor (MSVSMON.EXE) cannot be used to debug 64-bit processes or 64-bit dumps. Please use the 64-bit version instead. В моём случае, проблема в отсутствии расширения запускаемого файла. В Project -> Properties -> Debugging -> Command я регулярно забываю добавить расширение exe.

Незавершённые Unit тесты в XCode на Mac OS X

Некоторое время назад я начал писать тесты для в XCode. Сразу же столкнулся с проблемой – IDE пишет, что тесты не завершены. К сожалению, единственное решение, которое я нашёл – добавлять задержку в метод tearDown - (void)tearDown { // Tear-down code here. [NSThread sleepForTimeInterval:1.0]; [super tearDown]; }

Вывод отладочной информации в Open JDK

Для включения вывода отладочной информации, логгинга (logging), достаточно указать конфигурационный файл с соответствующими настройками. Нет необходимости помнить, как должен выглядеть этот файл. Любой дистрибьютив JDK содержит такой файл. Достаточно его адоптировать для ваших нужд. jre/lib/logging.properties Чтобы включть соответствующий логгер, нужно указать уровень важности выводимой информации. sun.awt.X11.focus.XWindow.level = FINER Приведённый выше фрагмент добавленный в конец файла позволит отслеживать события связанные с состянием фокуса на топлевеле в XToolkit (Linux и Solaris). Найти соответствующий логгер можно в пространстве Open JDK. Один из вариантов знакомства с пространством – воспользоваться web-интерфейсом системы контроля версий Mercurial. Слепок файла XWindow.java на момент написания блога, находится здесь.
      51     private static final PlatformLogger focusLog = PlatformLogger.getLogger("sun.awt.X11.focus.XWindow");
В строке 51 видно, название логгера. При добавлении логгера в файл, нужно помнить, что в файле конфигурации указывается уровень выводимых сообщений, поэтому нужно не забыть добавить .logger к названию логгера, как это сделано выше. В конечном итоге, достаточно просто запустить команду java с соответствующей опцией. java -Djava.util.logging.config.file=logging.properties YourApplicationClass

Сборка Open JDK

С недавнего времени сборка пространства Open JDK значительно упростилась. Весь процесс теперь описан в одном документе – документация по сборке JDK Вкратце процесс сводится к
  1. Клонированию пространства из репозиторя hg fclone http://hg.openjdk.java.net/jdk8/jdk8
  2. Переходу в корень пространства cd jdk8
  3. Выполнению скрипта bash ./configure
  4. И выполнению сборки командой make
Если вам нужна гибкость в процессе настройки, для этого предусмотрены специальные флаги bash ./configure --enable-debug позволит собрать отладочный билд, с отладочной информацией и assertions времени выполнения. bash ./configure --with-freetype=/cygdrive/c/freetype-i586 --with-target-bits=32

Programming Blog