KilianB / JImageHash

Perceptual image hashing library used to match similar images
MIT License
397 stars 80 forks source link

Difficulty Building on Linux #30

Open jbrain opened 5 years ago

jbrain commented 5 years ago

Unable to build under current openjdk + javafx (openjfx), producing

[ERROR] /home/me/development/JImageHash/src/main/java/com/github/kilianB/hash/Hash.java:[18,26] cannot access javafx.scene.paint.Color
[ERROR]   bad class file: /home/me/.m2/repository/org/openjfx/javafx-graphics/12-ea+8/javafx-graphics-12-ea+8-linux.jar(javafx/scene/paint/Color.class)
[ERROR]     class file has wrong version 55.0, should be 52.0
[ERROR]     Please remove or make sure it appears in the correct subdirectory of the classpath.

Fedora 28 openjdk version "1.8.0_191" OpenJDK Runtime Environment (build 1.8.0_191-b13) OpenJDK 64-Bit Server VM (build 25.191-b13, mixed mode)

Windows build was successful after getting the Oracle Java JDK and Maven to play nice with each other, but only from within Eclipse for some reason (likely local default maven config missing some things).

KilianB commented 5 years ago

Maybe your eclipse configuration is set up to include the javafx sdk. This is probably the reason why I did not catch the issue on my machine either. Once I get home I’ll release a version with updated dependency. Thank you for pointing this out

jbrain commented 5 years ago

This is more than likely caused by a combination of openjfx and differences in versions of Maven between the two machines, and not something that should be addressed here I just wanted to give you as heads up since building on a recent linux blend would not be uncommon. Fedora ships with Maven 3.5.2

I believe the problem I had building in Win10 was simply due to Netbeans using it's bundled version (3.0.5) of Maven with it's plugin (as it should by default) and me not selecting the 3.6.0 installed version. Once set everything built without error in Win10.

KilianB commented 5 years ago

Since this is not time critical, let me think about it a little bit mote and address this issue at a later time. There has to be a way to solve this in a reasonable manner, even if different maven versions are involved. The library is almost self sufficient and all dependencies related to JavaFX are under my control with no requirement for any advanced version.

Without doing any testing or in depth research:

Maybe explicitly defining a version range of FX in both the actual library and the utility code is all that is needed. Currently we use the transitive dependency of the utility code which apparently breaks the code. Maybe pushing this fork is all that is needed https://github.com/pontusvision/pontus-JImageHashUtilityCode/commit/d1f888474d19b4c6a5ca4a5bd0a18e390943c36a

The specified error is linked to the compiler version as specified by maven. In this instance Java 1.8 is required.

<properties>
    <maven.compiler.target>1.8</maven.compiler.target>
    <maven.compiler.source>1.8</maven.compiler.source>
</properties>

Or with newer versions of maven

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

Or the maven version itself was linked to an older JVM instance. I'll set up a fedora build myself and see if I can reproduce the issues.

Adithya-copart commented 4 years ago

I ran into the same issue using a docker container built using jruby:9.2.8.0-jdk (source).

Maybe pushing this fork is all that is needed pontusvision/pontus-JImageHashUtilityCode@d1f8884

I see that javafx-graphics is resolved to 12-ea+8 and maybe this is all we need.

KilianB commented 4 years ago

I am not happy about the overall dependencies of this project and javafx has caused more issue than it has done good in the past. Maybe it's time to rethink the imports and modularize the project.

InstantMuffin commented 4 years ago

I just ran into the same issue. Ubuntu 19.10.

teplyuska commented 4 years ago

I am not happy about the overall dependencies of this project and javafx has caused more issue than it has done good in the past. Maybe it's time to rethink the imports and modularize the project.

It would be awesome with a separate library with only the algorithms and some matcher utils.