not working with java 10+

[sanados]

Select compiler: failed

No JNI header generator detected.

javah was deprecated since long ago and was removed.

Replace javah with javac -h

[istathar]

@sanados hi there! I haven't done active maintenance on java-gnome for years, but as it happened I installed a new computer the other day and attempted to build & install one of my old programs. Without knowing better I tried Java 10 and yeah, it didn't work.

I spent a brief moment ripping out the javah stuff out of ./configure and replacing it with calls to javac -h but this didn't work as it generated stubs for files for which there was no implementation and the build broke.

I didn't have more time to investigate; installing Java 1.8.0 worked as a fallback but obviously that isn't sustainable long term.

[sanados]

I saw that there is no active maintenance, just wanted to document it here for others to see if they run into this.
Thanks for coming back and giving an update!

[dvogel]

FWIW I was able to build using openjdk-11 on debian. I happened to have javah on my PATH from an openjdk-8 install. This was an accident -- didn't realize I still had openjdk-8 installed.

$ readlink /usr/bin/javah /etc/alternatives/javah
/etc/alternatives/javah
/usr/lib/jvm/java-8-openjdk-amd64/bin/javah

$ dpkg-query -S /usr/lib/jvm/java-8-openjdk-amd64/bin/javah
openjdk-8-jdk-headless:amd64: /usr/lib/jvm/java-8-openjdk-amd64/bin/javah

Here's the .config:

# This is an automatically generated Makefile fragment which is used
# to configure java-gnome for building. Do not edit (your changes will
# be overwritten next time ./configure is run), do not commit to
# repository. Anyone packaging java-gnome on any operating system:
# please do not override this file by patching it! Figure out what the
# problem is, and let us know so we can improve the ./configure perl
# script which generates it.

OS=debian


# The lists of jars are colon separated, suitable for being
# concatenated into a CLASSPATH

JUNIT_JARS=/usr/share/java/junit.jar

# the JAVAC variable contains the path to the java source compiler,
# the JAVA variable contains the path to the java runtime virtual
# machine. In both cases, the _CMD variable is for the terse output
# when make commands are running.

JAVAC=/usr/lib/jvm/java-11-openjdk-amd64/bin/javac -g -source 1.6 -target 1.6
JAVAC_CMD=JAVAC    

# the JAVAH, JAR, and JAVADOC variables simply contains a usable jar
# and javah executable, respectively, while the JAVAH_CMD, JAR_CMD,
# and JAVADOC_CMD variables is for display purposes, matching the
# pattern above.

JAVAH=/usr/lib/jvm/java-8-openjdk-amd64/bin/javah -jni
JAVAH_CMD=JAVAH    
JAR=/usr/bin/fastjar 
JAR_CMD=JAR      
JAVADOC=/usr/lib/jvm/java-11-openjdk-amd64/bin/javadoc 
JAVADOC_CMD=JAVADOC  
JAVA=/usr/lib/jvm/java-11-openjdk-amd64/bin/java -client -ea -Djava.awt.headless=true
JAVA_CMD=JAVA     

# the path to the C compiler

CCACHE=/usr/bin/ccache
CC=/usr/bin/x86_64-linux-gnu-gcc-10  -g -Wall -fPIC -I/usr/lib/jvm/java-11-openjdk-amd64/include -I/usr/lib/jvm/java-11-openjdk-amd64/include/linux -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast  -Werror-implicit-function-declaration -Wfatal-errors
CC_CMD=GCC      
LINK=/usr/bin/x86_64-linux-gnu-gcc-10  -g -shared -Wall -fPIC
LINK_CMD=LINK     

# the install prefix. This *only* affects the location that installed
# files are sent to during the `make install` step. You can, as it
# happens, override it on the make command line the same way you
# specify DESTDIR, ie by doing `make PREFIX=/blah install`.

PREFIX=/home/dvogel/opt/java-gnome
LIBDIR=/home/dvogel/opt/java-gnome/lib
JARDIR=/home/dvogel/opt/java-gnome/share/java

# finally, we extract the version strings from the source code, for
# use in naming the target library files.

APIVERSION=4.1
VERSION=4.1.4-dev

[dvogel]

I've managed to make the project compile with openjdk-11 on debian in this branch: https://github.com/dvogel/java-gnome/tree/jdk-11. I don't use java a lot so I'm less familiar with the other build tools (e.g. ./configure compiler=ecj). As such, I suspect it will need quite a bit of additional work before I can push it upstream. Hopefully the WIP is helpful to anyone else who runs into this issue though.