Next Engine release

Development
21

…so somewhere between JDK11 and JDK18, the ByteBuffer.clear():ByteBuffer override was added.

It is added in java 9 I think.

That is what I am suspicious of too, but our GitHub actions built JME for maven publishing with java 8 and I can confirm that jar is built with java 8.

1 Like
22

I don’t see how it can be anything else.

clear():Buffer and clear():ByteBuffer are two different methods. One exists in JDK8 and the other doesn’t.

That’s weird because it is not in JDK11:
https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/nio/ByteBuffer.html

How?

1 Like
23

What type of JDK-8 ? The docs above are oracle’s only.

24

Yeah, i glanced JDK-8 docs and sources and can confirm this override is new, it isn’t on jdk-8.

25 
javap -verbose BufferUtils.class | grep major

major version: 52
26

That’s only telling you that the class format is JDK8 compatible. It says nothing about what JDK libraries it was compiled against.

The method was added in JDK13.

JDK12: ByteBuffer (Java SE 12 & JDK 12 )
JDK13: ByteBuffer (Java SE 13 & JDK 13 )

So JME is being compiled with a newer java and is maybe missing some source version setting.

Edit: and note that I think after JDK10, the sourceCompatibility setting no longer works?

I have this in my builds to try and be 1.7 compatible for SimMath, for example:

And a similar thing in my buildSrc arranged projects:

1 Like
27

Maybe something going crazy with Github’s actions.

But looking at the workflow run summary, I see only artifacts built with jdk8 on ubuntu are uploaded to maven:

2 Likes
28

Does re-running the java-8 build action only and watching it, may help to diagnose the problem or to track the script ?

29

I didn’t see anything in the logs that confirms that JDK8 was what’s being used other than that the job is called “Build on JDK8”.

…I presume it’s also not possible that other versions are overwriting the JDK8 version before it gets uploaded.

30

Well, the logs are already there

Setup java environment

0s
Run actions/setup-java@v3
  with:
    distribution: temurin
    java-version: 8
    java-package: jdk
    check-latest: false
    server-id: github
    server-username: GITHUB_ACTOR
    server-password: GITHUB_TOKEN
    overwrite-settings: true
    job-status: success
    token: ***
Installed distributions
  Resolved Java 8.0.352+8 from tool-cache
  Setting Java 8.0.352+8 as the default
  Creating toolchains.xml for JDK version 8 from temurin
  Writing to /home/runner/.m2/toolchains.xml
  
  Java configuration:
    Distribution: temurin
    Version: 8.0.352+8
    Path: /opt/hostedtoolcache/Java_Temurin-Hotspot_jdk/8.0.352-8/x64
  
Creating settings.xml with server-id: github
Writing to /home/runner/.m2/settings.xml
1 Like
31

I guess this is the issue, updating to gradle 7.6 always requires JDK-11+, so jdk-8 is ignored in this case:

Gradle automatically relies on adoptium open-jdk if it doesn’t exist, it’s installed by default.

1 Like
32

Is this mentioned somewhere on their release note?

1 Like
33

I think yes, however you can test which java is your gradle using, add gradle --version before the running script and concatenate using && with the build script.

└──╼ $gradle --version

------------------------------------------------------------
Gradle 7.6
------------------------------------------------------------

Build time:   2022-11-25 13:35:10 UTC
Revision:     daece9dbc5b79370cc8e4fd6fe4b2cd400e150a8

Kotlin:       1.7.10
Groovy:       3.0.13
Ant:          Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM:          17.0.5 (Debian 17.0.5+8-Debian-2)
OS:           Linux 5.10.0-18-amd64 amd64
34

And if gradle is configured properly then it “shouldn’t” matter. Need to figure out where to add the configuration I linked above to our JME builds. I’ve never really understood our gradle setup so I don’t know where exactly to look.

Edit: probably in common.gradle

Easy to try.

1 Like
35

image
image514×539 40.3 KB

EDIT:
Unless we have to configure it ourselves, it will default to openjdk17.
https://docs.gradle.org/7.6/release-notes.html

1 Like
36

https://docs.gradle.org/current/userguide/toolchains.html#sec:consuming

EDIT: This should control the java version the gradle is consuming.

1 Like
37

Before messing with the tool chains…

Try adding:

compileJava { // compile-time options:
    options.encoding = 'UTF-8'
    options.compilerArgs << '-Xlint:unchecked'
    options.deprecation = true
    if( JavaVersion.current().isCompatibleWith(JavaVersion.VERSION_1_10) ) {
        options.release = 8
    }
}

…or similar to common.gradle and see what happens.

Edit: because note that I build my stuff on JDK18 these days and Mythruna will still run on Java8 just fine.

2 Likes
38

@Ali_RS I added a new PR to do some testing:

1 Like
39

I have added gradle --version at the beginning of the bash script, here is the result:

------------------------------------------------------------
Gradle 7.6
------------------------------------------------------------

Build time:   2022-11-25 13:35:10 UTC
Revision:     daece9dbc5b79370cc8e4fd6fe4b2cd400e150a8

Kotlin:       1.7.10
Groovy:       3.0.13
Ant:          Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM:          1.8.0_352 (Temurin 25.352-b08)
OS:           Linux 5.15.0-1030-azure amd64

This means that gradle already uses java-8.

1 Like
40

And I made a PR with Paul suggestion

1 Like