Использование jrawio в моем собственном проекте вызывает ошибку - PullRequest
1 голос
/ 22 января 2020

Я использую это: https://github.com/tidalwave-it/jrawio-src Это поставщик ввода-вывода изображения для файлов Camera Raw

Я запустил проект maven, взял необходимые сгенерированные файлы и поместите их в качестве ссылочных библиотек в мой собственный проект, который преобразует изображения. Когда я запускаю преобразование формата .NEF в JPEG, происходит ошибка ниже.

   Jan 22, 2020 1:54:16 PM it.tidalwave.imageio.util.Logger info
    INFO: Installing RAWProcessor...
    Jan 22, 2020 1:54:16 PM it.tidalwave.imageio.util.Logger info
    INFO: Installed RAWProcessor
    RAWProcessor succesfully installed
    Exception in thread "AWT-EventQueue-1" java.lang.NoSuchMethodError: java.nio.ShortBuffer.position(I)Ljava/nio/ShortBuffer;
        at it.tidalwave.imageio.nef.NEFCompressionData.<init>(NEFCompressionData.java:79)

, а 79 - строка, вызывающая ошибку:

73        shortBuffer = byteBuffer.asShortBuffer();
79        shortBuffer.position(1);

При моем исследовании упоминается буфер методы (, такие как shortBuffer.position (1); ), используемые в SPI jrawio, претерпели изменения с Java8 на Java9 и поэтому не будут распознаваться - но я не использовать Java9. Я использовал Java8 как для редактирования, так и для запуска проекта jrawio maven и моего собственного проекта.

Я также пытался использовать и компилировать старые Javas-файлы, но это нарушало мой собственный проект. Я изменял настройки в generate-sources. xml и pom. xml перед запуском проекта jrawio для генерации jar-файлов, но не повезло.

Запуск проекта jrawio также дает:

warning [options] bootstrap class path not set in conjunction with -source 8

Что я могу сделать, чтобы исправить все это и успешно внедрить этот поставщик SPI Image I / O для Camera Raw в мой собственный проект, отредактированный и скомпилированный Java8?

1 Ответ

0 голосов
/ 22 января 2020

Как вы заметили, классы Buffer были изменены в java9 для добавления ковариантных переопределений нескольких методов. Ранее метод

public Buffer position(int newPosition)

существовал только в базовом классе Buffer, и поскольку он также возвращал Buffer, его было не так удобно использовать в сочетании с цепочкой методов. В java9 перегруженные методы были добавлены во все подклассы для возврата конкретного подтипа , например

public ShortBuffer position(int newPosition)

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

Проблема возникает, когда код компилируется с файлами классов из jdk9 и выполняется на более старом jdk. В этом случае байт-код содержит ссылку на новую перегрузку, которая не может быть разрешена на более старом jdk.

Это также является причиной предупреждения, которое вы видели:

warning [options] bootstrap class path not set in conjunction with -source 8

Опции source и target влияют только на принятый исходный код и сгенерированный байт-код, но при компиляции все равно будут использоваться библиотеки классов текущего jdk. Одним из решений этого было бы установить путь к загрузочному классу так, чтобы он указывал на более старую версию jre.

Лучшее решение, которое было включено в jdk9, , заключается в использовании параметра release вместо, Это заставляет компилятор использовать некую внутреннюю базу данных, которая содержит информацию о том, когда какие методы были добавлены в jdk, и генерирует байт-код, совместимый с версией выпуска. С maven этот параметр можно установить с помощью свойства maven.compiler.release внутри блока properties в pom.xml.

<properties>
    <maven.compiler.release>8</maven.compiler.release>
    ...

С муравьем, который является для запуска generate-sources.xml параметр release можно передать в задачу javac

(обратите внимание, что я на самом деле не проверял это с источниками jrawio)

...