Upgraded various maven plugin versions to latest available.

[archenroot]

Upgraded source and target from 1.7 to 1.8 for maven-compiler-plugin.

[saudet]

Upgraded source and target from 1.7 to 1.8 for maven-compiler-plugin.

Don't do that, Groovy as used by Gradle doesn't support 1.8 features very well

[archenroot]

Ok let me fix it. I did it as using Java 21 where 1.7 is not supported anymore 1.8 will be using jdk 17

[saudet]

Yeah, I really wonder if anyone is ever going to use anything after 17 in production...

[archenroot]

I reverted back the source and target versions to 1.7

[HGuillemet]

Upgraded source and target from 1.7 to 1.8 for maven-compiler-plugin.

Don't do that, Groovy as used by Gradle doesn't support 1.8 features very well

Are you sure this is still an issue ? What 's the problem exactly ?
Gradle users work with Groovy DSL on Java project written in Java 1.8, 11 or 17 for years.

[saudet]

Yes, I'm sure: https://docs.gradle.org/current/userguide/validation_problems.html#implementation_unknown

[HGuillemet]

What you linked is related to the use of lambdas in gradle plugins. I don't think it's related to the version of Java javacpp itself is written with. Or did I miss something ?

[saudet]

If you can figure out a nicer way to make sure the build fails on lambda expressions, we could add that instead

[HGuillemet]

The build of what ?
I need an example of failure due to lambda expression to understand what's going on, why we are stuck with a 12+ years old version of Java, and look for a possible solution.

[saudet]

The build for JavaCPP, we can't use lambda expressions in it, see issue bytedeco/gradle-javacpp#23

[saudet]

And there's most likely similar issues with Android, Kotlin, Scala, etc, so until we have a really good reason to move away from Java SE 7, I'll just stick with it.

[archenroot]

Maybe one of the reasons/ideas to upgrade to at least 1.8 is to use latest graalvm-21 (and later in future) and start building native-images for the code base, although not sure what are your long-term plans.

[saudet]

I'm not having any issues with GraalVM 21. What error do you get when running this sample code?
https://github.com/bytedeco/sample-projects/tree/master/opencv-stitching-native

[archenroot]

@saudet - I switched to Oracle GraalVM 21.0.1 (I use SDKMAN to managed different version simultaneously)

I got an error:

[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] Source option 6 is no longer supported. Use 8 or later.
[ERROR] Target option 6 is no longer supported. Use 8 or later.

So I upgraded maven-compiler-plugin to 3.12.1 which defaults to 8:

And I got this build log(note the recommendations):

[WARNING] Major.Minor version mismatch between native-image-maven-plugin (21.2.0) and native-image executable (Unknown)
[INFO] Executing: /home/zangetsu/.sdkman/candidates/java/21.0.1-graal/lib/svm/bin/native-image -cp /home/zangetsu/.m2/repository/org/bytedeco/opencv-platform/4.5.5-1.5.7/opencv-platform-4.5.5-1.5.7.jar:/home/zangetsu/.m2/repository/org/bytedeco/openblas-platform/0.3.19-1.5.7/openblas-platform-0.3.19-1.5.7.jar:/home/zangetsu/.m2/repository/org/bytedeco/javacpp-platform/1.5.7/javacpp-platform-1.5.7.jar:/home/zangetsu/.m2/repository/org/bytedeco/javacpp/1.5.7/javacpp-1.5.7-linux-x86_64.jar:/home/zangetsu/.m2/repository/org/bytedeco/openblas/0.3.19-1.5.7/openblas-0.3.19-1.5.7.jar:/home/zangetsu/.m2/repository/org/bytedeco/openblas/0.3.19-1.5.7/openblas-0.3.19-1.5.7-linux-x86_64.jar:/home/zangetsu/.m2/repository/org/bytedeco/opencv/4.5.5-1.5.7/opencv-4.5.5-1.5.7.jar:/home/zangetsu/.m2/repository/org/bytedeco/javacpp/1.5.7/javacpp-1.5.7.jar:/home/zangetsu/.m2/repository/org/bytedeco/opencv/4.5.5-1.5.7/opencv-4.5.5-1.5.7-linux-x86_64.jar:/home/zangetsu/proj/public/bytedeco-sample-projects-archenroot/opencv-stitching-native/target/opencv-stitching-native-1.5.7.jar --no-fallback --allow-incomplete-classpath -H:Class=org.bytedeco.samples.Stitching -H:Name=stitching
Warning: Using a deprecated option --allow-incomplete-classpath from command line. Allowing an incomplete classpath is now the default. Use --link-at-build-time to report linking errors at image build time for a class or package.
Warning: The option '-H:Name=stitching' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: Please re-evaluate whether any experimental option is required, and either remove or unlock it. The build output lists all active experimental options, including where they come from and possible alternatives. If you think an experimental option should be considered as stable, please file an issue.
========================================================================================================================
GraalVM Native Image: Generating 'stitching' (executable)...
========================================================================================================================
[1/8] Initializing...                                                                                    (7.0s @ 0.56GB)
 Java version: 21.0.1+12, vendor version: Oracle GraalVM 21.0.1+12.1
 Graal compiler: optimization level: 2, target machine: x86-64-v3, PGO: ML-inferred
 C compiler: gcc (linux, x86_64, 11.4.0)
 Garbage collector: Serial GC (max heap size: 80% of RAM)
 1 user-specific feature(s):
 - com.oracle.svm.thirdparty.gson.GsonFeature
------------------------------------------------------------------------------------------------------------------------
 1 experimental option(s) unlocked:
 - '-H:Name' (alternative API option(s): -o stitching; origin(s): command line)
------------------------------------------------------------------------------------------------------------------------
Build resources:
 - 26.49GB of memory (5.3% of 503.77GB system memory, determined at start)
 - 32 thread(s) (36.4% of 88 available processor(s), determined at start)
Found pending operations, continuing analysis.
[2/8] Performing analysis...  [*****]                                                                   (13.7s @ 0.93GB)
    5,347 reachable types   (79.8% of    6,702 total)
    5,314 reachable fields  (41.7% of   12,753 total)
   27,718 reachable methods (34.7% of   79,948 total)
    2,479 types,   205 fields, and 1,998 methods registered for reflection
    1,055 types,   145 fields, and 1,088 methods registered for JNI access
        4 native libraries: dl, pthread, rt, z
[3/8] Building universe...                                                                               (2.5s @ 1.91GB)
[4/8] Parsing methods...      [**]                                                                       (2.9s @ 2.25GB)
[5/8] Inlining methods...     [***]                                                                      (0.4s @ 1.29GB)
[6/8] Compiling methods...    [****]                                                                    (15.6s @ 0.98GB)
[7/8] Layouting methods...    [**]                                                                       (2.8s @ 1.27GB)
[8/8] Creating image...       [***]                                                                      (7.0s @ 1.00GB)
  12.11MB ( 6.88%) for code area:    15,985 compilation units
 161.39MB (91.61%) for image heap:  333,533 objects and 1,395 resources
   2.66MB ( 1.51%) for other data
 176.16MB in total
------------------------------------------------------------------------------------------------------------------------
Top 10 origins of code area:                                Top 10 object types in image heap:
   6.94MB java.base                                          141.97MB byte[] for embedded resources
   2.50MB svm.jar (Native Image)                               6.81MB byte[] for java.lang.String
1010.38kB opencv-4.5.5-1.5.7.jar                               3.13MB byte[] for code metadata
 464.54kB javacpp-1.5.7.jar                                    2.58MB java.lang.String
 407.95kB java.management                                      1.38MB java.lang.Class
 148.73kB java.logging                                         1.16MB com.oracle.svm.core.jni.access.JNINativeLinkage
 148.70kB com.oracle.svm.svm_enterprise                      629.01kB java.lang.Object[]
  91.16kB jdk.proxy4                                         444.73kB byte[] for general heap data
  73.54kB jdk.charsets                                       403.60kB heap alignment
  47.88kB jdk.proxy3                                         366.48kB byte[] for reflection metadata
 235.91kB for 15 more packages                                 2.56MB for 1076 more object types
                              Use '-H:+BuildReport' to create a report with more details.
------------------------------------------------------------------------------------------------------------------------
Security report:
 - Binary includes Java deserialization.
 - Use '--enable-sbom' to embed a Software Bill of Materials (SBOM) in the binary.
------------------------------------------------------------------------------------------------------------------------
Recommendations:
 G1GC: Use the G1 GC ('--gc=G1') for improved latency and throughput.
 PGO:  Use Profile-Guided Optimizations ('--pgo') for improved throughput.
 INIT: Adopt '--strict-image-heap' to prepare for the next GraalVM release.
 HEAP: Set max heap for improved and more predictable memory usage.
 CPU:  Enable more CPU features with '-march=native' for improved performance.
------------------------------------------------------------------------------------------------------------------------
                        3.3s (5.9% of total time) in 48 GCs | Peak RSS: 3.83GB | CPU load: 16.00
------------------------------------------------------------------------------------------------------------------------
Produced artifacts:
 /home/zangetsu/proj/public/bytedeco-sample-projects-archenroot/opencv-stitching-native/target/stitching (executable)
========================================================================================================================
Finished generating 'stitching' in 54.1s.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:05 min
[INFO] Finished at: 2024-01-01T13:10:30+01:00
[INFO] ------------------------------------------------------------------------

And I am capable to run the sample:

[archenroot]

@saudet - the thing with graalvm is that latest v21 requires at least java 1.8 code...

[saudet]

Well, you've just tried it yourself and it works fine with classes compiled for Java SE 7, so there's no issues, right?

[HGuillemet]

The build for JavaCPP, we can't use lambda expressions in it, see issue bytedeco/gradle-javacpp#23

This issue is very specific to plugin authoring in Java: gradle sometimes tracks the versions of codes to determine if the output of a task is up to date, like the code of the task itself. And it's apparently impossible to determine the version of a code written as a Java lambda expression. So we cannot write tasks as Java lambda expressions in Gradle plugin. Gradle plugins written in Kotlin or Groovy can use lambda expressions.
You already did the modification in JavaCPP Gradle plugin to remove lambdas.

So this issue does not prevent JavaCPP itself to be written in Java 8+ and to contain lambdas. And does not prevent JavaCPP Gradle plugin to be written in Java 8 either as long as tasks are not written as lambdas.

Java 7 bytecode is still supported by OpenJDK 21 but we cannot target 7 with javac anymore. So we need Java 17- to compile JavaCPP.

I don't know anything about GraalVM, but I guess it's the same ?

I doubt Android or any current technology would cause any problem if JavaCPP is targetted to Java 8 or 11 but in the other hand, as long as JavaCPP is in "maintenance" mode and that all platform still can run Java 7 bytecode, there is little reason to upgrade.