Comment 1 Frederic Fusier 2007-04-14 10:32:13 EDT

Can you provide a simple test case to help us to reproduce the problem?
Thanks

Comment 2 maarten meijer 2007-04-15 04:04:30 EDT

(In reply to comment #1)
> Can you provide a simple test case to help us to reproduce the problem?
Will try do in the next week. 

I'm in a large scale refactoring where I first did a facade with get/setNewName methods in a subclass, and then later decided to rename the protected or public fields as well.
It apparenrtly matches the get/settter in the facde or something.
Maybe the testcase will not be so simple ;-)

I think the key is in:
Caused by: java.lang.NullPointerException
        at
org.eclipse.jdt.internal.core.search.matching.FieldLocator.matchReportReference(FieldLocator.java:221)

I'm using version 3.2.2 by the way...

Comment 3 Frederic Fusier 2007-04-16 11:50:57 EDT

(In reply to comment #2)
> Will try do in the next week. 
> 
OK, thanks

> I'm in a large scale refactoring where I first did a facade with get/setNewName
> methods in a subclass, and then later decided to rename the protected or public
> fields as well.
> It apparenrtly matches the get/settter in the facde or something.
> Maybe the testcase will not be so simple ;-)
> 
I guess if it was simple, then it would occur before... If this NPE is always reproducible, you can also activate Search debug trace by changing following lines in .options file:

# Turn on debug tracing for org.eclipse.jdt.core plugin
org.eclipse.jdt.core/debug=true

# Reports java search activity
org.eclipse.jdt.core/debug/search=true

Then copy the console outputs in a file and attach it to this bug...

> I think the key is in:
> Caused by: java.lang.NullPointerException
>         at
> org.eclipse.jdt.internal.core.search.matching.FieldLocator.matchReportReference(FieldLocator.java:221)
> 
Of course, this line is already under the spot lights! But we'd rather prefer to understand why an object was unexpectedly null instead of putting a null check to avoid the exception...

> I'm using version 3.2.2 by the way...
> 
Thanks for the precision.

Comment 4 maarten meijer 2007-04-16 18:07:41 EDT

I think I know what is happening, and the problem is related to my workaround for bug#66177 no PDE build from linked resource. I have a non-PDE basic library where I develop in. To include in PDE projects I use an ANT copy of relevant packages to a PDE library project for use by the plugins I'm developing. This gives the following tree:
+ SomeLibrary (for PDE)
+ src
=   SomeClass.java
* ant-duplicate.xml (for copy builder)
+ SomeLibrary (basic)
+ src
=   SomeClass.java

The problem occurs when trying to Rename some public or protected field in SomeLibrary (basic)/src/SomeClass.java

I suspect that the fatal NullPointer is returned when the search encounters an identically named field in an identically named class. The proper behavious in my view would be to show a dialog or just show them with a warning in Preview dialog. I will create the traces and add them as attachments.

Comment 5 maarten meijer 2007-04-16 18:07:55 EDT

Created attachment 63958 [details]
mylar/context/zip

Comment 6 maarten meijer 2007-04-16 18:27:59 EDT

I found plugin org.eclipse.jdt.core_3.2.3.v_686_R32x.jar
I unjarred it and changed the options as you described
==
# Turn on debug tracing for org.eclipse.jdt.core plugin ALREADY ON!
org.eclipse.jdt.core/debug=true

# Reports java search activity
org.eclipse.jdt.core/debug/search=true
==
I can repeat the error but where do I find the console output to send?

Comment 7 maarten meijer 2007-04-17 04:37:45 EDT

Created attachment 64005 [details]
Log with search options on

debug.options contains:
# Turn on debug tracing for org.eclipse.jdt.core plugin
org.eclipse.jdt.core/debug=true

# Reports java search activity
org.eclipse.jdt.core/debug/search=true

Comment 8 Frederic Fusier 2007-04-17 06:58:01 EDT

(In reply to comment #6)
> I found plugin org.eclipse.jdt.core_3.2.3.v_686_R32x.jar
> I unjarred it and changed the options as you described
> ==
> # Turn on debug tracing for org.eclipse.jdt.core plugin ALREADY ON!
> org.eclipse.jdt.core/debug=true
> 
> # Reports java search activity
> org.eclipse.jdt.core/debug/search=true
> ==
> I can repeat the error but where do I find the console output to send?
> 

Sorry I should give you more precise steps to activate the trace...

There's no need to unjar this jdt-core plugin jar file, you only need to have the .options file in the <eclipse install dir>/eclipse subdir and launch eclipse in a terminal window using following command line:
./eclipse -consoleLog -refresh -debug -showLocation -data <your workspace path> -vm <your VM path>

On my Linux box, using this command line, I got the Search trace in the terminal window from where I launched eclipse:
Thread[Worker-2,5,main] BasicSearchEngine.searchAllTypeNames(char[], char[], int, int, IJavaSearchScope, IRestrictedAccessTypeRequestor, int, IProgressMonitor)
Thread[Worker-2,5,main]         - package name: null
Thread[Worker-2,5,main]         - match rule: R_EXACT_MATCH
Thread[Worker-2,5,main]         - type name: !@$#!@
Thread[Worker-2,5,main]         - match rule: R_PATTERN_MATCH | R_CASE_SENSITIVE
Thread[Worker-2,5,main]         - search for: 5
Thread[Worker-2,5,main]         - scope: JavaWorkspaceScope

I guess it should be similar for a Mac/OS box...

Comment 9 Frederic Fusier 2007-04-17 07:01:02 EDT

Created attachment 64019 [details]
.options file to activate Search trace

Note that the trace is not ON by default even with:
# Turn on debug tracing for org.eclipse.jdt.core plugin
org.eclipse.jdt.core/debug=true

You need to put -debug parameter in your command line to really have this trace activated...

Comment 10 Frederic Fusier 2007-04-17 07:47:22 EDT

(In reply to comment #4)
> I think I know what is happening, and the problem is related to my workaround
> for bug#66177 no PDE build from linked resource. I have a non-PDE basic library
> where I develop in. To include in PDE projects I use an ANT copy of relevant
> packages to a PDE library project for use by the plugins I'm developing. This
> gives the following tree:
> + SomeLibrary (for PDE)
> + src
> =   SomeClass.java
> * ant-duplicate.xml (for copy builder)
> + SomeLibrary (basic)
> + src
> =   SomeClass.java
> 
> The problem occurs when trying to Rename some public or protected field in
> SomeLibrary (basic)/src/SomeClass.java
> 
> I suspect that the fatal NullPointer is returned when the search encounters an
> identically named field in an identically named class. The proper behavious in
> my view would be to show a dialog or just show them with a warning in Preview
> dialog. I will create the traces and add them as attachments.
> 
Can you provide more information on your set-up?
1) Are 'SomeLibrary (PDE)' and 'SomeLibrary (basic)' Java or Plug-in projects?
2) Is there any dependencies between these 2 projects?
3) How does the ant-duplicate.xml work (copy from PDE to basic, reverse way, 
   merge, other...)?

Comment 11 maarten meijer 2007-04-17 09:01:49 EDT

After reading http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.user/tasks/running_eclipse.htm#macosx
I've modified my eclipse.ini so it reads the description in debug.options as follows:

-debug /Applications/eclipse3.2.1/debug.options
-consolelog
-vmargs
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Xbootclasspath/p:../../../plugins/org.eclipse.jdt.debug_3.2.1.r321_v20060731/jdi.jar
-Xms256m
-Xmx512m
-XX:MaxPermSize=256m
-Dorg.eclipse.swt.internal.carbon.smallFonts
-Dorg.eclipse.swt.internal.carbon.noFocusRing

But I get no sign of search activity in the .log file, just the exception.

Re test setup, I'm gradually building up test setup as described until I find on that reliably generates the error.

Comment 12 Frederic Fusier 2007-04-17 11:12:29 EDT

(In reply to comment #11)
The trace outputs are never put in the .log file but in the console. Following comment 8 instructions should display these outputs in the the terminal window
from where you launched eclipse. Isn't Mac/OS an Unix operating system? If so, these instructions should work...
Does your debug.options file contains the lines for Search trace?
Can you also provide answers for comment 10 questions?

Comment 13 maarten meijer 2007-04-17 14:36:03 EDT

 (In reply to comment #12)
> (In reply to comment #11)
> The trace outputs are never put in the .log file but in the console. Following
> comment 8 instructions should display these outputs in the the terminal window
> from where you launched eclipse. Isn't Mac/OS an Unix operating system? If so,
> these instructions should work...
Yes Mac OSX is unix like :-( but different. I expected the output to appear in the console.log file after using -consolelog, but alas.
Outputs should appear as well when I'm just using java search, right?
> Does your debug.options file contains the lines for Search trace?
Yes it includes that (see comment 7) Also I use -debug on the command line...via eclipse.ini
> Can you also provide answers for comment 10 questions?
I'm graduallty building the ever more complex MINIMAL set of two projects that will recreate the problem. 
It has to do with project SomeLibrary (for PDE) having SomeLibrary (basic) set as a dependency on its build path. When I switch that off, the problem goes away but I want the dependency set for refactorings to propagate towards the clients of this copied library as well.
I do ghet problems/warnings so far but no failures and error log entries.

Comment 14 maarten meijer 2007-04-17 15:20:05 EDT

Created attachment 64087 [details]
Search trace before error occurs

Attachment is the trace created by using the following shell commands on mac osx:
cd /Applications/eclipse3.2.1/
./eclipse -os macosx -ws carbon -debug /Applications/eclipse3.2.1/debug.options -consolelog -keyring /Users/maarten/.eclipse_keyring -consoleLog -showlocation -data /Users/maarten/workspace-181380 | bbedit
The console output is then piped to bbeedit for saving and editing.
So what's the next step?

Comment 15 maarten meijer 2007-04-20 09:06:47 EDT

I have downloaded Eclipse 3.3M6 and installed all my usual plugins. 
I then created a new workspace where I took the two projects from CVS.

When I refactor in version 3.2.2 the error occurs.

When I do the same in vevrsion 3.3M6 I do get multiple warnings about shadowing
'Another name will shadow access to the renamed element'
But the refactoring is execured without problems.

It appears the problem has gone away as a side effect of something else.

Comment 16 Frederic Fusier 2007-04-20 09:23:08 EDT

Thanks for the feedback. So, I close this bug as WORKSFORME.

Please note that it does not mean that I do not believe it happens in 3.2.2.
But as I cannot reproduce it locally, I have no chance to find the original bug and set this bug as a duplicate of it...