Comment 1 Dani Megert 2010-01-18 04:22:12 EST

>org.codehaus.jdt.groovy.internal.compiler.ast.LazyGenericsType.getType
This is not Eclipse. Please file the bug against Groovy Eclipse from codehaus.org.

Comment 2 Jörg Thönnes 2010-01-20 10:05:04 EST

(In reply to comment #1)
> >org.codehaus.jdt.groovy.internal.compiler.ast.LazyGenericsType.getType
> This is not Eclipse. Please file the bug against Groovy Eclipse from
> codehaus.org.

Hi Dani,

another colleague of mine was able to reproduce this without any Groovy plugin installed.
So this seems to be a more general issue.

So please re-open this issue.

Thanks, Jörg

Comment 3 Dani Megert 2010-01-20 10:10:28 EST

>another colleague of mine was able to reproduce this without any Groovy plugin
>installed.
>So this seems to be a more general issue.
>
>So please re-open this issue.
As soon as you provide those reproducible steps.

Comment 4 Jörg Thönnes 2010-01-23 07:25:52 EST

Created attachment 157033 [details]
Stacktrace without Groovy plugin

As promised, a colleague reproduced this renaming without having the Groovy plugin installed.

Comment 5 Jörg Thönnes 2010-01-23 07:28:35 EST

Recently, we made a change with regard to the class file location:
Initially, we put the .class files in the same place as the .java file.
Now, we put them into a separate target folder.

The line in the stacktrace "Caused by: java.lang.IllegalArgumentException: Class file name must end with .class"
indicates an issue here.

So my colleague moved the .class files back to .java files.

Comment 6 Jörg Thönnes 2010-01-23 07:29:59 EST

Created attachment 157034 [details]
Second stack trace after moving the .class files besides .java files

As mentioned before, my colleague moved the .class files back to the .java files.
This resulted in another stack trace.

Comment 7 Jörg Thönnes 2010-01-23 07:32:17 EST

Added my colleague as Cc.

Comment 8 Markus Keller 2010-01-24 20:19:09 EST

The stacktraces you've posted now are different problems than the first one (which really was/is a problem in the Groovy plug-in).

(In reply to comment #4)
> Created an attachment (id=157033) [details] [diff]
> Stacktrace without Groovy plugin

That looks like a dup of bug 286379.


(In reply to comment #6)
> Created an attachment (id=157034) [details] [diff]
> Second stack trace after moving the .class files besides .java files

This seems to be a new problem. Moving to JDT Core for investigation:

java.lang.ClassCastException: java.lang.String cannot be cast to org.eclipse.jdt.internal.core.JavaElement
at org.eclipse.jdt.internal.core.JavaModelManager.secondaryTypesRemoving(JavaModelManager.java:4405)
at org.eclipse.jdt.internal.core.JavaModelManager.secondaryTypesRemoving(JavaModelManager.java:4336)
at org.eclipse.jdt.internal.core.DeltaProcessor.updateIndex(DeltaProcessor.java:2603)
a

Comment 9 Jörg Thönnes 2010-02-08 06:19:43 EST

Anything new here?

As a workaround, the refactoring to change a method signature can also change the name of the function.
This refactoring works in all the failing cases.

Will you fix this for the 3.5 SR2 release? We would really appreciate it.

Comment 10 Dani Megert 2010-02-08 06:24:25 EST

>Anything new here?
No, because we still do not have a test case.

Comment 11 Michael Meß 2010-02-09 07:00:06 EST

The workaround to change the method signature works fine for functions, but
unfortunately it cannot be applied to member variable names where renaming fails; renaming local variables works.

Comment 12 Jörg Thönnes 2010-02-09 12:06:13 EST

(In reply to comment #10)
> >Anything new here?
> No, because we still do not have a test case.

Hi Dani,

it is difficult to provide a test case since we have a large project which we cannot send to you.
Do you have any utility to obfuscate java source code so we could send you our project?

Comment 13 Dani Megert 2010-02-09 12:13:08 EST

>it is difficult to provide a test case since we have a large project which we
>cannot send to you.
Maybe you could filter out the pattern by shrinking it on your side.

>Do you have any utility to obfuscate java source code so we could send you our
>project?
See http://java-source.net/open-source/obfuscators

Comment 14 Olivier Thomann 2010-02-09 12:18:04 EST

(In reply to comment #13)
> >Do you have any utility to obfuscate java source code so we could send you our
> >project?
> See http://java-source.net/open-source/obfuscators
If you go in that direction, you need to make sure that the issue still arises once the code is obfuscated.

I updated the title to reflect what needs to be fixed.

Comment 15 Jörg Thönnes 2010-02-09 12:39:40 EST

(In reply to comment #14)
> I updated the title to reflect what needs to be fixed.

Please, could you shed some light on what is meant by "secondary types removal?"

Comment 16 Olivier Thomann 2010-02-09 12:46:30 EST

(In reply to comment #15)
> Please, could you shed some light on what is meant by "secondary types
> removal?"
The problem occurs in:
org.eclipse.jdt.internal.core.JavaModelManager.secondaryTypesRemoving(JavaModelManager.java:4405)

Secondary types are toplevel types defined in a compilation unit that are not public.
For example:

A.java:

public class A {}
class B {}

B is a secondary type inside the unit A.java.

Comment 17 Frederic Fusier 2010-02-09 12:56:44 EST

(In reply to comment #16)
> (In reply to comment #15)
> > Please, could you shed some light on what is meant by "secondary types
> > removal?"
> The problem occurs in:
> org.eclipse.jdt.internal.core.JavaModelManager.secondaryTypesRemoving(JavaModelManager.java:4405)
> 
> Secondary types are toplevel types defined in a compilation unit that are not
> public.
> For example:
> 
> A.java:
> 
> public class A {}
> class B {}
> 
> B is a secondary type inside the unit A.java.

Typically, the removal action occurs when a secondary type is removed from a source and the JavaModelManager secondary types cache needs to be updated...

In the comment 16 sample, that would occurs when the secondary type B was removed from the java source file A.java...

Comment 18 Jörg Thönnes 2010-02-09 13:03:21 EST

Thanks for the hints, that will help greatly.

So I have just to look for files containing such secondary types?

Actually, in our Java source code we do not use such types, only nested classes:

A.java

public class A {
   class B {}
}

But this is not a nested type, is it?

But in some Groovy scripts we use nested types.

Is there any way to clear or debug this cache?

I set up a fresh check-out in a new workspace, so I presume this also happens if the cache is cleared.

I will try to strip down the source code now.

Comment 19 Olivier Thomann 2010-02-09 13:08:31 EST

(In reply to comment #18)
> So I have just to look for files containing such secondary types?
Somehow you should have secondary types. The code where it fails is only called if projectInfo.secondaryTypes is not null.

> But this is not a nested type, is it?
Yes, this is what we call a member type (nested types that is not local to a method or an initializer).

> Is there any way to clear or debug this cache?
I would need to debug it myself to find out why that cache is being populated.

Comment 20 Jörg Thönnes 2010-02-09 13:40:29 EST

My findings so fare are that deleting the sub-tree with the Groovy code corrects this issue.

Then I tracked down all Groovy files having secondary types and removed the corresponding sub-directories.
But this did not help.

On the other side, I wonder how my colleague did reproduce this without any Groovy plugin.
Is it possible that the cache is working on .class files (in target folder) and some Groovy generated files have left over from a previous run?

Please leave this bug open until I have talked to my colleague tomorrow.

Thanks, Jörg

Comment 21 Olivier Thomann 2010-02-09 13:43:08 EST

(In reply to comment #20)
> Please leave this bug open until I have talked to my colleague tomorrow.
I won't close this bug as long as it is not clear that the problem comes from a third party bundle.

Comment 22 Jörg Thönnes 2010-02-09 13:44:47 EST

(In reply to comment #19)
> (In reply to comment #18)
> > So I have just to look for files containing such secondary types?
> Somehow you should have secondary types. The code where it fails is only called
> if projectInfo.secondaryTypes is not null.

Do you have some trick to find all files containing secondary types? Just grep-ing for multiple occurances of "class" would also find nested classes etc.

Comment 23 Olivier Thomann 2010-02-09 14:00:32 EST

I can provide a small tool that would do this for you, but you'll need to wait later today as I am busy on other bugs.

Comment 24 Jörg Thönnes 2010-02-09 14:12:57 EST

(In reply to comment #23)
> I can provide a small tool that would do this for you, but you'll need to wait
> later today as I am busy on other bugs.

Thanks, that would be help a lot. Since I am at GMT+1, I can wait until tomorrow, ie > 10 hours.

I found the following scenario:

1. With Groovy files and Groovy plugin installed --> rename --> error
2. Un-install Groovy plugin --> rename --> error
3. New workspace, import existing projects --> rename --> WORKS!!
4. Back to previous workspace (which is rebuilt) --> rename --> ERROR!!!

So it seems to me that there is some corrupt information cached in the workspace.

Do you have an idea how I could clean the secondary types cache without switching to a new workspace?
This would help supporting this idea.

Comment 25 Frederic Fusier 2010-02-09 14:29:29 EST

(In reply to comment #24)
> (In reply to comment #23)
> > I can provide a small tool that would do this for you, but you'll need to wait
> > later today as I am busy on other bugs.
> 
> Thanks, that would be help a lot. Since I am at GMT+1, I can wait until
> tomorrow, ie > 10 hours.
> 
> I found the following scenario:
> 
> 1. With Groovy files and Groovy plugin installed --> rename --> error
> 2. Un-install Groovy plugin --> rename --> error
> 3. New workspace, import existing projects --> rename --> WORKS!!
> 4. Back to previous workspace (which is rebuilt) --> rename --> ERROR!!!
> 
> So it seems to me that there is some corrupt information cached in the
> workspace.
> 
> Do you have an idea how I could clean the secondary types cache without
> switching to a new workspace?
> This would help supporting this idea.

The cache is built when you start your eclipse session, it's not saved while closing your session and read while restarting it... Hence, if there's still an exception while reopening your old workspace, that means that there are still Groovy secondary types read by the Java Model at startup. It means that the uninstall of this plugin didn't work properly...

To know what are these offending secondary types which are still visible for the Java Model (ie. they still exist somewhere onto your classpath), you can also activate the debug for the search engine by changing the following lines in the .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, add the following argument in your eclipse command line:
-debug <relative path of the .options file>
-consoleLog

With these debug, while restarting your eclipse session, you should see displayed in the console the content of the JavaModelManager secondary cache.

You can also get a more complete information about the operation done on this
cache, by activate the trace for the JavaModelManager instead... Just replace
the search engine activation line by the Java Model one into the .options file:

# Reports various Java model activities
org.eclipse.jdt.core/debug/javamodel=true

Then, reproduce the problem with these 2 traces separately activated (ie. Search
Engine and Java Model manager), copy/paste the 2 console outputs you'll get in
2 separate text files and attach these files to this bug.

This will surely help us to understand what happen there...

TIA

Comment 26 Markus Keller 2010-02-09 14:50:21 EST

> Do you have some trick to find all files containing secondary types? Just
> grep-ing for multiple occurances of "class" would also find nested classes etc.

If you indent nested classes but do not indent top-level classes, this regular expression will do that (Ctrl+H, File Search, on *.java files):
(?s-i)(\R(public\s*)?class.*){2,}

Comment 27 Jörg Thönnes 2010-02-10 05:38:22 EST

FYI: I created the following bug for the Groovy Eclipse plugin to get more help from the Groovy people:

GRECLIPSE-642: Groovy plugin may break JDT rename feature completely
http://jira.codehaus.org/browse/GRECLIPSE-642

Thanks for the hints, Frederic and Markus. I will have a look.

Comment 28 Jörg Thönnes 2010-02-10 09:27:53 EST

Created attachment 158715 [details]
debug/search=true,groovy-plugin-disabled

Reproduced error with JDT debug/search=true and de-installed groovy plugin.

Comment 29 Jörg Thönnes 2010-02-10 09:29:03 EST

Created attachment 158716 [details]
debug/search=true,groovy-plugin-enabled

Reproduced error with JDT debug/search=true and installed groovy plugin.

Comment 30 Jörg Thönnes 2010-02-10 09:30:14 EST

Created attachment 158717 [details]
debug/javamodel=true,groovy-plugin-disabled

Reproduced error with JDT debug/javamodel=true and de-installed groovy plugin.

Comment 31 Jörg Thönnes 2010-02-10 09:34:50 EST

Created attachment 158719 [details]
debug/javamodel=true,groovy-plugin-enabled

Reproduced error with JDT debug/javamodel=true and installed groovy plugin. (Gzipped since the file was too large)

Comment 32 Frederic Fusier 2010-02-10 10:27:10 EST

Thanks Jörg for the feedback.

So, reading the logs with the Groovy plugin uninstalled, it appears that there's still an 'all-macd' project in which there are still secondary types. Is it a Groovy project/plugin not removed while uninstalling the product or is it a project belonging to your application?

Note that I do not see in these logs the exception attached in comment 6:
> Created an attachment (id=157034) [details] [details] [diff]
> Second stack trace after moving the .class files besides .java files

Instead the exception you got is still a dup of bug 286379...

In fact, what I would like to have was a trace file with the JavaModelManager debug activated when the exception attached in comment 6 occurs... I suspect this exception to cancel the Groovy uninstall process and lead to have some files/project not to be removed properly.

So, I suggest that you execute the following scenario:
1) Start in a brand new wksp
2) Install the Groovy plugin
3) Load your projects
4) Leave the session
5) Restart the session with the JMM debug activated
6) Uninstall the Groovy plugin
7) Copy the console output in log file 1
8) Leave the session (I guess it's mandatory after the Groovy uninstall)
9) Restart the session with the JMM debug activated
10) Move the .class files besides the .java files (in fact, do the same 
    operation than you did in comment 6)
11) Copy the console output in log file 2
12) Attach the 2 log files to the bug

Note also that the 2 log files when the Groovy plugin is installed both show the StackOverflowException dumped in comment 0. So, it seems that we have 2 different issues here. Hence, I suggest to keep the current bug for the JDT/UI stack over flow issue and that you open a separate bug for the secondary type removal exception by copying the comment 6 as the initial description...

TIA

Comment 33 Jörg Thönnes 2010-02-10 10:53:34 EST

OK, just a quick question: Does the JavaModelManager work on the java source code or on the compiled class files?

If it works on .class files, this could explain why the issues persists if the workbench is restarted (the are left-over .class files).

Anyway, will execute the suggested steps above as soon as I have some time. Will you create the second bug?

Comment 34 Frederic Fusier 2010-02-10 11:29:06 EST

(In reply to comment #33)
> OK, just a quick question: Does the JavaModelManager work on the java source
> code or on the compiled class files?
> 
It looks at both of them as soon as they are accessible through the classpath...

> If it works on .class files, this could explain why the issues persists if the
> workbench is restarted (the are left-over .class files).
>
That cannot be the explanation because secondary types can only exist in a source file, after having been compiled, each class have one .class file whatever they were primary or secondary types... Furthermore, if you look closely at the secondary types cache contents in the log, you'll see that all paths are located in the 'src' source folder of the 'all-macd' project.

> Anyway, will execute the suggested steps above as soon as I have some time.
> Will you create the second bug?
>
Sure, I'll do it...

Comment 35 Olivier Thomann 2010-02-10 11:34:24 EST

(In reply to comment #33)
> OK, just a quick question: Does the JavaModelManager work on the java source
> code or on the compiled class files?
It works on both. Since IClassFile represents compiled class file on the classpath.
 
> If it works on .class files, this could explain why the issues persists if the
> workbench is restarted (the are left-over .class files).
I think we are not talking about the same issue.
The problem I want to see with secondary types is:
java.lang.ClassCastException: java.lang.String cannot be cast to org.eclipse.jdt.internal.core.JavaElement
at org.eclipse.jdt.internal.core.JavaModelManager.secondaryTypesRemoving(JavaModelManager.java:4405)
at org.eclipse.jdt.internal.core.JavaModelManager.secondaryTypesRemoving(JavaModelManager.java:4336)
at org.eclipse.jdt.internal.core.DeltaProcessor.updateIndex(DeltaProcessor.java:2603)
at org.eclipse.jdt.internal.core.DeltaProcessor.updateCurrentDeltaAndIndex(DeltaProcessor.java:2406)

Not the one about java.lang.IllegalArgumentException: Class file name must end with .class. This one is already fixed in 3.6 stream as Frédéric mentioned.

> Anyway, will execute the suggested steps above as soon as I have some time.
> Will you create the second bug?
This bug is for the secondary types issue. Not the problem with "Class file name must end with .class".

Could you please try a 3.6M5 build to see if the problem is gone?

If the java.lang.ClassCastException issue cannot be reproduced, we will close this bug as WORKSFORME and it can be reopen when steps to reproduce can be provided.

Thanks.

Comment 36 Frederic Fusier 2010-02-10 11:39:10 EST

(In reply to comment #34)
> > Anyway, will execute the suggested steps above as soon as I have some time.
> > Will you create the second bug?
> >
> Sure, I'll do it...

I've opened bug 302455 for the JDT/Core secondary types issue...

Comment 37 Frederic Fusier 2010-02-10 11:45:39 EST

Sorry for the noise, I read the logs with Groovy installed too fast and I missed the fact that the stack trace was in the Groovy code... Hence, this issue does not concern JDT/UI!

So, closing this bug as NOT_ECLIPSE...

Comment 38 Michael Meß 2010-02-11 04:00:11 EST

What does eclipse do different when renaming a function from the "Change signature"-dialog (See comment 9 and 11) from renaming using the "Rename" functionality?

Maybe this information can be used to narrow down the reason for the problem.

Are some checks (including those causing the problems) omitted when using the "Change signature" dialog for renaming a function?

Comment 39 Dani Megert 2010-02-11 04:03:25 EST

Michael, this bug is closed. Please add your comments to bug 302455.

Comment 40 Markus Keller 2010-02-11 10:49:08 EST

(In reply to comment #38)
> What does eclipse do different when renaming a function from the "Change
> signature"-dialog (See comment 9 and 11) from renaming using the "Rename"
> functionality?

These are two different refactorings, so their implementation is not completely analogous.

> Maybe this information can be used to narrow down the reason for the problem.
> 
> Are some checks (including those causing the problems) omitted when using the
> "Change signature" dialog for renaming a function?

Not really, the exceptions happen in the execution phase.


(In reply to bug 302455 comment #2)
> bug 299746 should be closed as a duplicate of bug 286379.

Yup, doing that.

Comment 41 Markus Keller 2010-02-11 10:51:20 EST

*** This bug has been marked as a duplicate of bug 286379 ***

Comment 42 Frederic Fusier 2010-02-16 07:51:17 EST

Set as not eclipse instead of duplicate. This initial issue reported at comment is a problem with the Groovy plugin. The search issue of bug 286379 was reported later while doing tests to reproduce the problem.

Hence, it's clearer to have on bug per issue:
 - bug 299746: Groovy problem described at comment 0
 - bug 286379: Search problem got at comment 4
 - bug 302455: Secondary types cache problem got a cmment 6

Comment 43 Jörg Thönnes 2010-02-16 08:53:44 EST

Thanks, Jörg

Comment 44 Srikanth Sankaran 2010-03-08 04:44:53 EST

Verified for 3.6M6

Comment 45 Srikanth Sankaran 2010-03-08 04:45:46 EST

Verified.