Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Java Development Tools (JDT) » Eclipse Mars.2 problem resolving type(Incremental compilation fails under very mysterious circumstances)
Eclipse Mars.2 problem resolving type [message #1733996] Thu, 02 June 2016 19:13 Go to next message
Kevin Mitchell is currently offline Kevin MitchellFriend
Messages: 2
Registered: June 2016
Junior Member
First some background:

I'm helping maintain a large project with about 2,398 source files. We get source drops from our upstream partner who apparently uses Ant and Eclipse, and we use Maven and M2Eclipse with Eclipse.

We've got a new code drop that has some added and modified files, and I'm testing building it in our environment.

Sometimes, the IDE can't resolve the type on some of the classes. I get messages like <Classname> cannot be resolved to a type.

The classes that aren't resolved happen to not be in files named after the class, and there are also almost-identical classes with the same names in an adjacent package. These classes, and their state of disorganization, are not new; we've been successfully developing this product with Eclipse for over 18 months.

Furthermore, it's intermittent. Some minor changes to other files may make the errors go away, but using the Clean... menu item and a rebuild causes the errors to come back.

I can also observe the following strange results:


  1. Choose the missing type, do a Quick Fix to add the import for that type, and the IDE doesn't add the import (the unresolved type is in the same package). The option to fix things by importing is not always present.
  2. Add the import manually, and it fixes the problem.
  3. Organize Imports removes the redundant import of a class in the same package, and then the errors reappear.
  4. Going outside the IDE and manually changing the packages around by transposing letters in a two-level-up directory name, and using Perl to change all the package paths in the source, also fixes the problem. In other words, the problem is sensitive to the name we're using for the packages.


Fails with:


  • Mars.2 IDE
  • Latest snapshot IDE


The source seems to be well-formed, at least in the sense that it builds fine with:


  • Oracle JDK 1.7 compiler via Maven
  • ecj-4.5.2 in batch mode, using a build.xml exported from the IDE, and the settings file from the IDE (strangely enough)
  • IntelliJ IDEA


Problem seems to be consistent on Mac/Windows/Linux, and I've tried new workspaces, clean installs of Eclipse, deleting global Eclipse settings.

My experiments tell me that the problem seems to be isolated to the incremental compilation that happens in the IDE. That it's so sensitive to how things are named makes me wonder if there's some kind of hash collision in a cache or something.

Any ideas/suggestions? Is there a way I can gather debugging information from the JDT?

I could even attempt a look into the JDT source code if anybody can suggest what part might be involved.
Re: Eclipse Mars.2 problem resolving type [message #1734156 is a reply to message #1733996] Sun, 05 June 2016 12:58 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
Messages: 1853
Registered: July 2009
Senior Member
Maybe this is the core:

Quote:
The classes that aren't resolved happen to not be in files named after the class

How are those classes supposed to be found then? Are those public types (should then show an error regarding this mismatch)?

Perhaps some ways of building simply rely on a fortunate compilation order, so that those classes are compiled first and a .class file is found in target/classes? A different compile order (e.g., induced by some renaming) could change this game - randomly.
Re: Eclipse Mars.2 problem resolving type [message #1735935 is a reply to message #1734156] Thu, 23 June 2016 18:32 Go to previous message
Kevin Mitchell is currently offline Kevin MitchellFriend
Messages: 2
Registered: June 2016
Junior Member
Stephan Herrmann wrote on Sun, 05 June 2016 12:58

How are those classes supposed to be found then?


Presumably however they were found before? I'm not fully aware about how the IDE or the incremental compiler work behind the scenes, but one would think there's a strategy there somewhere.

In any event, thanks for the response. We ended up writing some scripts to separate these classes out, and applied them to both our upstream and our changed code before merging. That solves the problem for us, for now.

If I ever come upon a small test case that isn't proprietary, I'll put a test case together and open a bug for consideration.

Like Gregory House, even though the patient will live, the puzzle is what intrigues me.
Previous Topic:Hook into the build process
Next Topic:Feature patch releng
Goto Forum:
  


Current Time: Mon Oct 07 05:29:57 GMT 2024

Powered by FUDForum. Page generated in 0.05188 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top