[REGRESSION] Gradle "Project Problems"

[errael]

Apache NetBeans version

Apache NetBeans 22 release candidate NOTE: both RC2 and RC3

What happened

Download RC-2, copy NB-21 userdir, Start NB, Gradle Project Problems.

Language / Project Type / NetBeans Component

Gradle

How to reproduce

Using project and sole sub-project from https://github.com/errael/astrology-castro BRANCH: LogOps

    The gradle projects are in
        astrology-castro/codegen
        astrology-castro/codegen/castro

Product Version: Apache NetBeans IDE 22-rc2
Java: 21.0.1; OpenJDK 64-Bit Server VM 21.0.1+12-29
Runtime: OpenJDK Runtime Environment 21.0.1+12-29
System: Linux version 6.8.0-76060800daily20240311-generic running on amd64; UTF-8; en_US (nb)
User directory: /home/err/.nb/22/userdir
Cache directory: /home/err/.nb/22/cachedir

• Copy userdir from NB-21
• Startup NetBeans, the projects already open, get ProjectProblems dialog for both projects. See png attachment
• Doing Clean&Build on each project (right click on project) succeeds. But ends with Cannot Load, See png attachement (NOTE the gradle-6.8.3)

NOTE After clean build there are many bogus warnings about "unused"

Did this work correctly in an earlier version?

Apache NetBeans 21

Operating System

Linux harmony 6.8.0-76060800daily20240311-generic #202403110203~1713206908~22.04~3a62479 SMP PREEMPT_DYNAMIC Mon A x86_64 x86_64 x86_64 GNU/Linux

JDK

JDK-21/JDK-11

Apache NetBeans packaging

Apache NetBeans binary zip

Anything else

No response

Are you willing to submit a pull request?

No

[errael]

Just did a start/close of NB and am attaching the log.

The first indication of trouble is

INFO [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]:
    Load aiming EVALUATED for Unloaded Gradle Project:
    GradleFiles[projectDir=/src/astro/castro/codegen/castro, rootDir=/src/astro/castro/codegen]
INFO [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]:
    Load aiming FULL for Gradle: :castro[FALLBACK]
INFO [org.netbeans.modules.gradle.execute.GradleDistributionProviderImpl]:
    Gradle Distribution for Gradle:
    :castro[FALLBACK] is GradleDistribution{gradleUserHome=/home/err/.gradle,
        distributionDir=/home/err/.gradle/wrapper/dists/gradle-6.8.3-bin/7ykxq50lst7lb7wx1nijpicxn/gradle-6.8.3,
        distributionURI=https://services.gradle.org/distributions/gradle-6.8.3-bin.zip,
        version=Gradle 6.8.3}
INFO [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]:
    Load aiming EVALUATED for Unloaded Gradle Project:
    GradleFiles[projectDir=/src/astro/castro/codegen, rootDir=/src/astro/castro/codegen]
INFO [org.netbeans.modules.gradle.loaders.GradleProjectLoaderImpl]:
    Load aiming FULL for Gradle: AstroComp[FALLBACK]
WARNING [org.netbeans.modules.gradle.loaders.LegacyProjectLoader]:
    Loading of script /src/astro/castro/codegen/castro/build.gradle threw an exception {2}
INFO [org.netbeans.modules.gradle.loaders.LegacyProjectLoader]:
    Stacktrace from gradle daemon:
java.lang.IllegalArgumentException: Unsupported class file major version 61
	at org.objectweb.asm.ClassReader.<init>(ClassReader.java:196)
	at org.objectweb.asm.ClassReader.<init>(ClassReader.java:177)
	at org.objectweb.asm.ClassReader.<init>(ClassReader.java:163)
	at org.gradle.tooling.internal.provider.serialization.ClasspathInferer.find(ClasspathInferer.java:105)
Caused: org.gradle.api.GradleException: Could not determine the class-path for class org.netbeans.modules.gradle.loaders.LegacyProjectLoader$NbProjectInfoAction.
	at org.gradle.tooling.internal.provider.serialization.ClasspathInferer.find(ClasspathInferer.java:142)
	at org.gradle.tooling.internal.provider.serialization.ClasspathInferer.getClassPathFor(ClasspathInferer.java:60)

LOG.txt

[errael]

Just tried with RC3, sames problems

[matthiasblaesing]

java.lang.IllegalArgumentException: Unsupported class file major version 61

That is a class build for JDK 17. My gut feeling the asm Version that complains there is to old.

[errael]

java.lang.IllegalArgumentException: Unsupported class file major version 61

That is a class build for JDK 17. My gut feeling the asm Version that complains there is to old.

I'm not sure what you're saying. What is "That", the first word of the comment, referring to?

This works with NB-21 running under JDK-21.

[matthiasblaesing]

java.lang.IllegalArgumentException: Unsupported class file major version 61

That is a class build for JDK 17. My gut feeling the asm Version that complains there is to old.

I'm not sure what you're saying. What is "That", the first word of the comment, referring to?

That class that is being processed by asm according to the stack trace.

But this:

java.lang.IllegalArgumentException: Unsupported class file major version 61 at org.objectweb.asm.ClassReader.(ClassReader.java:196) at org.objectweb.asm.ClassReader.(ClassReader.java:177) at org.objectweb.asm.ClassReader.(ClassReader.java:163) at org.gradle.tooling.internal.provider.serialization.ClasspathInferer.find(ClasspathInferer.java:105) Caused: org.gradle.api.GradleException: Could not determine the class-path for class org.netbeans.modules.gradle.loaders.LegacyProjectLoader$NbProjectInfoAction.

Makes no sense. NB bundles asm 9.7 and gradle 7.4 bundles asm 9.2. Both should support JDK 17 (9.2 is documented to support JDK 18 classes).

My gut feeling: Someone decided it would be a good idea that the gradle tooling API passed java bytecode from the caller (NetBeans IDE) to the project being worked on. If that is the case, the asm version relevant here is the one in the gradle being targetted. If that asm version supported JDK 11, it would have worked because the bytecode level for the gradle project was bumped in this cycle to JDK 17.

@lkishalmi what do you think?

[errael]

I didn't even think about the class file version. The project is compiled for jdk-11, there are some multi version jars that have something for jdk-16. In the main gradle directory, astrology-castro/codegen I did the following. Yep, makes no sense. gradle is supposed to use JDK-11 because it a gradle 6.8.3 project.

$ for i in $(find . -name '*.class'); do echo $(javap -v $i | grep 'major version');done | sort | uniq
major version: 55
major version: 60

[neilcsmith-net]

My guess is that the Java version upgrade from 8 to 17 in #7257 needs reverting prior to release.

This line seems to pass NBProjectInfoAction into ProjectConnection::action - https://github.com/apache/netbeans/blob/master/extide/gradle/src/org/netbeans/modules/gradle/loaders/LegacyProjectLoader.java#L484

Looking at the docs of ProjectConnection::action the passed in class needs to be deserializable into the build. https://docs.gradle.org/current/javadoc/org/gradle/tooling/ProjectConnection.html#action-org.gradle.tooling.BuildAction-

[sdedic]

will try to investigate / fix tomorrow

[lkishalmi]

My guess is that the Java version upgrade from 8 to 17 in #7257 needs reverting prior to release.

This line seems to pass NBProjectInfoAction into ProjectConnection::action - https://github.com/apache/netbeans/blob/master/extide/gradle/src/org/netbeans/modules/gradle/loaders/LegacyProjectLoader.java#L484

Looking at the docs of ProjectConnection::action the passed in class needs to be deserializable into the build. https://docs.gradle.org/current/javadoc/org/gradle/tooling/ProjectConnection.html#action-org.gradle.tooling.BuildAction-

Yes, that's the issue. Revert could work.

For the next release it would be better to split the gradle module and have a core that does the communication with the Gradle Tooling that can be kept on Java 8 for the foreseeable future.

[mbien]

i am usually for reverts in situations like this. But if the lang level of the module is what causes this, this can be trivially fixed until a better solution is found.

-> https://github.com/apache/netbeans/pull/7367 (untested)

bonus: fixes two evil var occurrences :P

[mbien]

@errael dev build: https://github.com/apache/netbeans/actions/runs/9006322390/artifacts/1485162519

[neilcsmith-net]

@mbien :+1: - totally agree - I meant reverting the language level change, not the whole lot. Had also taken a quick look at what was involved, but hadn't got around to looking at the changes. PR looks good to me at a glance.

I hadn't realised that the Gradle Tooling API offered this weird hacky thing with serialization and bytecode loading in the daemon from the IDE classes.

[errael]

... dev build: ...

@mbien It comes up cleanly without "Project Problems". I've tried a few things, it's looking good.