Re: Refactor renaming hardly works anymore

[Emilian Bold]

My 2c: there are multiple levels to tweak this starting from "should
Compile on Save be enabled by default" to "remove all code". As a
feature to me "Apply Code Changes" seems separate from
"Compile-on-Save" although they might use some common plumbing.

--emi

On Wed, Feb 26, 2020 at 5:31 PM Eirik Bakke  wrote:
>
> Wait--why would we get rid of Compile-on-Save? Are you guys building your 
> projects on every run? And how would "Apply Code Changes" work in the 
> debugger without Compile-on-Save?
>
> -- Eirik
>
> -Original Message-
> From: Emilian Bold 
> Sent: Tuesday, February 25, 2020 10:04 AM
> To: Neil C Smith 
> Cc: NetBeans Mailing List ; Geertjan Wielenga 
> 
> Subject: Re: Refactor renaming hardly works anymore
>
> > Well, compile on save doesn't work without it as far as I know.  Which
> is fine, because it saves me from having to disable it on every project 
> anyway! ;-)
>
> Touche! (I would vote to get rid of that feature entirely.)
>
> --emi
>
> On Tue, Feb 25, 2020 at 4:55 PM Neil C Smith  wrote:
> >
> > On Tue, 25 Feb 2020 at 14:47, Emilian Bold  wrote:
> > > Although, my impression is that some features are not implemented
> > > and nb-javac is more or less mandatory for the full Java editing
> > > experience.
> >
> > Well, compile on save doesn't work without it as far as I know.  Which
> > is fine, because it saves me from having to disable it on every
> > project anyway! ;-)
> >
> > Best wishes,
> >
> > Neil
>
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>

-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

RE: Refactor renaming hardly works anymore

[Eirik Bakke]

Wait--why would we get rid of Compile-on-Save? Are you guys building your 
projects on every run? And how would "Apply Code Changes" work in the debugger 
without Compile-on-Save?

-- Eirik

-Original Message-
From: Emilian Bold  
Sent: Tuesday, February 25, 2020 10:04 AM
To: Neil C Smith 
Cc: NetBeans Mailing List ; Geertjan Wielenga 

Subject: Re: Refactor renaming hardly works anymore

> Well, compile on save doesn't work without it as far as I know.  Which
is fine, because it saves me from having to disable it on every project anyway! 
;-)

Touche! (I would vote to get rid of that feature entirely.)

--emi

On Tue, Feb 25, 2020 at 4:55 PM Neil C Smith  wrote:
>
> On Tue, 25 Feb 2020 at 14:47, Emilian Bold  wrote:
> > Although, my impression is that some features are not implemented 
> > and nb-javac is more or less mandatory for the full Java editing 
> > experience.
>
> Well, compile on save doesn't work without it as far as I know.  Which 
> is fine, because it saves me from having to disable it on every 
> project anyway! ;-)
>
> Best wishes,
>
> Neil

-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Geertjan Wielenga]

Without very clear steps and a full description of your environment, no one
can help.

Gj

On Tue, Feb 25, 2020 at 5:31 PM Hans Grimmelshausen HG 
wrote:

> Hello Geertjan and others,
>
> Unfortunately also with NB 11.3 alpha, the same Null pointer exception
> occurs frequently at compile time, with non-installed nb-java plugin.
>
> But I observed the following:
> While the null pointer exception in its stack-trace lists this (which you
> quoted earlier) :
> ->  at
> org.netbeans.lib.nbjavac.services.NBAttr.visitClassDef(NBAttr.java:66)
>
> … and the nb-javac plugin isn't installed (which for many, including me,
> would be located in the user's home, here under Linux it's: .netbeans/11.2/
> ), there's still a hard-wired module inside the netbeans application
> folder, this:
> ->  netbeans/java/modules/org-netbeans-lib-nbjavac.jar
>
> This jar file stays there, even if nb-javac plugin isn't installed (or
> un-installed) in the user's home.
> Could this be the problem?
>
> For now, the situation for my mid-sized OpenJDK 11 project is as follows:
> a) With installed nb-javac plugin:
> No null-pointer exceptions at compile time, but refactoring-rename doesn't
> work.
>
> b) Without the nb-javac plugin:
> Frequent null-pointer exceptions at compile time, however
> refactoring-rename works fine.
>
> Strange. The null pointer exception doesn't block anything, it seems, i.e.
> I can continue to work with the project in NB. But since the exception is
> shown in red an occurs frequently when compiling, it's irritating. Also I
> am at my wits' end. :-)
>
> Greetings,
> Hans
>
>
> Am 25.02.20 um 15:41 schrieb Geertjan Wielenga:
>
> Definitely try 11.3.
>
> And possibly nb-javac is disabled, though still installed.
>
> Gj
>
> On Tue, Feb 25, 2020 at 3:39 PM Hans Grimmelshausen HG 
> wrote:
>
>> Hello Geertjan and other readers,
>>
>> Your observation makes sense, but the strange thing is that I did
>> uninstall nb-javac via NB's menu Tools->Plugins. So it's shown under
>> "Available Plugins".
>> Also I can successfully refactore-rename methods etc in my mid-sized
>> project, which hasn't been working with an installed nb-javac. Like Thomas
>> suggested, disabling nb-javac wasn't enough, it had to be un-installed.
>>
>> I even tried with a fresh NB profile, but the null pointer exceptions
>> keep up coming.
>> This is all very strange to me. Since indeed the nb-javac mention is in
>> the stacktrace.
>> Maybe I should try NB 11.3 ?
>>
>> Thanks.
>>
>> Greetings,
>> Hans
>>
>>
>>
>> Am 25.02.20 um 11:52 schrieb Geertjan Wielenga:
>>
>> Since this is in the stacktrace, nb-javac must still be present, i.e.,
>> has not been uninstalled:
>>
>>  at
>> org.netbeans.lib.nbjavac.services.NBAttr.visitClassDef(NBAttr.java:66)
>>
>> Gj
>>
>> On Tue, Feb 25, 2020 at 11:48 AM Neil C Smith 
>> wrote:
>>
>>> On Tue, 25 Feb 2020 at 10:35, Hans Grimmelshausen (HG) 
>>> wrote:
>>> > Geertjan wrote at
>>> > one point that the nb-javac plugin was mainly useful for JDK 8
>>> projects.
>>>
>>> Mainly useful for running NetBeans itself on JDK 8 as far as I know.
>>> And for supporting versions of JDK above what the IDE is running on.
>>>
>>> Maybe it's time to take the plunge and stop supporting NetBeans on JDK
>>> 8 from 12.1?!
>>>
>>> Best wishes,
>>>
>>> Neil
>>
>>
>
> --
> Via Netbeans-Apache
>
>

Re: Refactor renaming hardly works anymore

[Hans Grimmelshausen HG]

Hello Geertjan and others,

Unfortunately also with NB 11.3 alpha, the same Null pointer exception occurs 
frequently at compile time, with non-installed nb-java plugin.


But I observed the following:
While the null pointer exception in its stack-trace lists this (which you 
quoted earlier) :

->  at org.netbeans.lib.nbjavac.services.NBAttr.visitClassDef(NBAttr.java:66)

… and the nb-javac plugin isn't installed (which for many, including me, 
would be located in the user's home, here under Linux it's: .netbeans/11.2/ 
), there's still a hard-wired module inside the netbeans application folder, 
this:

->  netbeans/java/modules/org-netbeans-lib-nbjavac.jar

This jar file stays there, even if nb-javac plugin isn't installed (or 
un-installed) in the user's home.

Could this be the problem?

For now, the situation for my mid-sized OpenJDK 11 project is as follows:
a) With installed nb-javac plugin:
No null-pointer exceptions at compile time, but refactoring-rename doesn't work.

b) Without the nb-javac plugin:
Frequent null-pointer exceptions at compile time, however refactoring-rename 
works fine.


Strange. The null pointer exception doesn't block anything, it seems, i.e. I 
can continue to work with the project in NB. But since the exception is shown 
in red an occurs frequently when compiling, it's irritating. Also I am at my 
wits' end. :-)


Greetings,
Hans


Am 25.02.20 um 15:41 schrieb Geertjan Wielenga:

Definitely try 11.3.

And possibly nb-javac is disabled, though still installed.

Gj

On Tue, Feb 25, 2020 at 3:39 PM Hans Grimmelshausen HG > wrote:


Hello Geertjan and other readers,

Your observation makes sense, but the strange thing is that I did
uninstall nb-javac via NB's menu Tools->Plugins. So it's shown under
"Available Plugins".
Also I can successfully refactore-rename methods etc in my mid-sized
project, which hasn't been working with an installed nb-javac. Like
Thomas suggested, disabling nb-javac wasn't enough, it had to be
un-installed.

I even tried with a fresh NB profile, but the null pointer exceptions
keep up coming.
This is all very strange to me. Since indeed the nb-javac mention is in
the stacktrace.
Maybe I should try NB 11.3 ?

Thanks.

Greetings,
Hans



Am 25.02.20 um 11:52 schrieb Geertjan Wielenga:

Since this is in the stacktrace, nb-javac must still be present, i.e.,
has not been uninstalled:

     at
org.netbeans.lib.nbjavac.services.NBAttr.visitClassDef(NBAttr.java:66)

Gj

On Tue, Feb 25, 2020 at 11:48 AM Neil C Smith mailto:neilcsm...@apache.org>> wrote:

On Tue, 25 Feb 2020 at 10:35, Hans Grimmelshausen (HG)
mailto:far...@mail.de>> wrote:
> Geertjan wrote at
> one point that the nb-javac plugin was mainly useful for JDK 8
projects.

Mainly useful for running NetBeans itself on JDK 8 as far as I know.
And for supporting versions of JDK above what the IDE is running on.

Maybe it's time to take the plunge and stop supporting NetBeans on JDK
8 from 12.1?!

Best wishes,

Neil




--
Via Netbeans-Apache

Re: Refactor renaming hardly works anymore

[Emilian Bold]

> Well, compile on save doesn't work without it as far as I know.  Which
is fine, because it saves me from having to disable it on every
project anyway! ;-)

Touche! (I would vote to get rid of that feature entirely.)

--emi

On Tue, Feb 25, 2020 at 4:55 PM Neil C Smith  wrote:
>
> On Tue, 25 Feb 2020 at 14:47, Emilian Bold  wrote:
> > Although, my impression is that some features are not implemented and
> > nb-javac is more or less mandatory for the full Java editing
> > experience.
>
> Well, compile on save doesn't work without it as far as I know.  Which
> is fine, because it saves me from having to disable it on every
> project anyway! ;-)
>
> Best wishes,
>
> Neil

-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Neil C Smith]

On Tue, 25 Feb 2020 at 14:47, Emilian Bold  wrote:
> Although, my impression is that some features are not implemented and
> nb-javac is more or less mandatory for the full Java editing
> experience.

Well, compile on save doesn't work without it as far as I know.  Which
is fine, because it saves me from having to disable it on every
project anyway! ;-)

Best wishes,

Neil

-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Emilian Bold]

I haven't followed the whole thread here, but couldn't NetBeans
auto-disable nb-javac if needed?

If nb-javac is only supposed to work for Java 8 runtimes then perhaps
NetBeans should just use it as a fallback?

Although, my impression is that some features are not implemented and
nb-javac is more or less mandatory for the full Java editing
experience.

--emi



On Tue, Feb 25, 2020 at 4:41 PM Geertjan Wielenga  wrote:
>
> Definitely try 11.3.
>
> And possibly nb-javac is disabled, though still installed.
>
> Gj
>
> On Tue, Feb 25, 2020 at 3:39 PM Hans Grimmelshausen HG  wrote:
>>
>> Hello Geertjan and other readers,
>>
>> Your observation makes sense, but the strange thing is that I did uninstall 
>> nb-javac via NB's menu Tools->Plugins. So it's shown under "Available 
>> Plugins".
>> Also I can successfully refactore-rename methods etc in my mid-sized 
>> project, which hasn't been working with an installed nb-javac. Like Thomas 
>> suggested, disabling nb-javac wasn't enough, it had to be un-installed.
>>
>> I even tried with a fresh NB profile, but the null pointer exceptions keep 
>> up coming.
>> This is all very strange to me. Since indeed the nb-javac mention is in the 
>> stacktrace.
>> Maybe I should try NB 11.3 ?
>>
>> Thanks.
>>
>> Greetings,
>> Hans
>>
>>
>>
>> Am 25.02.20 um 11:52 schrieb Geertjan Wielenga:
>>
>> Since this is in the stacktrace, nb-javac must still be present, i.e., has 
>> not been uninstalled:
>>
>>  at 
>> org.netbeans.lib.nbjavac.services.NBAttr.visitClassDef(NBAttr.java:66)
>>
>> Gj
>>
>> On Tue, Feb 25, 2020 at 11:48 AM Neil C Smith  wrote:
>>>
>>> On Tue, 25 Feb 2020 at 10:35, Hans Grimmelshausen (HG)  
>>> wrote:
>>> > Geertjan wrote at
>>> > one point that the nb-javac plugin was mainly useful for JDK 8 projects.
>>>
>>> Mainly useful for running NetBeans itself on JDK 8 as far as I know.
>>> And for supporting versions of JDK above what the IDE is running on.
>>>
>>> Maybe it's time to take the plunge and stop supporting NetBeans on JDK
>>> 8 from 12.1?!
>>>
>>> Best wishes,
>>>
>>> Neil
>>
>>

-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Geertjan Wielenga]

Definitely try 11.3.

And possibly nb-javac is disabled, though still installed.

Gj

On Tue, Feb 25, 2020 at 3:39 PM Hans Grimmelshausen HG 
wrote:

> Hello Geertjan and other readers,
>
> Your observation makes sense, but the strange thing is that I did
> uninstall nb-javac via NB's menu Tools->Plugins. So it's shown under
> "Available Plugins".
> Also I can successfully refactore-rename methods etc in my mid-sized
> project, which hasn't been working with an installed nb-javac. Like Thomas
> suggested, disabling nb-javac wasn't enough, it had to be un-installed.
>
> I even tried with a fresh NB profile, but the null pointer exceptions keep
> up coming.
> This is all very strange to me. Since indeed the nb-javac mention is in
> the stacktrace.
> Maybe I should try NB 11.3 ?
>
> Thanks.
>
> Greetings,
> Hans
>
>
>
> Am 25.02.20 um 11:52 schrieb Geertjan Wielenga:
>
> Since this is in the stacktrace, nb-javac must still be present, i.e., has
> not been uninstalled:
>
>  at
> org.netbeans.lib.nbjavac.services.NBAttr.visitClassDef(NBAttr.java:66)
>
> Gj
>
> On Tue, Feb 25, 2020 at 11:48 AM Neil C Smith 
> wrote:
>
>> On Tue, 25 Feb 2020 at 10:35, Hans Grimmelshausen (HG) 
>> wrote:
>> > Geertjan wrote at
>> > one point that the nb-javac plugin was mainly useful for JDK 8 projects.
>>
>> Mainly useful for running NetBeans itself on JDK 8 as far as I know.
>> And for supporting versions of JDK above what the IDE is running on.
>>
>> Maybe it's time to take the plunge and stop supporting NetBeans on JDK
>> 8 from 12.1?!
>>
>> Best wishes,
>>
>> Neil
>
>
>

Re: Refactor renaming hardly works anymore

[Hans Grimmelshausen HG]

Hello Geertjan and other readers,

Your observation makes sense, but the strange thing is that I did uninstall 
nb-javac via NB's menu Tools->Plugins. So it's shown under "Available Plugins".
Also I can successfully refactore-rename methods etc in my mid-sized project, 
which hasn't been working with an installed nb-javac. Like Thomas suggested, 
disabling nb-javac wasn't enough, it had to be un-installed.


I even tried with a fresh NB profile, but the null pointer exceptions keep up 
coming.
This is all very strange to me. Since indeed the nb-javac mention is in the 
stacktrace.

Maybe I should try NB 11.3 ?

Thanks.

Greetings,
Hans



Am 25.02.20 um 11:52 schrieb Geertjan Wielenga:
Since this is in the stacktrace, nb-javac must still be present, i.e., has 
not been uninstalled:


     at org.netbeans.lib.nbjavac.services.NBAttr.visitClassDef(NBAttr.java:66)

Gj

On Tue, Feb 25, 2020 at 11:48 AM Neil C Smith > wrote:


On Tue, 25 Feb 2020 at 10:35, Hans Grimmelshausen (HG) mailto:far...@mail.de>> wrote:
> Geertjan wrote at
> one point that the nb-javac plugin was mainly useful for JDK 8 projects.

Mainly useful for running NetBeans itself on JDK 8 as far as I know.
And for supporting versions of JDK above what the IDE is running on.

Maybe it's time to take the plunge and stop supporting NetBeans on JDK
8 from 12.1?!

Best wishes,

Neil

Re: Refactor renaming hardly works anymore

[Geertjan Wielenga]

Since this is in the stacktrace, nb-javac must still be present, i.e., has
not been uninstalled:

 at
org.netbeans.lib.nbjavac.services.NBAttr.visitClassDef(NBAttr.java:66)

Gj

On Tue, Feb 25, 2020 at 11:48 AM Neil C Smith  wrote:

> On Tue, 25 Feb 2020 at 10:35, Hans Grimmelshausen (HG) 
> wrote:
> > Geertjan wrote at
> > one point that the nb-javac plugin was mainly useful for JDK 8 projects.
>
> Mainly useful for running NetBeans itself on JDK 8 as far as I know.
> And for supporting versions of JDK above what the IDE is running on.
>
> Maybe it's time to take the plunge and stop supporting NetBeans on JDK
> 8 from 12.1?!
>
> Best wishes,
>
> Neil
>
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>

Re: Refactor renaming hardly works anymore

[Neil C Smith]

On Tue, 25 Feb 2020 at 10:35, Hans Grimmelshausen (HG)  wrote:
> Geertjan wrote at
> one point that the nb-javac plugin was mainly useful for JDK 8 projects.

Mainly useful for running NetBeans itself on JDK 8 as far as I know.
And for supporting versions of JDK above what the IDE is running on.

Maybe it's time to take the plunge and stop supporting NetBeans on JDK
8 from 12.1?!

Best wishes,

Neil

-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Hans Grimmelshausen (HG)]

Hello again Netbeans users,

With great interest I follow this thread (and others), and learned several 
things.
As mentioned by me and others, the de-installation of the nb-javac plugin 
(which NB suggests to install at the beginning and then regularly) repairs 
the refactor-renaming so that it works again. Which is excellent.


My project's source-/binary-format is "JDK 11" by the way. Geertjan wrote at 
one point that the nb-javac plugin was mainly useful for JDK 8 projects.


However now with the uninstalled nb-javac plugin, I regularly experience Null 
pointer exceptions in NB when I edit a java source file and then either 
compile it manually (F9) or run the project (F6), where NB first compiles 
every changed source file (with the gears in its symbol), before it runs the 
project. I attach the stack trace below.


This is with NB 11.2, Openjdk "11.0.6" 2020-01-14 (from Ubuntu 18 LTS), and 
my mid-sized project.


Is there a work-around for this problem, too?
Btw, I disabled my activated C++ plugin from NB 8.3 repository, but this 
doesn't seem to change things.


Greetings,
Hans



---

java.lang.NullPointerException
    at 
jdk.compiler/com.sun.tools.javac.comp.Check.checkClassOverrideEqualsAndHash(Check.java:2095)
    at 
jdk.compiler/com.sun.tools.javac.comp.Check.checkClassOverrideEqualsAndHashIfNeeded(Check.java:2085)

    at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4577)
    at jdk.compiler/com.sun.tools.javac.comp.Attr.attribClass(Attr.java:4503)
    at jdk.compiler/com.sun.tools.javac.comp.Attr.visitClassDef(Attr.java:951)
    at org.netbeans.lib.nbjavac.services.NBAttr.visitClassDef(NBAttr.java:66)
    at 
jdk.compiler/com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:774)

    at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655)
    at jdk.compiler/com.sun.tools.javac.comp.Attr.attribStat(Attr.java:724)
    at 
jdk.compiler/com.sun.tools.javac.comp.Attr.visitAnonymousClassDefinition(Attr.java:2397)

    at jdk.compiler/com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:2288)
    at 
jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1689)

    at jdk.compiler/com.sun.tools.javac.comp.Attr.attribTree(Attr.java:655)
    at jdk.compiler/com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:695)
    at 
org.netbeans.modules.java.hints.spiimpl.Utilities.attributeTree(Utilities.java:655)
    at 
org.netbeans.modules.java.hints.spiimpl.Utilities.parseAndAttribute(Utilities.java:435)
    at 
org.netbeans.modules.java.hints.spiimpl.Utilities.parseAndAttribute(Utilities.java:349)
    at 
org.netbeans.modules.java.hints.spiimpl.Utilities.parseAndAttribute(Utilities.java:329)
    at 
org.netbeans.modules.java.hints.spiimpl.Utilities.parseAndAttribute(Utilities.java:325)
    at 
org.netbeans.modules.java.hints.spiimpl.pm.PatternCompiler.compile(PatternCompiler.java:44)
    at 
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.doComputeHints(HintsInvoker.java:535)
    at 
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHintsImpl(HintsInvoker.java:283)
    at 
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints(HintsInvoker.java:228)
    at 
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints(HintsInvoker.java:193)
    at 
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints(HintsInvoker.java:166)
    at 
org.netbeans.modules.java.hints.spiimpl.hints.HintsInvoker.computeHints(HintsInvoker.java:128)
    at 
org.netbeans.modules.java.hints.spiimpl.hints.HintsTask.run(HintsTask.java:114)
    at 
org.netbeans.modules.java.hints.spiimpl.hints.HintsTask.run(HintsTask.java:65)
[catch] at 
org.netbeans.modules.java.source.JavaSourceAccessor$CancelableTaskWrapper.run(JavaSourceAccessor.java:273)
    at 
org.netbeans.modules.parsing.impl.TaskProcessor.callParserResultTask(TaskProcessor.java:561)
    at 
org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.run(TaskProcessor.java:786)

    at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279)
    at 
org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.execute(TaskProcessor.java:702)
    at 
org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProcessor.java:663)
    at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)

    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
    at 
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)

    at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
    at 
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)


---



Am 17.02.20 um 11:47 schrieb Thomas Kellerer:

Hans 

Re: Refactor renaming hardly works anymore

[Laszlo Kishalmi]

That's fixed in 11.3

On 2/24/20 4:45 PM, Ty Young wrote:




If anyone's interested, here's another bug:


https://pastebin.com/g0eLXnFy


On 2/18/20 3:34 PM, Jan Lahoda wrote:

Thanks! I can reproduce, will take a look on how to fix this!

Jan

On Tue, Feb 18, 2020 at 10:21 AM Ty Young > wrote:




I know some things that changed (like adding the support for JDK
9, or the ability to use the JDK's javac instead of nb-javac).
But it is hard to say what is the issue without actually being
able to reproduce the issue. I am definitely willing to look at
problems with (Java) refactoring, but I need to be able to
reproduce them. I tried a simple testcase with renaming an
interface method, and it worked - so apparently I didn't trigger
the problematic part. Might be related to the JDK 9 module
support (although I tried both with and without module-info), or
to something else, but having a case where one can see what is
going on makes chances for a fix much higher.

Jan



It seems to work OK on newly created projects but once you start
actually getting into the thick of things it breaks. I suppose
the only way to track down any of the issues is by using an
existing project.


Sadly for my project(s) you'll need a Panama JDK compiled the
from the source code here(at least to compile):


https://github.com/openjdk/panama-foreign


My project can be found here:


https://github.com/BlueGoliath/Crosspoint


Oddly enough I can't, for whatever reason, get the interface
refractoring bug to happen again but I can get a NullPointer
Exception when moving MemoryObject interface to the enums package:


Module Java Refactoring threw java.lang.NullPointerException.
Please report a bug against Java Refactoring module and attach
your var/log/messages.log.


Detail stacktrace:


java.lang.NullPointerException
    at

org.netbeans.api.java.source.ElementUtilities.enclosingTypeElementImpl(ElementUtilities.java:140)
    at

org.netbeans.api.java.source.ElementUtilities.enclosingTypeElement(ElementUtilities.java:129)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitMemberSelect(MoveTransformer.java:126)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitMemberSelect(MoveTransformer.java:47)
    at
com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2231)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:76)
    at
com.sun.source.util.TreeScanner.visitRequires(TreeScanner.java:906)
    at
com.sun.tools.javac.tree.JCTree$JCRequires.accept(JCTree.java:2966)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:76)
    at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
    at
com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:114)
    at
com.sun.source.util.TreeScanner.visitModule(TreeScanner.java:879)
    at
com.sun.tools.javac.tree.JCTree$JCModuleDecl.accept(JCTree.java:2815)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:76)
    at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
    at
com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:114)
    at
com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:145)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitCompilationUnit(MoveTransformer.java:320)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitCompilationUnit(MoveTransformer.java:47)
    at
com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:603)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin$TransformTask.run(JavaRefactoringPlugin.java:443)
    at

org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin$TransformTask.run(JavaRefactoringPlugin.java:408)
    at

Re: Refactor renaming hardly works anymore

[Ty Young]

If anyone's interested, here's another bug:


https://pastebin.com/g0eLXnFy


On 2/18/20 3:34 PM, Jan Lahoda wrote:

Thanks! I can reproduce, will take a look on how to fix this!

Jan

On Tue, Feb 18, 2020 at 10:21 AM Ty Young > wrote:




I know some things that changed (like adding the support for JDK
9, or the ability to use the JDK's javac instead of nb-javac).
But it is hard to say what is the issue without actually being
able to reproduce the issue. I am definitely willing to look at
problems with (Java) refactoring, but I need to be able to
reproduce them. I tried a simple testcase with renaming an
interface method, and it worked - so apparently I didn't trigger
the problematic part. Might be related to the JDK 9 module
support (although I tried both with and without module-info), or
to something else, but having a case where one can see what is
going on makes chances for a fix much higher.

Jan



It seems to work OK on newly created projects but once you start
actually getting into the thick of things it breaks. I suppose the
only way to track down any of the issues is by using an existing
project.


Sadly for my project(s) you'll need a Panama JDK compiled the from
the source code here(at least to compile):


https://github.com/openjdk/panama-foreign


My project can be found here:


https://github.com/BlueGoliath/Crosspoint


Oddly enough I can't, for whatever reason, get the interface
refractoring bug to happen again but I can get a NullPointer
Exception when moving MemoryObject interface to the enums package:


Module Java Refactoring threw java.lang.NullPointerException.
Please report a bug against Java Refactoring module and attach
your var/log/messages.log.


Detail stacktrace:


java.lang.NullPointerException
    at

org.netbeans.api.java.source.ElementUtilities.enclosingTypeElementImpl(ElementUtilities.java:140)
    at

org.netbeans.api.java.source.ElementUtilities.enclosingTypeElement(ElementUtilities.java:129)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitMemberSelect(MoveTransformer.java:126)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitMemberSelect(MoveTransformer.java:47)
    at
com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:2231)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:76)
    at
com.sun.source.util.TreeScanner.visitRequires(TreeScanner.java:906)
    at
com.sun.tools.javac.tree.JCTree$JCRequires.accept(JCTree.java:2966)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:76)
    at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
    at
com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:114)
    at
com.sun.source.util.TreeScanner.visitModule(TreeScanner.java:879)
    at
com.sun.tools.javac.tree.JCTree$JCModuleDecl.accept(JCTree.java:2815)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:76)
    at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
    at
com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:114)
    at
com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:145)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitCompilationUnit(MoveTransformer.java:320)
    at

org.netbeans.modules.refactoring.java.plugins.MoveTransformer.visitCompilationUnit(MoveTransformer.java:47)
    at
com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:603)
    at
com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at

org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.scan(RefactoringVisitor.java:192)
    at

org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin$TransformTask.run(JavaRefactoringPlugin.java:443)
    at

org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin$TransformTask.run(JavaRefactoringPlugin.java:408)
    at
org.netbeans.api.java.source.JavaSource$1.run(JavaSource.java:673)
    at

Re: Refactor renaming hardly works anymore

[Martin Desruisseaux]

Le 18/02/2020 à 11:25, Geertjan Wielenga a écrit :

Best to also check whether the problem can be reproduced with nb-javac 
uninstalled.


Yes my plan is to try with a fresh install and answer "no" to the 
question suggesting to install nb-javac.


    Martin



-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Geertjan Wielenga]

Best to also check whether the problem can be reproduced with nb-javac
uninstalled, i.e., let’s see if we can all isolate the problem to nb-javac
and at the same time try our best to work without nb-javac, since ideally
in the end, assuming we’re running NetBeans on a JDK later than JDK 8,
we’ll not be needing it.

Gj

On Tue, 18 Feb 2020 at 09:28, Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Hello Jan
>
> Le 18/02/2020 à 08:30, Jan Lahoda a écrit :
>
> > I know some things that changed (like adding the support for JDK 9, or
> > the ability to use the JDK's javac instead of nb-javac). But it is
> > hard to say what is the issue without actually being able to reproduce
> > the issue. I am definitely willing to look at problems with (Java)
> > refactoring, but I need to be able to reproduce them. I tried a simple
> > testcase with renaming an interface method, and it worked - so
> > apparently I didn't trigger the problematic part. Might be related to
> > the JDK 9 module support (although I tried both with and without
> > module-info), or to something else, but having a case where one can
> > see what is going on makes chances for a fix much higher.
> >
> Thanks for looking. In my case the failures are systematic: since
> NetBeans 11.2 refactoring and "search usage" never succeed, unless the
> class is not used anywhere. However I have not yet verified if it
> happens on another machine than mine. The problem occurs with the Apache
> SIS project, which has a particularity: it is a Maven project but
> provides also the NetBeans Ant project files. The Maven build is the
> official one, but I open the project as a NetBeans Ant project in the
> IDE for daily development (I find NetBeans Ant projects more efficient
> than Maven projects - faster to build and launch, more customizable,
> better at providing a global view of all modules. There is no conflict
> as long as I never open the project as a Maven project in NetBeans).
>
> But to avoid wasting your time, I should check if the issue is still
> present in NetBeans 11.3 first, and if yes if it occurs also on other
> machines. In the meantime I have a workaround for not being able to
> search usages: I change the name of the method and I check which classes
> got the red icon in the project tab.
>
>  Martin
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>

Re: Refactor renaming hardly works anymore

[Martin Desruisseaux]

Hello Jan

Le 18/02/2020 à 08:30, Jan Lahoda a écrit :

I know some things that changed (like adding the support for JDK 9, or 
the ability to use the JDK's javac instead of nb-javac). But it is 
hard to say what is the issue without actually being able to reproduce 
the issue. I am definitely willing to look at problems with (Java) 
refactoring, but I need to be able to reproduce them. I tried a simple 
testcase with renaming an interface method, and it worked - so 
apparently I didn't trigger the problematic part. Might be related to 
the JDK 9 module support (although I tried both with and without 
module-info), or to something else, but having a case where one can 
see what is going on makes chances for a fix much higher.


Thanks for looking. In my case the failures are systematic: since 
NetBeans 11.2 refactoring and "search usage" never succeed, unless the 
class is not used anywhere. However I have not yet verified if it 
happens on another machine than mine. The problem occurs with the Apache 
SIS project, which has a particularity: it is a Maven project but 
provides also the NetBeans Ant project files. The Maven build is the 
official one, but I open the project as a NetBeans Ant project in the 
IDE for daily development (I find NetBeans Ant projects more efficient 
than Maven projects - faster to build and launch, more customizable, 
better at providing a global view of all modules. There is no conflict 
as long as I never open the project as a Maven project in NetBeans).


But to avoid wasting your time, I should check if the issue is still 
present in NetBeans 11.3 first, and if yes if it occurs also on other 
machines. In the meantime I have a workaround for not being able to 
search usages: I change the name of the method and I check which classes 
got the red icon in the project tab.


    Martin



-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Eduard]

As far back as in NB8 did I on rare occasions get weird results on 
refactor/renaming. I never had the time to disrupt what i was working on 
and to drill down what actually triggered this. I don't recall how I 
worked around that, though.


In almost all cases does it work as expected.

Maybe, as a first step, a special refactoring-bug reporting menu item 
could be created with which one could submit a file that failed.


Cheers
Eduard

Jan Lahoda wrote on 18/02/2020 08:30:
On Mon, Feb 17, 2020 at 2:58 PM Ty Young > wrote:


On 2/17/20 7:32 AM, Geertjan Wielenga wrote:

Indeed, Oracle is contributing constantly to NetBeans. Easy to
prove, look at the GitHub repo, at the list of contributors. Is
your name there? Mine is.



Bit odd then that no one is using an Oracle email address. I
suppose it's a requirement to use a different Apache email
address? The more you know, I guess.


But uh... Sorry, I'll have to pass on signing away my first born
child or whatever is within Apache's version legal document. I'm
not a lawyer. Didn't understand Oracle's legal waiver when I
attempted to submit a one-liner fix to JavaFX and I doubt Apache
is any different.


(/joke)


But I digress, does anyone who originally worked on Netbeans still
contribute? Does anyone know what changed from Netbeans 8 to
Netbeans 9 that kickstarted the borked refractoring avalanche?


I know some things that changed (like adding the support for JDK 9, or 
the ability to use the JDK's javac instead of nb-javac). But it is 
hard to say what is the issue without actually being able to reproduce 
the issue. I am definitely willing to look at problems with (Java) 
refactoring, but I need to be able to reproduce them. I tried a simple 
testcase with renaming an interface method, and it worked - so 
apparently I didn't trigger the problematic part. Might be related to 
the JDK 9 module support (although I tried both with and without 
module-info), or to something else, but having a case where one can 
see what is going on makes chances for a fix much higher.


Jan



I am from Oracle. In the top 10 contributors, half the names are
from Oracle.

Gj

On Mon, 17 Feb 2020 at 14:03, Ty Young mailto:youngty1...@gmail.com>> wrote:


On 2/17/20 6:59 AM, Ty Young wrote:
>
> On 2/17/20 4:41 AM, Hans Grimmselshausen wrote:
>> Good day Netbeans users,
>>
> snip
>
>
>> Do you fellow Netbeans users know of problems with the
refactoring
>> module?
>>
>
> Various code refactoring bugs have existed since before Oracle
> "donated" Netbeans to Apache(AKA Netbeans 9 alpha). Some
seem to be
> java 9 specific, or dependant on whether or not nb-javac is
> installed(as others have said) or how your project is
setup. I'm
> currently hitting a refactoring bug where renaming an
interface method
> will rename all implementation method names but not the
interface
> method name itself. It's borked to high hell.


Java 9 modules specific*


>
>
> Presumably the original Oracle developers would know how to
fix all of
> it but - despite actively using Netbeans internally as
admitted by an
> actual Oracle developer - Oracle doesn't seem to even be
contributing
> to Netbeans at all. At least no one seems to interact on
this list...

-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org

For additional commands, e-mail:
users-h...@netbeans.apache.org


For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Jan Lahoda]

On Mon, Feb 17, 2020 at 2:58 PM Ty Young  wrote:

> On 2/17/20 7:32 AM, Geertjan Wielenga wrote:
>
> Indeed, Oracle is contributing constantly to NetBeans. Easy to prove, look
> at the GitHub repo, at the list of contributors. Is your name there? Mine
> is.
>
>
> Bit odd then that no one is using an Oracle email address. I suppose it's
> a requirement to use a different Apache email address? The more you know, I
> guess.
>
>
> But uh... Sorry, I'll have to pass on signing away my first born child or
> whatever is within Apache's version legal document. I'm not a lawyer.
> Didn't understand Oracle's legal waiver when I attempted to submit a
> one-liner fix to JavaFX and I doubt Apache is any different.
>
>
> (/joke)
>
>
> But I digress, does anyone who originally worked on Netbeans still
> contribute? Does anyone know what changed from Netbeans 8 to Netbeans 9
> that kickstarted the borked refractoring avalanche?
>

I know some things that changed (like adding the support for JDK 9, or the
ability to use the JDK's javac instead of nb-javac). But it is hard to say
what is the issue without actually being able to reproduce the issue. I am
definitely willing to look at problems with (Java) refactoring, but I need
to be able to reproduce them. I tried a simple testcase with renaming an
interface method, and it worked - so apparently I didn't trigger the
problematic part. Might be related to the JDK 9 module support (although I
tried both with and without module-info), or to something else, but having
a case where one can see what is going on makes chances for a fix much
higher.

Jan


>
> I am from Oracle. In the top 10 contributors, half the names are from
> Oracle.
>
> Gj
>
> On Mon, 17 Feb 2020 at 14:03, Ty Young  wrote:
>
>>
>> On 2/17/20 6:59 AM, Ty Young wrote:
>> >
>> > On 2/17/20 4:41 AM, Hans Grimmselshausen wrote:
>> >> Good day Netbeans users,
>> >>
>> > snip
>> >
>> >
>> >> Do you fellow Netbeans users know of problems with the refactoring
>> >> module?
>> >>
>> >
>> > Various code refactoring bugs have existed since before Oracle
>> > "donated" Netbeans to Apache(AKA Netbeans 9 alpha). Some seem to be
>> > java 9 specific, or dependant on whether or not nb-javac is
>> > installed(as others have said) or how your project is setup. I'm
>> > currently hitting a refactoring bug where renaming an interface method
>> > will rename all implementation method names but not the interface
>> > method name itself. It's borked to high hell.
>>
>>
>> Java 9 modules specific*
>>
>>
>> >
>> >
>> > Presumably the original Oracle developers would know how to fix all of
>> > it but - despite actively using Netbeans internally as admitted by an
>> > actual Oracle developer - Oracle doesn't seem to even be contributing
>> > to Netbeans at all. At least no one seems to interact on this list...
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
>> For additional commands, e-mail: users-h...@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>

Re: Refactor renaming hardly works anymore

[Geertjan Wielenga]

Best to not use nb-javac anyway. Ultimately we’ll move away from it. Though
make sure to run on a JDK later than JDK 8.

Gj

On Mon, 17 Feb 2020 at 17:39, Thomas Kellerer  wrote:

> Still happens to me with beta3 (unless I uninstall nb-javac)
>
> Laszlo Kishalmi schrieb am 17.02.2020 um 18:37:
> > I'd recommend to test 11.3-beta3, there were a lot of improvements
> around refactoring. I myself fixed 2 bugs during the beta cycle.
> >
> > On 2/17/20 5:56 AM, Martin Desruisseaux wrote:
> >> Hello Hans
> >>
> >> Le 17/02/2020 à 13:56, Hans Grimmelshausen a écrit :
> >>
> >>> Have you tried Thomas' excellent work-around for the problem? He wrote:
> >>>
> >> Not yet. My plan was to try with NetBeans 11.3. Of course I should try
> the beta first so issues can be filled. But trying beta versions depend on
> whether it happens at a time we are in a work rush or not.
> >>
> >> Anyway, having confirmation that I'm not alone, I will try to
> investigate more when I have a chance if the issue is still present in
> NetBeans 11.3.
> >>
> >> Thanks,
> >>
> >> Martin
>
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>

Re: Refactor renaming hardly works anymore

[Thomas Kellerer]

Still happens to me with beta3 (unless I uninstall nb-javac)

Laszlo Kishalmi schrieb am 17.02.2020 um 18:37:

I'd recommend to test 11.3-beta3, there were a lot of improvements around 
refactoring. I myself fixed 2 bugs during the beta cycle.

On 2/17/20 5:56 AM, Martin Desruisseaux wrote:

Hello Hans

Le 17/02/2020 à 13:56, Hans Grimmelshausen a écrit :


Have you tried Thomas' excellent work-around for the problem? He wrote:


Not yet. My plan was to try with NetBeans 11.3. Of course I should try the beta 
first so issues can be filled. But trying beta versions depend on whether it 
happens at a time we are in a work rush or not.

Anyway, having confirmation that I'm not alone, I will try to investigate more 
when I have a chance if the issue is still present in NetBeans 11.3.

    Thanks,

        Martin


-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Laszlo Kishalmi]

I'd recommend to test 11.3-beta3, there were a lot of improvements 
around refactoring. I myself fixed 2 bugs during the beta cycle.


On 2/17/20 5:56 AM, Martin Desruisseaux wrote:

Hello Hans

Le 17/02/2020 à 13:56, Hans Grimmelshausen a écrit :


Have you tried Thomas' excellent work-around for the problem? He wrote:

Not yet. My plan was to try with NetBeans 11.3. Of course I should try 
the beta first so issues can be filled. But trying beta versions 
depend on whether it happens at a time we are in a work rush or not.


Anyway, having confirmation that I'm not alone, I will try to 
investigate more when I have a chance if the issue is still present in 
NetBeans 11.3.


    Thanks,

        Martin



-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Geertjan Wielenga]

I’m sorry, I don’t know where to begin responding to your points and
questions.

Can you start by getting a very basic understanding of the Apache Software
Foundation, what it is, and how it works, here:

apache.org

Thanks,

Gj

On Mon, 17 Feb 2020 at 14:58, Ty Young  wrote:

> On 2/17/20 7:32 AM, Geertjan Wielenga wrote:
>
> Indeed, Oracle is contributing constantly to NetBeans. Easy to prove, look
> at the GitHub repo, at the list of contributors. Is your name there? Mine
> is.
>
>
> Bit odd then that no one is using an Oracle email address. I suppose it's
> a requirement to use a different Apache email address? The more you know, I
> guess.
>
>
> But uh... Sorry, I'll have to pass on signing away my first born child or
> whatever is within Apache's version legal document. I'm not a lawyer.
> Didn't understand Oracle's legal waiver when I attempted to submit a
> one-liner fix to JavaFX and I doubt Apache is any different.
>
>
> (/joke)
>
>
> But I digress, does anyone who originally worked on Netbeans still
> contribute? Does anyone know what changed from Netbeans 8 to Netbeans 9
> that kickstarted the borked refractoring avalanche?
>
>
> I am from Oracle. In the top 10 contributors, half the names are from
> Oracle.
>
> Gj
>
> On Mon, 17 Feb 2020 at 14:03, Ty Young  wrote:
>
>>
>> On 2/17/20 6:59 AM, Ty Young wrote:
>> >
>> > On 2/17/20 4:41 AM, Hans Grimmselshausen wrote:
>> >> Good day Netbeans users,
>> >>
>> > snip
>> >
>> >
>> >> Do you fellow Netbeans users know of problems with the refactoring
>> >> module?
>> >>
>> >
>> > Various code refactoring bugs have existed since before Oracle
>> > "donated" Netbeans to Apache(AKA Netbeans 9 alpha). Some seem to be
>> > java 9 specific, or dependant on whether or not nb-javac is
>> > installed(as others have said) or how your project is setup. I'm
>> > currently hitting a refactoring bug where renaming an interface method
>> > will rename all implementation method names but not the interface
>> > method name itself. It's borked to high hell.
>>
>>
>> Java 9 modules specific*
>>
>>
>> >
>> >
>> > Presumably the original Oracle developers would know how to fix all of
>> > it but - despite actively using Netbeans internally as admitted by an
>> > actual Oracle developer - Oracle doesn't seem to even be contributing
>> > to Netbeans at all. At least no one seems to interact on this list...
>
>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
>> For additional commands, e-mail: users-h...@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>

Re: Refactor renaming hardly works anymore

[Ty Young]

On 2/17/20 7:32 AM, Geertjan Wielenga wrote:
Indeed, Oracle is contributing constantly to NetBeans. Easy to prove, 
look at the GitHub repo, at the list of contributors. Is your name 
there? Mine is.



Bit odd then that no one is using an Oracle email address. I suppose 
it's a requirement to use a different Apache email address? The more you 
know, I guess.



But uh... Sorry, I'll have to pass on signing away my first born child 
or whatever is within Apache's version legal document. I'm not a lawyer. 
Didn't understand Oracle's legal waiver when I attempted to submit a 
one-liner fix to JavaFX and I doubt Apache is any different.



(/joke)


But I digress, does anyone who originally worked on Netbeans still 
contribute? Does anyone know what changed from Netbeans 8 to Netbeans 9 
that kickstarted the borked refractoring avalanche?



I am from Oracle. In the top 10 contributors, half the names are from 
Oracle.


Gj

On Mon, 17 Feb 2020 at 14:03, Ty Young > wrote:



On 2/17/20 6:59 AM, Ty Young wrote:
>
> On 2/17/20 4:41 AM, Hans Grimmselshausen wrote:
>> Good day Netbeans users,
>>
> snip
>
>
>> Do you fellow Netbeans users know of problems with the refactoring
>> module?
>>
>
> Various code refactoring bugs have existed since before Oracle
> "donated" Netbeans to Apache(AKA Netbeans 9 alpha). Some seem to be
> java 9 specific, or dependant on whether or not nb-javac is
> installed(as others have said) or how your project is setup. I'm
> currently hitting a refactoring bug where renaming an interface
method
> will rename all implementation method names but not the interface
> method name itself. It's borked to high hell.


Java 9 modules specific*


>
>
> Presumably the original Oracle developers would know how to fix
all of
> it but - despite actively using Netbeans internally as admitted
by an
> actual Oracle developer - Oracle doesn't seem to even be
contributing
> to Netbeans at all. At least no one seems to interact on this
list...

-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org

For additional commands, e-mail: users-h...@netbeans.apache.org


For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Martin Desruisseaux]

Hello Hans

Le 17/02/2020 à 13:56, Hans Grimmelshausen a écrit :


Have you tried Thomas' excellent work-around for the problem? He wrote:

Not yet. My plan was to try with NetBeans 11.3. Of course I should try 
the beta first so issues can be filled. But trying beta versions depend 
on whether it happens at a time we are in a work rush or not.


Anyway, having confirmation that I'm not alone, I will try to 
investigate more when I have a chance if the issue is still present in 
NetBeans 11.3.


    Thanks,

        Martin



-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Geertjan Wielenga]

Indeed, Oracle is contributing constantly to NetBeans. Easy to prove, look
at the GitHub repo, at the list of contributors. Is your name there? Mine
is. I am from Oracle. In the top 10 contributors, half the names are from
Oracle.

Gj

On Mon, 17 Feb 2020 at 14:03, Ty Young  wrote:

>
> On 2/17/20 6:59 AM, Ty Young wrote:
> >
> > On 2/17/20 4:41 AM, Hans Grimmselshausen wrote:
> >> Good day Netbeans users,
> >>
> > snip
> >
> >
> >> Do you fellow Netbeans users know of problems with the refactoring
> >> module?
> >>
> >
> > Various code refactoring bugs have existed since before Oracle
> > "donated" Netbeans to Apache(AKA Netbeans 9 alpha). Some seem to be
> > java 9 specific, or dependant on whether or not nb-javac is
> > installed(as others have said) or how your project is setup. I'm
> > currently hitting a refactoring bug where renaming an interface method
> > will rename all implementation method names but not the interface
> > method name itself. It's borked to high hell.
>
>
> Java 9 modules specific*
>
>
> >
> >
> > Presumably the original Oracle developers would know how to fix all of
> > it but - despite actively using Netbeans internally as admitted by an
> > actual Oracle developer - Oracle doesn't seem to even be contributing
> > to Netbeans at all. At least no one seems to interact on this list...
>
> -
> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
> For additional commands, e-mail: users-h...@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>

Re: Refactor renaming hardly works anymore

[Ty Young]

On 2/17/20 6:59 AM, Ty Young wrote:


On 2/17/20 4:41 AM, Hans Grimmselshausen wrote:

Good day Netbeans users,


snip


Do you fellow Netbeans users know of problems with the refactoring 
module?




Various code refactoring bugs have existed since before Oracle 
"donated" Netbeans to Apache(AKA Netbeans 9 alpha). Some seem to be 
java 9 specific, or dependant on whether or not nb-javac is 
installed(as others have said) or how your project is setup. I'm 
currently hitting a refactoring bug where renaming an interface method 
will rename all implementation method names but not the interface 
method name itself. It's borked to high hell.



Java 9 modules specific*





Presumably the original Oracle developers would know how to fix all of 
it but - despite actively using Netbeans internally as admitted by an 
actual Oracle developer - Oracle doesn't seem to even be contributing 
to Netbeans at all. At least no one seems to interact on this list...


-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Ty Young]

On 2/17/20 4:41 AM, Hans Grimmselshausen wrote:

Good day Netbeans users,


snip


Do you fellow Netbeans users know of problems with the refactoring 
module?




Various code refactoring bugs have existed since before Oracle "donated" 
Netbeans to Apache(AKA Netbeans 9 alpha). Some seem to be java 9 
specific, or dependant on whether or not nb-javac is installed(as others 
have said) or how your project is setup. I'm currently hitting a 
refactoring bug where renaming an interface method will rename all 
implementation method names but not the interface method name itself. 
It's borked to high hell.



Presumably the original Oracle developers would know how to fix all of 
it but - despite actively using Netbeans internally as admitted by an 
actual Oracle developer - Oracle doesn't seem to even be contributing to 
Netbeans at all. At least no one seems to interact on this list...


-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Hans Grimmelshausen]

Hello Martin,

Thanks for the confirmation. Here too, sometimes the refactor-renaming works, 
but mostly it doesn't. And I too assumed it was "just" some problem specific 
to my configuration...


Have you tried Thomas' excellent work-around for the problem? He wrote:


You need to uninstall the nb-javac library, then refactoring works again.
I still get it with 11.3-beta3 as long as nb-javac is installed
Note that just disabling nb-javac is not enough.


Adieu,
Hans



Am 17.02.20 um 12:16 schrieb Martin Desruisseaux:


Hello Hans

Le 17/02/2020 à 11:41, Hans Grimmselshausen a écrit :

With Netbeans 11.2 (but also with 11.0) running in OpenJDK 11.0.6 on 
Ubuntu 18 LTS, for some time I experience a lot of problems when I try to 
refactor-rename public variables and functions in my mid-sized project. 
Mostly but not always, I then get the following error:


Module Java Refactoring threw java.util.ConcurrentModificationException.

(…snip…)

Refactoring in an Ant project is also broken for me since NetBeans 11.2 
running on OpenJDK 13.0.1. Or actually it works only if the class is not 
yet used by any other class. The "Search usage" action seems to suffer from 
the same problem. I assumed it was some problem specific to my 
configuration so I didn't took the time to investigate yet. It my case, the 
exception I got is an AssertionError:


Caused: java.lang.AssertionError
at com.sun.tools.javac.util.Assert.error(Assert.java:155)
at com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
at 
com.sun.tools.javac.comp.Modules.setCompilationUnitModules(Modules.java:559)
at com.sun.tools.javac.comp.Modules.enter(Modules.java:287)
at com.sun.tools.javac.comp.Modules.enter(Modules.java:268)
at com.sun.tools.javac.comp.Modules.initModules(Modules.java:259)
at 
com.sun.tools.javac.main.JavaCompiler.initModules(JavaCompiler.java:1126)
at com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:393)
at com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:327)
at 
org.netbeans.modules.java.source.parsing.JavacParser.moveToPhase(JavacParser.java:660)
at 
org.netbeans.modules.java.source.parsing.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:361)
at 
org.netbeans.api.java.source.CompilationController.toPhase(CompilationController.java:84)
at 
org.netbeans.api.java.source.WorkingCopy.toPhase(WorkingCopy.java:193)
at 
org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.setWorkingCopy(RefactoringVisitor.java:110)
at 
org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin$TransformTask.run(JavaRefactoringPlugin.java:425)
at 
org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin$TransformTask.run(JavaRefactoringPlugin.java:408)
at org.netbeans.api.java.source.JavaSource$1.run(JavaSource.java:673)
at org.netbeans.api.java.source.JavaSource$1.run(JavaSource.java:663)
at 
org.netbeans.api.java.source.JavaSource$MultiTask.run(JavaSource.java:502)
at 
org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586)
at 
org.netbeans.modules.parsing.api.ParserManager$MultiUserTaskAction.run(ParserManager.java:166)
at 
org.netbeans.modules.parsing.api.ParserManager$MultiUserTaskAction.run(ParserManager.java:138)
at 
org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181)
at 
org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178)
at 
org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
at 
org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
at 
org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
at 
org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
at 
org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178)
at 
org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:83)
at 
org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:452)
at 
org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:423)
at 
org.netbeans.api.java.source.JavaSource.runModificationTask(JavaSource.java:684)
at 
org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.processFiles(JavaRefactoringPlugin.java:317)
at 
org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.processFiles(JavaRefactoringPlugin.java:263)
at 
org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.processFiles(JavaRefactoringPlugin.java:245)
at 
org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.createAndAddElements(JavaRefactoringPlugin.java:326)
at 

Re: Refactor renaming hardly works anymore

[Martin Desruisseaux]

Hello Hans

Le 17/02/2020 à 11:41, Hans Grimmselshausen a écrit :

With Netbeans 11.2 (but also with 11.0) running in OpenJDK 11.0.6 on 
Ubuntu 18 LTS, for some time I experience a lot of problems when I try 
to refactor-rename public variables and functions in my mid-sized 
project. Mostly but not always, I then get the following error:


Module Java Refactoring threw java.util.ConcurrentModificationException.

(…snip…)

Refactoring in an Ant project is also broken for me since NetBeans 11.2 
running on OpenJDK 13.0.1. Or actually it works only if the class is not 
yet used by any other class. The "Search usage" action seems to suffer 
from the same problem. I assumed it was some problem specific to my 
configuration so I didn't took the time to investigate yet. It my case, 
the exception I got is an AssertionError:


Caused: java.lang.AssertionError
at com.sun.tools.javac.util.Assert.error(Assert.java:155)
at com.sun.tools.javac.util.Assert.checkNonNull(Assert.java:62)
at 
com.sun.tools.javac.comp.Modules.setCompilationUnitModules(Modules.java:559)
at com.sun.tools.javac.comp.Modules.enter(Modules.java:287)
at com.sun.tools.javac.comp.Modules.enter(Modules.java:268)
at com.sun.tools.javac.comp.Modules.initModules(Modules.java:259)
at 
com.sun.tools.javac.main.JavaCompiler.initModules(JavaCompiler.java:1126)
at com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:393)
at com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:327)
at 
org.netbeans.modules.java.source.parsing.JavacParser.moveToPhase(JavacParser.java:660)
at 
org.netbeans.modules.java.source.parsing.CompilationInfoImpl.toPhase(CompilationInfoImpl.java:361)
at 
org.netbeans.api.java.source.CompilationController.toPhase(CompilationController.java:84)
at 
org.netbeans.api.java.source.WorkingCopy.toPhase(WorkingCopy.java:193)
at 
org.netbeans.modules.refactoring.java.spi.RefactoringVisitor.setWorkingCopy(RefactoringVisitor.java:110)
at 
org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin$TransformTask.run(JavaRefactoringPlugin.java:425)
at 
org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin$TransformTask.run(JavaRefactoringPlugin.java:408)
at org.netbeans.api.java.source.JavaSource$1.run(JavaSource.java:673)
at org.netbeans.api.java.source.JavaSource$1.run(JavaSource.java:663)
at 
org.netbeans.api.java.source.JavaSource$MultiTask.run(JavaSource.java:502)
at 
org.netbeans.modules.parsing.impl.TaskProcessor.callUserTask(TaskProcessor.java:586)
at 
org.netbeans.modules.parsing.api.ParserManager$MultiUserTaskAction.run(ParserManager.java:166)
at 
org.netbeans.modules.parsing.api.ParserManager$MultiUserTaskAction.run(ParserManager.java:138)
at 
org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:181)
at 
org.netbeans.modules.parsing.impl.TaskProcessor$2.call(TaskProcessor.java:178)
at 
org.netbeans.modules.masterfs.filebasedfs.utils.FileChangedManager.priorityIO(FileChangedManager.java:153)
at 
org.netbeans.modules.masterfs.providers.ProvidedExtensions.priorityIO(ProvidedExtensions.java:335)
at 
org.netbeans.modules.parsing.nb.DataObjectEnvFactory.runPriorityIO(DataObjectEnvFactory.java:118)
at 
org.netbeans.modules.parsing.impl.Utilities.runPriorityIO(Utilities.java:67)
at 
org.netbeans.modules.parsing.impl.TaskProcessor.runUserTask(TaskProcessor.java:178)
at 
org.netbeans.modules.parsing.api.ParserManager.parse(ParserManager.java:83)
at 
org.netbeans.api.java.source.JavaSource.runUserActionTaskImpl(JavaSource.java:452)
at 
org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:423)
at 
org.netbeans.api.java.source.JavaSource.runModificationTask(JavaSource.java:684)
at 
org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.processFiles(JavaRefactoringPlugin.java:317)
at 
org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.processFiles(JavaRefactoringPlugin.java:263)
at 
org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.processFiles(JavaRefactoringPlugin.java:245)
at 
org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.createAndAddElements(JavaRefactoringPlugin.java:326)
at 
org.netbeans.modules.refactoring.java.plugins.RenameRefactoringPlugin.prepare(RenameRefactoringPlugin.java:626)
[catch] at 
org.netbeans.modules.refactoring.api.AbstractRefactoring.pluginsPrepare2(AbstractRefactoring.java:417)
at 
org.netbeans.modules.refactoring.api.AbstractRefactoring.pluginsPrepare(AbstractRefactoring.java:401)
at 
org.netbeans.modules.refactoring.api.AbstractRefactoring.prepare(AbstractRefactoring.java:212)
at 
org.netbeans.modules.refactoring.spi.impl.ParametersPanel$Prepare.run(ParametersPanel.java:1063)

Re: Refactor renaming hardly works anymore

[Thomas Kellerer]

Hans Grimmselshausen schrieb am 17.02.2020 um 12:09:
> Does anybody know if this "refactoring-problem due to nb_javac
> plugin" already in the bug database? Because it confuses users a lot.
> Actually I thought "Am I the only persons in the world who used
> Netbeans for many years but suddenly fails to simply rename functions
> and variables?"...


Yes, there are numerous issues logged for that already, some are marked as 
resolved, some are still open

Thomas




-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Hans Grimmselshausen]

Hello Thomas,

Thank you very much. Your suggestion turns out to be a perfect work-around 
for the refactoring problem. You made my day.


Now thinking about it, every fresh version of Netbeans (since version 11.0 I 
think, or was it already in version 10?) asks at the first start to install 
this nb-javac plugin, which I always did. Because it's a very handy plugin 
which speeds up the compile-execution cycle for larger projects a good deal.


Does anybody know if this "refactoring-problem due to nb_javac plugin" 
already in the bug database? Because it confuses users a lot. Actually I 
thought "Am I the only persons in the world who used Netbeans for many years 
but suddenly fails to simply rename functions and variables?"...


Greetings,
Hans


P.S. Vielen Dank nochmals für die prompte Hilfe, Thomas.


Am 17.02.20 um 11:47 schrieb Thomas Kellerer:

Hans Grimmselshausen schrieb am 17.02.2020 um 11:41:

With Netbeans 11.2 (but also with 11.0) running in OpenJDK 11.0.6 on
Ubuntu 18 LTS, for some time I experience a lot of problems when I
try to refactor-rename public variables and functions in my mid-sized
project. Mostly but not always, I then get the following error:

--- Module Java Refactoring threw
java.util.ConcurrentModificationException. Please report a bug
against Java Refactoring module and attach your
var/log/messages.log. ---

My Ant based project has been created with Netbeans 9 or 10 (where
refactor-rename worked), and has about 60 Java source files,
including many Swing classes made with Netbeans designer (i.e. where
for a source.java file there's a matching source.form file).

I deleted the Netbeans cache folder, tried a new Netbeans user
profile, created a new (Ant based) Netbeans project and copied all my
source files to the new project's src folder. But with no success.

Do you fellow Netbeans users know of problems with the refactoring
module?


You need to uninstall the nb-javac library, then refactoring works again.

I still get it with 11.3-beta3 as long as nb-javac is installed

Note that just disabling nb-javac is not enough.



-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Refactor renaming hardly works anymore

[Thomas Kellerer]

Hans Grimmselshausen schrieb am 17.02.2020 um 11:41:
> With Netbeans 11.2 (but also with 11.0) running in OpenJDK 11.0.6 on
> Ubuntu 18 LTS, for some time I experience a lot of problems when I
> try to refactor-rename public variables and functions in my mid-sized
> project. Mostly but not always, I then get the following error:
>
> --- Module Java Refactoring threw
> java.util.ConcurrentModificationException. Please report a bug
> against Java Refactoring module and attach your
> var/log/messages.log. ---
>
> My Ant based project has been created with Netbeans 9 or 10 (where
> refactor-rename worked), and has about 60 Java source files,
> including many Swing classes made with Netbeans designer (i.e. where
> for a source.java file there's a matching source.form file).
>
> I deleted the Netbeans cache folder, tried a new Netbeans user
> profile, created a new (Ant based) Netbeans project and copied all my
> source files to the new project's src folder. But with no success.
>
> Do you fellow Netbeans users know of problems with the refactoring
> module?


You need to uninstall the nb-javac library, then refactoring works again.

I still get it with 11.3-beta3 as long as nb-javac is installed

Note that just disabling nb-javac is not enough.


-
To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org
For additional commands, e-mail: users-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Refactor renaming hardly works anymore

[Hans Grimmselshausen]

Good day Netbeans users,

With Netbeans 11.2 (but also with 11.0) running in OpenJDK 11.0.6 on Ubuntu 
18 LTS, for some time I experience a lot of problems when I try to 
refactor-rename public variables and functions in my mid-sized project. 
Mostly but not always, I then get the following error:


---
Module Java Refactoring threw java.util.ConcurrentModificationException.
Please report a bug against Java Refactoring module and attach your 
var/log/messages.log.

---

My Ant based project has been created with Netbeans 9 or 10 (where 
refactor-rename worked), and has about 60 Java source files, including many 
Swing classes made with Netbeans designer (i.e. where for a source.java file 
there's a matching source.form file).


I deleted the Netbeans cache folder, tried a new Netbeans user profile, 
created a new (Ant based) Netbeans project and copied all my source files to 
the new project's src folder. But with no success.


There's a small Netbeans library project of mine attached to my main project: 
when I rename public functions or variables in this library project, the same 
errors happen, but when I close my main project, the renaming in the library 
projects works. Like Netbeans wouldn't like my main project and only there 
doesn't allow to refactor-rename.


Do you fellow Netbeans users know of problems with the refactoring module?
Did I mis-configure anything in my Netbeans main project which causes this 
error, or did I encounter a real bug? In case of the latter I'd try to file a 
bug report. But to sort-out potential configuration problems on my side, I 
first wanted to post the problem here in the mailing list first and ask the 
Netbeans experts for advice.


From the messages.log I attach the last part below, i.e. Java's error stack 
trace. Maybe a Java user knowing more than I do, can sport something which I 
missed. In case further information would be needed, I'd gladly print it.


Thanks for any help.

Greetings,
Hans


---

SEVERE [org.openide.util.Exceptions]
java.util.ConcurrentModificationException
    at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1134)
    at 
org.netbeans.modules.java.source.parsing.ParameterNameProviderImpl.getParameterName(ParameterNameProviderImpl.java:130)
    at 
org.netbeans.modules.java.source.parsing.ParameterNameProviderImpl$1.invoke(ParameterNameProviderImpl.java:90)

    at com.sun.proxy.$Proxy24.getParameterName(Unknown Source)
    at 
com.sun.tools.javac.code.MissingInfoHandler.getParameterName(MissingInfoHandler.java:63)
    at 
com.sun.tools.javac.code.Symbol$ParamSymbol.getSimpleName(Symbol.java:1746)
    at 
com.sun.tools.javac.code.Symbol$ParamSymbol.getSimpleName(Symbol.java:1731)
    at 
org.netbeans.modules.java.source.parsing.ParameterNameProviderImpl$2.lambda$visitMethod$0(ParameterNameProviderImpl.java:142)
    at 
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)

    at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
    at 
java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
    at 
java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
    at 
java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
    at 
java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
    at 
java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
    at 
java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
    at 
org.netbeans.modules.java.source.parsing.ParameterNameProviderImpl$2.visitMethod(ParameterNameProviderImpl.java:142)
    at 
org.netbeans.modules.java.source.parsing.ParameterNameProviderImpl$2.visitMethod(ParameterNameProviderImpl.java:138)

    at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:914)
    at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:91)
    at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
    at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:114)
    at com.sun.source.util.TreeScanner.visitClass(TreeScanner.java:188)
    at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:822)
    at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at com.sun.source.util.TreeScanner.scan(TreeScanner.java:106)
    at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:114)
    at 
com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:145)

    at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:603)
    at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
    at 
org.netbeans.modules.java.source.parsing.ParameterNameProviderImpl.lambda$null$0(ParameterNameProviderImpl.java:146)
    at