search

apache / netbeans

Apache NetBeans
https://netbeans.apache.org/
Apache License 2.0
2.64k stars 849 forks source link

Netbeans 22 does not load a 8.9 gradle wrapper in project. Infinite loop. #7606

Closed patton73 closed 1 month ago

patton73 commented 2 months ago

Apache NetBeans version

Apache NetBeans 22

What happened

If you have a project with a gradle wrapper 8.9. Netbeans 22 cannot load it. It just starts an infinite loop but does not load anithing.

Language / Project Type / NetBeans Component

No response

How to reproduce

Just make a project with a gradle 8.9 wrapper in it.

Did this work correctly in an earlier version?

No / Don't know

Operating System

Linux Ubuntu 24.04 LTS

JDK

Jdk 17.0.11

Apache NetBeans packaging

Apache NetBeans provided installer

Anything else

No response

Are you willing to submit a pull request?

No

lkishalmi commented 2 months ago

Can you test that with NetBeans 23-rc1. That has Gradle 8.9 Tooling in it.

patton73 commented 2 months ago

I am going to test it as soon i can. Anyway it seems to me that the option "prefer gradle wrapper" does not work. I expect that if i choose that option the wrpper inside the project should be used to compile it and not the netbeans' built in tool.

neilcsmith-net commented 2 months ago

@patton73 you misunderstand. The Tooling API is a Gradle library for executing Gradle builds. It will use the wrapper in the project, and is meant to be forwards compatible. Tooling API 8.7 in NB22 should be able to run a Gradle 8.9 build. I wonder if this is a sign of an upstream compatibility issue, or that NetBeans is doing something with the Tooling API that is breaking that forwards compatibility promise? As well as testing 23-rc1, it would probably be good to understand what is breaking in NB22 so that the issue does not recur.

patton73 commented 2 months ago

Netbeans 22 just does not load the project and it goes on loading forever. No log, no error, nothing to see.

neilcsmith-net commented 2 months ago

Sure, but a stack dump or similar (eg. jstack) may show what it's stuck in.

patton73 commented 1 month ago

I tested also the netbeans daily build. And it hangs as well with gradle wrapper. You have as a test project that hangs, this one: https://github.com/Rebirth-Project/version-comparator No way to load this project with netbeans 22 and netbeans 23 daily build.

update: same problem with Gradle version 8.10.

neilcsmith-net commented 1 month ago

What else have you tried with? Have you compared to a basic project from Gradle init? Is it all projects affected? Did you import settings when trying NB23 rc?

patton73 commented 1 month ago

What else have you tried with? Have you compared to a basic project from Gradle init? Is it all projects affected? Did you import settings when trying NB23 rc?

The project i linked is a completely IDE free gradle project (you can compile it by command line). Yes I imported old Netbeans 22 settings. I try also to avoid importing old settings to see if it loads without entering the infinite loop.

patton73 commented 1 month ago

Update: even if i do not import netbeans 22 setting the daily build hangs in an infinite loop.

neilcsmith-net commented 1 month ago

But does it apply to a Gradle project created using gradle init or other projects? I'm still unclear whether it's specific to that project?

patton73 commented 1 month ago

update: a completely empty project created with "gradle init" with version 8.10 (even without build.gradle since it does not create it) loads. But this does not resolve the problem. I have many projects that i upgraded to gradle 8.9 and 8.10 and they do not load in netbeans 22 and newer. And unfortunately the IDE does not print any error. It just tries to load the project in an infinite loop.

neilcsmith-net commented 1 month ago

So, do they have any configuration in common? Does removing some / all of the .gradle directory help?

sdedic commented 1 month ago

@patton73 could you try to trim down some of the failing projects to a minimal sample (no sources are needed actually, just the build files and dir structure) and attach it ?

sdedic commented 1 month ago

OK, the culprit is now known, reproduced on https://github.com/Rebirth-Project/version-comparator. The net.researchgate.release plugin prompts on the stdin or console for release version; the getter is called as a part of project introspection, as the releaseVersion is a valid and readable task property. Sadly the helper method is not private which makes it a public object property in groovy.

Here's the relevant part of stacktrace from the gradle daemon:

"Daemon worker" #31 prio=5 os_prio=0 cpu=4670,32ms elapsed=215,31s tid=0x00007f3784008770 nid=0x5fb5e in Object.wait()  [0x00007f37e8cce000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(java.base@17.0.8/Native Method)
        - waiting on <0x00000000e1060b38> (a java.lang.Object)
        at java.lang.Object.wait(java.base@17.0.8/Object.java:338)
        at org.gradle.internal.daemon.clientinput.StdInStream.waitForContent(StdInStream.java:77)
        at org.gradle.internal.daemon.clientinput.StdInStream.read(StdInStream.java:57)
        - locked <0x00000000e1060b38> (a java.lang.Object)
        at sun.nio.cs.StreamDecoder.readBytes(java.base@17.0.8/StreamDecoder.java:270)
        at sun.nio.cs.StreamDecoder.implRead(java.base@17.0.8/StreamDecoder.java:313)
        at sun.nio.cs.StreamDecoder.read(java.base@17.0.8/StreamDecoder.java:188)
        - locked <0x00000000ed478050> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(java.base@17.0.8/InputStreamReader.java:177)
        at java.io.BufferedReader.fill(java.base@17.0.8/BufferedReader.java:162)
        at java.io.BufferedReader.readLine(java.base@17.0.8/BufferedReader.java:329)
        - locked <0x00000000ed478050> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(java.base@17.0.8/BufferedReader.java:396)
        at java_io_BufferedReader$readLine.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
        at net.researchgate.release.PluginHelper.readLine(PluginHelper.groovy:183)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@17.0.8/Native Method)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@17.0.8/NativeMethodAccessorImpl.java:77)
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@17.0.8/DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(java.base@17.0.8/Method.java:568)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
        at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrapNoCoerce.invoke(StaticMetaMethodSite.java:149)
        at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:100)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:55)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:217)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:240)
        at net.researchgate.release.PluginHelper.getReleaseVersion(PluginHelper.groovy:149)
        at net.researchgate.release.PluginHelper.getReleaseVersion(PluginHelper.groovy)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@17.0.8/Native Method)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@17.0.8/NativeMethodAccessorImpl.java:77)
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@17.0.8/DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(java.base@17.0.8/Method.java:568)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
        at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1942)
        at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3815)

I've tried quick patches like giving the gradle's BuildAction an empty (byte[0]) InputStream or even a closed Inputstream, but that did not seem to make any difference (surprisingly). I need to try another magic or - at the worst - make an exclusion for this class:property.

patton73 commented 1 month ago

Strarting from this project : https://github.com/Rebirth-Project/version-comparator

update: cleaning the project and removing .gradle and netbeans cache does nothing. update2: cleaning the project and removing .gradle and netbeans cache and removing sources leaving only default directories (src/main/java with inside the file module-info.java) loads the project.

The behaviour is absolutely random.

And this does not happen till gradle 8.8 wrapper. Only with gradle 8.9 and newer.

patton73 commented 1 month ago

OK, the culprit is now known, reproduced on https://github.com/Rebirth-Project/version-comparator. The net.researchgate.release plugin prompts on the stdin or console for release version; the getter is called as a part of project introspection, as the releaseVersion is a valid and readable task property. Sadly the helper method is not private which makes it a public object property in groovy.

Here's the relevant part of stacktrace from the gradle daemon:

"Daemon worker" #31 prio=5 os_prio=0 cpu=4670,32ms elapsed=215,31s tid=0x00007f3784008770 nid=0x5fb5e in Object.wait()  [0x00007f37e8cce000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(java.base@17.0.8/Native Method)
        - waiting on <0x00000000e1060b38> (a java.lang.Object)
        at java.lang.Object.wait(java.base@17.0.8/Object.java:338)
        at org.gradle.internal.daemon.clientinput.StdInStream.waitForContent(StdInStream.java:77)
        at org.gradle.internal.daemon.clientinput.StdInStream.read(StdInStream.java:57)
        - locked <0x00000000e1060b38> (a java.lang.Object)
        at sun.nio.cs.StreamDecoder.readBytes(java.base@17.0.8/StreamDecoder.java:270)
        at sun.nio.cs.StreamDecoder.implRead(java.base@17.0.8/StreamDecoder.java:313)
        at sun.nio.cs.StreamDecoder.read(java.base@17.0.8/StreamDecoder.java:188)
        - locked <0x00000000ed478050> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(java.base@17.0.8/InputStreamReader.java:177)
        at java.io.BufferedReader.fill(java.base@17.0.8/BufferedReader.java:162)
        at java.io.BufferedReader.readLine(java.base@17.0.8/BufferedReader.java:329)
        - locked <0x00000000ed478050> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(java.base@17.0.8/BufferedReader.java:396)
        at java_io_BufferedReader$readLine.call(Unknown Source)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:130)
        at net.researchgate.release.PluginHelper.readLine(PluginHelper.groovy:183)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@17.0.8/Native Method)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@17.0.8/NativeMethodAccessorImpl.java:77)
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@17.0.8/DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(java.base@17.0.8/Method.java:568)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
        at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrapNoCoerce.invoke(StaticMetaMethodSite.java:149)
        at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:100)
        at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:55)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:217)
        at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:240)
        at net.researchgate.release.PluginHelper.getReleaseVersion(PluginHelper.groovy:149)
        at net.researchgate.release.PluginHelper.getReleaseVersion(PluginHelper.groovy)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@17.0.8/Native Method)
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@17.0.8/NativeMethodAccessorImpl.java:77)
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@17.0.8/DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(java.base@17.0.8/Method.java:568)
        at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:107)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
        at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:1942)
        at groovy.lang.MetaClassImpl.getProperty(MetaClassImpl.java:3815)

I've tried quick patches like giving the gradle's BuildAction an empty (byte[0]) InputStream or even a closed Inputstream, but that did not seem to make any difference (surprisingly). I need to try another magic or - at the worst - make an exclusion for this class:property.

You are saying that the "release" task is called automatically even if you do not call the task? Since that is the task that prompts for input. And this does not happen if you compile by command line.

sdedic commented 1 month ago

You are saying that the "release" task is called automatically even if you do not call the task? Since that is the task that prompts for input. And this does not happen if you compile by command line.

No. The task is not run. But NetBeans inspect all configured tasks and extensions for their properties. This task's field is (I guess) accidentally public (the author perhaps didn't care about default groovy visibility) making it formally a property - and mere reading of the property value results in an interactive prompt.

mbien commented 1 month ago

Update: even if i do not import netbeans 22 setting the daily build hangs in an infinite loop.

@patton73 can you clarify what you mean by infinite loop? Does NetBeans keep doing something in a loop and it never completes, or does it mean that it gets stuck and the PC is idling from that point on.

patton73 commented 1 month ago

Update: even if i do not import netbeans 22 setting the daily build hangs in an infinite loop.

@patton73 can you clarify what you mean by infinite loop? Does NetBeans keep doing something in a loop and it never completes, or does it mean that it gets stuck and the PC is idling from that point on.

NetBeans keep doing something in a loop and it never completes. In particular it never loads the current project. it never finishes to load it. But it does not hang. You can continue working on other projects.

sdedic commented 1 month ago

@patton73 we are arguing about the wording loop, which indicates something is being done repeatedly, over and over. Like displaying again and again an error message about an unloadable project, or finishing the load and starting the project load again etc. During my investigation I didn't observe repeated actions, but just one pending and never finished action (project load).

So the question is whether you are sure about repeating (loop) - and the issue should be analyzed more to reproduce the "loop", or the report was simply inaccurate and we can assume the issue is fixed. With the PR applied I am able to open the test project without problems.

patton73 commented 1 month ago

Ok to be precise that is not a loop but a "pending" loading action that never finish. I called it a loop because in the status bar (bottom-right) the action never ends and the UI always shows the loading running action. So ok that is not a loop.

mbien commented 1 month ago

@patton73 thanks for clarifying! all good. Thats what we saw too.

patton73 commented 1 month ago

I tested the new daily build. Now it works. I would close this bug. Thanks a lot for your help.