Current requirements are: - Java 1.8 (Level 8.0) - Android SDK API level 24 (Version 7.0 Nougat, released August 2016)
Official production builds are performed w/ Java 1.8. - Java 1.8 (Level 8.0) - Android SDK API level 24 (Version 7.0 Nougat, released August 2016)
Android 7 API level 24 supports Java 1.8, see https://developer.android.com/studio/write/java8-support
Java 8 is chosen today, June 2019, since OpenJDK 1.8 is well supported on desktop, mobile support is given w/ OpenJDK 9 and Android also support these language features for almost 3 years.
++++
Current patch does require one to set the target.sourcelevel, target.targetlevel and target.rt.jar properties or their equivalent capital case environment variables.
Update cpptask.jar to commit 757192655df20cc6a68affe8cbb4d7de387c9c67
Added CC Task Option: 'usehighleveltool' to give user option to prefer the high-level tool like gcc or clang for static linkage where usually 'ar' is being used.
Fixed CStruct annotation processor to not use dummy Java variable types
When annotations were placed on dummy Java variables, the annotation processor was emitting a RenameJavaType directive into the gluegen config file that caused the emitted file to be named boolean.java instead of RenderingConfig.java or Pixel.java. Turned off this behavior when jname is given in the @CStruct annotation. I'm uncertain how much this processor is even used, since I can't find any occurrences of @CStruct outside the test code for it in gluegen.
Fixed java.home directory and removed obsolete tools.jar
In Java 9+, there's no longer a "jre" directory in the installation, so removed references to it. The tools.jar file also no longer exists in Java installations (it's now stored in a secret non-JAR format), so removed that as well.
Bug 1363: Java 11: Refine 'java.home.dir' and 'java.lib.dir.platform' setup for traditional layout and JEP 220(Java 9+)
JEP 220 states it is now optional to use the <arch> subfolder in 'lib' to store native libraries, i.e. 'lib/<arch>/libjava.so' can be flattened to 'lib/libjava.so'. Further the jre subfolder is no more used according to the JEP 220, however, it can be used.
Therefor we scan for 'java.home.dir' in the following order: - if '<java.home>/../jre' exists, i.e. we are within the 'jre' folder, use '<java.home>/..'. - otherwise assume <java.home> reflect the flattened actual base folder and use it as is.
We scan for 'java.lib.dir.platform' in the following order: - if exists <java.home>/jre/lib/i386/libjava.so -> <java.home>/jre/lib/i386 - if exists <java.home>/lib/i386/libjava.so -> <java.home>/lib/i386 - defaults to flattened <java.home>/lib
This way we keep the historical arch information for each platform and stay most flexible for any SDK build layout.
Bug 1363: Java 11: Fix javadoc invocation, drop -source <release> for compile time javac
Also prepare the 'target.releaselevel' property to be set by 'RELEASE_LEVEL' environment, however - we do not use it at this point.
For now, we build gluegen-rt using '-source 1.8' '-target 1.8' and the bootclasspath of openjdk8 rt.jar to ensure java8 compatibility.
Alternatively one could use '--release 8' instead using the java11 distributed modules. However, I think the above method is more safe, only allowing java8 rt.jar to be used for compilation.
Further, gluegen.jar is build using '-target 1.8' only, since it musty use java11 sources at least for the javadoc taglet.
As of Java9, sun.misc.Cleaner has moved to jdk.internal.ref.Cleaner. However, access has been made (under the table) via sun.misc.Unsafe, which we are using for now as we cannot set the jdk.internal.ref.Cleaner method accessible.
In this regard, we had to change our Cleaner.clean(..) method using a ByteBuffer instead of a Buffer object paramter.
All tests have passed, no more illegal access case running on Java11 has been exposed.
Windows Regression: Mingw64 8.1.0 using statical linked tool lib Test1p1Test1p1JavaEmitter
'com.jogamp.gluegen.test.junit.generation.Test1p1JavaEmitter' exposes a regression using MingW64 8.1.0: System.loadLibrary() gives a "Can't find dependent libraries".
Here, 'Bindingtest1p1' is linked against 'test1' and fails to load due to its wrong dependent library name within 'Bindingtest1p1'. MingW64 8.1.0 dropped 'libtest1.so' into 'Bindingtest1p1.dll', which is surely wrong. Even passing '-Wl,-soname=test1.dll' didn't help.
Note: Such constellation would only work with adding the lib-path to PATH on Windows.
Since we don't utilize the method in any of our projects, but use the dynamic library lookup method - this is not a blocker, but wasted some good time.
Document Java8 target constraints, i.e. where we need to set source, target and bootclasspath to ensure target runtime Java8 compliance.
Fix one odd compile issue! Using two theorethical identical GNU/Linux Debian 10 machines with same set of installed software, one passes (like MacOS, Windows) and one fails. The failure was due to the CStructAnnotationProcessor's @SupportedSourceVersion tag. This downgrades the SourceVersion's previous bump from 6->11 (commit 610493b1724b5d91327f478338ff5d029bdcc032) down to 8.
Bug 1363: Java 11: Revert CStructAnnotationProcessor's @SupportedSourceVersion back to 11
Behold, the issue as documented at commit 2d89df89453c099d4e357aa17eae88efcf1d1b70, one build machine failing to compile SourceVersion.RELEASE_11 was due to an incomplete installation of openjdk-11-jdk on Debian GNU/Linux. Wow.
I have re-installed the openjdk-11-jre and openjdk-11-jdk packages on said machine, ensured they are being used .. and it works.
Another note here regarding usage of OpenJDK11 compile time environment and Java8 target. If using Eclipse, I had to set the system runtime JDK to JDK 8. Otherwise the 'editor clean-up' jobs would run against the JDK 11 classes and wrongly so change certain type castings etc, incompatible with Java 8. If anybody knows a solution here .. shoot.
Bug 1363: Java 11: Extract and extend sun.misc.Unsafe functionality to UnsafeUtil
UnsafeUtil centralizes the workarounds (hack) of certain Java>=9 modularization encapsulation pitfalls, where no exports have been defined. The last resort.
1) Buffers utilizes UnsafeUtil for Java>=9 invokeCleaner.
2) To gain access for certain methods + fields w/o 'illegal access warnings', we have to temporarily disable the IllegalAccessLogger. Hence we provide a method 'T doWithoutIllegalAccessLogger(..<T> action)' for our essential module access under Java >= 9.
Fix gluegen-cpptasks-base.xml for crosscompilation, failed due to unset supposedly detected mandatory new properties
Move new detected build properties build.dynamiclibs, build.staticlibs and output.lib.type from gluegen.cpptasks.detect.os.1 to gluegen.cpptasks.detect.os. This enables setting these mandatory properties always, as gluegen.cpptasks.detect.os.1 gets overriden by custom cross-compilation configurations.
Also moving the property dump from gluegen.cpptasks.detect.os.1 to gluegen.cpptasks.detect.os for same reasons.
Reworked gluegen/make/scripts/setenv-android-tools.sh, following canonical environment variables and sets all required variables for cross-compilation. See file's comments!
ant files: - android.version -> android.api.level (default 24) - android.jar defaults to ${gluegen.root}/make/lib/android-sdk/24/android.jar (provided)
Bug 1417 - Android: Complete 1st round: make/lib/gluegen-cpptask-android-<abi>.xml and scripts
All aligned now - gluegen-cpptasks-android-aarch64.xml - gluegen-cpptasks-android-armv6.xml (this has ld flag --no-undefined disabled, due to internal missing symbols) - gluegen-cpptasks-android-x86.xml
Bug 1417 - Android: Classify SYSROOTs in NDK for native libraries (link) and headers (compile)
Utilizing '-sysroot' with the linker, we require standard FS layout.
'~/Android/Sdk/ndk/20.1.5948944/platforms/android-24/arch-arm64' contains the proper std FS layout for libraries under usr/lib, but lacks the header files. We call this 'ANDROID_TOOLCHAIN_SYSROOT0' and shall be used for linking.
'~/Android/Sdk/ndk/20.1.5948944/toolchains/llvm/prebuilt/linux-x86_64/sysroot' native libraries are not under std FS layout, but headers are under std FS layout for compilation under usr/include. We call this 'ANDROID_TOOLCHAIN_SYSROOT1' and shall be used for compilation.
Identified while working on openal-soft Android compilation, where we need to pass ANDROID_TOOLCHAIN_SYSROOT0
Bug 1417 - Android: Add ANDROID_TOOLCHAIN_SYSROOT1_INC_ARCH for arch specific includes like asm/types.h
Also adapt make/lib/gluegen-cpptask-android* files: - Set C++ stdlib = libstdc++ - Set isysroot (same as sysroot) - Add isystem: *_SYSROOT1_INC, *_SYSROOT1_INC_ARCH and *_SYSROOT1_INC/c++/v1
Bug 1417 - Android: Add ANDROID_TOOLCHAIN_SYSROOT1_INC_STL for LLVM's C++ STL headers (default since NDK r18)
Using LLVM's c++_shared as of NDK r18: https://developer.android.com/ndk/guides/cpp-support.html LLVM's c++ headers must come before other system header! Also see https://github.com/android/ndk/issues/452 and https://gitlab.kitware.com/cmake/cmake/issues/17059
Also adapt make/lib/gluegen-cpptask-android* files: - Compiler -- align for potential C++ usage, i.e.: -- don't use '-sysroot' not '-isysroot' -- IF using C++ STL, prepend ANDROID_TOOLCHAIN_SYSROOT1_INC_STL -- just add normal sysroot headers via '-isystem'
- Linker -- Use ANDROID_TOOLCHAIN_SYSROOT1_LIB1 and ANDROID_TOOLCHAIN_SYSROOT1_LIB2 for '-L' search path -- where ANDROID_TOOLCHAIN_SYSROOT1_LIB2 is for 'libc++' -> 'c++_shared'
Bug 1417 - Android: Use d8 for dex'ing w/ implicit Java8 desugaring (macro: aapt.signed)
The new SDK d8 dex'ing tool performs Java8 desugaring, hence allows using Java8 code style.
We use d8 instead of dx in the 'aapt.signed' macro of 'jogamp-androidtasks.xml'.
For the proper desugaring, we pass 'android-min.jar and 'target.rt.jar' Android and Java8 system runtime jar-files to d8's classpath.
Macro 'aapt.signed' also receives the new optional element 'd8-classpaths' to allows caller to pass further required jar-files to the d8 classpath. See build-test.xml.
Origin <https://github.com/apache/avro/blob/master/lang/java/avro/src/main/java/org/apache/avro/util/WeakIdentityHashMap.java> from their commit 70260919426f89825ca148f5ee815f3b2cf4764d. Apache License Version 2.0 until. Using our JogAmp 'New BSD 2-Clause License' for changes after this initial commit.
Related to Bug 1312, where we like to utilize a WeakIdentityHashMap, allowing to have cached shared GLContext to disappear .. a compromise.