[groovy] don't use wildcards in classpath instead point out exact jar

[hbiyik]

Description

The issue is triggered when java is used in containerized environment.
When the container tool mounts/binds ext4 fs directly or with an overlayfs, the wildcard used in CLASSPATH (-cp) of java is not processing all the files pointed. This seems to happen only when host and the contaniner has different architecture (ie: 32 vs 64). So not every containerized env has this issue.

Workarounds:
For overlays fs, giving an option xino=on prevents this happening, for systemd-nspawn, --bind argument does mount with xino=off, therefore i could not find a way to modify this.

For ext4 mounting to container, i could not find a workaround.

General workaround in Kodi Buildsystem is to point directly to jar files instead of using wildcards.

Motivation and context

It prevents some existing and potential future build errors

How has this been tested?

in archlinux x86_64 host running aarhc64 and armv7h container.

What is the effect on users?

fixes #24225

Screenshots (if appropriate):

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• Student submission (PR was done for educational purposes and will be treated as such)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[fuzzard]

The problem this introduces is that you are now locked to hard coded version numbers.

[hbiyik]

is it not possible to -Dgroovy_SOURCE_DIR=/tmp -DGROOVY_VER=a.b.c, sorry i am not good with cmake.

[fuzzard]

That was the point of the wildcard. So you didn't have to do 6 arguments just for groovy shit

[hbiyik]

ok up to you then,

sidenote: when requesting custom groovy, it was already necessary to define the versions of groove, text and lang. but yeah...

edit i mean, before wildcards...

[fuzzard]

Is this possibly still relevant? https://stackoverflow.com/questions/14722657/java-classpath-wildcard-behaviour

ie quote the asterisk.

  set(classpath ${groovy_SOURCE_DIR}/lib/\"*\"
                ${apache-commons-lang_SOURCE_DIR}/\"*\"
                ${apache-commons-text_SOURCE_DIR}/\"*\"
                ${CMAKE_SOURCE_DIR}/tools/codegenerator
                ${CMAKE_CURRENT_SOURCE_DIR}/../python)

[hbiyik]

@fuzzard ill test it today and feedback

[hbiyik]

tested with

_JAVA_LAUNCHER_DEBUG=true /usr/bin/java -cp build/share/groovy/lib/"*" groovy.ui.GroovyMain

it does not work

----_JAVA_LAUNCHER_DEBUG----
Launcher state:
	First application arg index: 4
	debug:on
	javargs:off
	program name:java
	launcher name:openjdk
	javaw:off
	fullversion:17.0.11+9
Java args:
Command line args:
argv[0] = /usr/bin/java
argv[1] = -cp
argv[2] = build/share/groovy/lib/*
argv[3] = groovy.ui.GroovyMain
JRE path is /usr/lib/jvm/java-17-openjdk
jvm.cfg[0] = ->-server<-
jvm.cfg[1] = ->-client<-
1486 micro seconds to parse jvm.cfg
Default VM: server
Does `/usr/lib/jvm/java-17-openjdk/lib/server/libjvm.so' exist ... yes.
mustsetenv: FALSE
JVM path is /usr/lib/jvm/java-17-openjdk/lib/server/libjvm.so
24506 micro seconds to LoadJavaVM
Expanded wildcards:
    before: "build/share/groovy/lib/*"
    after : "build/share/groovy/lib/*"
JavaVM args:
    version 0x00010002, ignoreUnrecognized is JNI_FALSE, nOptions is 4
    option[ 0] = '-Dsun.java.launcher.diag=true'
    option[ 1] = '-Djava.class.path=build/share/groovy/lib/*'
    option[ 2] = '-Dsun.java.command=groovy.ui.GroovyMain'
    option[ 3] = '-Dsun.java.launcher=SUN_STANDARD'
340099 micro seconds to InitializeJVM
Main class is 'groovy.ui.GroovyMain'
App's argc is 0
Error: Could not find or load main class groovy.ui.GroovyMain
Caused by: java.lang.ClassNotFoundException: groovy.ui.GroovyMain
java.lang.ClassNotFoundException: groovy.ui.GroovyMain
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
	at java.base/java.lang.ClassLoader.loadClass(Unknown Source)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Unknown Source)
	at java.base/sun.launcher.LauncherHelper.loadMainClass(Unknown Source)
	at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(Unknown Source)

[fuzzard]

I will mention, im not against this per se, as it doesnt effect me in the slightest. The existing code is however correct in its functionality, so the true fault lies outside of this code base.

[hbiyik]

true, therefore i marked as improvement, it is also not %100 necessary for me, i can use out of tree patches, frankly the people who might face this issue is minority, so it is also ok to not merge.

Whoever has this problem can google and find this ticket in case they need to.