Home » Language IDEs » Java Development Tools (JDT) » Compiler regression in Eclipse 3.4?
| Compiler regression in Eclipse 3.4? [message #254261] |
Thu, 26 June 2008 08:32  |
Eclipse User |
|
|
|
Originally posted by: mauro.molinari.cardinis.com
Hello!
I have a strange (and serious) problem with Eclipse 3.4. A project of
mine (actually, a huge one) seems to have problems while compiling some
classes.
Eclipse says it can't resolve a package that:
- it does exist
- it is in the same source folder of the classes that try to import a
class in it
Precisely, the structure is this:
- src
- my.package.MyClass
- my.package.exceptions.AnotherClass
MyClass imports my.package.exceptions.AnotherClass, but the compiler
says it can't resolve my.package.execeptions. However, AnotherClass
exists and is in that package.
If I edit MyClass, delete "import my.package.exceptions.AnotherClass"
then use Organize Imports and save, sometimes the error goes away, but
sometimes the red markers in the overview rulers remain.
It's a very weird problem, one of those problems I had in the past when
I had buildpath problems. But there are no buildpath problems this time.
I double checked everything, I even built up all the project from
scratch in order to make sure there are no subtle causes to this. But
the problem persists.
I cleaned and built the project many times, without success.
The classes that exhibit this problem are always the same.
With Eclipse 3.3.2 there are no errors (obviously). My suspect is
against the multi-core support of Eclipse 3.4 compiler: might it be that
the compiler gives these errors because it fails in respecting the order
in which to compile those classes? Is there a way to turn of the
multi-threaded feature of the compiler to test it?
Unfortunately, this is one of those problems for which it's very very
hard to find a simple "hello world" to deterministically reproduce the
problem, so any help from JDT developers will be appreciated.
Mauro.
|
|
|
| Re: Compiler regression in Eclipse 3.4? [message #254265 is a reply to message #254261] |
Thu, 26 June 2008 08:38  |
| Eclipse User |
|
|
|
Funny, I had a similar problem yesterday with EMF generated classes
which are used by other classes. For me the problem was solved by
deleting all bundles and recheck them out from my subversion repository.
Tom
Mauro Molinari schrieb:
> Hello!
> I have a strange (and serious) problem with Eclipse 3.4. A project of
> mine (actually, a huge one) seems to have problems while compiling some
> classes.
> Eclipse says it can't resolve a package that:
> - it does exist
> - it is in the same source folder of the classes that try to import a
> class in it
>
> Precisely, the structure is this:
> - src
> - my.package.MyClass
> - my.package.exceptions.AnotherClass
>
> MyClass imports my.package.exceptions.AnotherClass, but the compiler
> says it can't resolve my.package.execeptions. However, AnotherClass
> exists and is in that package.
> If I edit MyClass, delete "import my.package.exceptions.AnotherClass"
> then use Organize Imports and save, sometimes the error goes away, but
> sometimes the red markers in the overview rulers remain.
>
> It's a very weird problem, one of those problems I had in the past when
> I had buildpath problems. But there are no buildpath problems this time.
> I double checked everything, I even built up all the project from
> scratch in order to make sure there are no subtle causes to this. But
> the problem persists.
> I cleaned and built the project many times, without success.
>
> The classes that exhibit this problem are always the same.
>
> With Eclipse 3.3.2 there are no errors (obviously). My suspect is
> against the multi-core support of Eclipse 3.4 compiler: might it be that
> the compiler gives these errors because it fails in respecting the order
> in which to compile those classes? Is there a way to turn of the
> multi-threaded feature of the compiler to test it?
>
> Unfortunately, this is one of those problems for which it's very very
> hard to find a simple "hello world" to deterministically reproduce the
> problem, so any help from JDT developers will be appreciated.
>
> Mauro.
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
| | | | | | | |
| Re: Compiler regression in Eclipse 3.4? [message #254464 is a reply to message #254455] |
Tue, 01 July 2008 13:05 |
| Eclipse User |
|
|
|
Mauro Molinari wrote:
> Philippe Mulet ha scritto:
>> If you really are desperate to turn off multithreaded compiler, please
>> add the following argument on your command line:
>>
>> -vmargs -Djdt.compiler.useSingleThread=true
>
> Thank you Philippe!
> Well, it doesn't seem to be a multithreading issue, because even if I
> specify that argument, the problem persists.
>
> I may try to prepare a small project that exhibits the problem but I
> think it won't be that easy.
>
> Mauro.
If you cannot reduce it, but still could share the offending workspace,
we could have a look at it then.
I suspect the erratic behavior comes from the fact that sometimes the
incremental compiler recompiles modified sources against sources or
against previously compiled binaries.
If you force a clean build, it will force getting rid of all existing
binaries. Then when you start touching one source file at a time, it
will compile this source file against existing classfiles.
In theory, the behavior should not be different; but if we have a bug,
then yes this could occur. This is why we would need steps to reproduce
and address it.
|
|
| | |
| Someone else with probably the same problem... Maybe the adtl data will help... [message #254691 is a reply to message #254513] |
Thu, 03 July 2008 18:46 |
| Eclipse User |
|
|
|
Originally posted by: rtroy.sciencetools.com
Philippe Mulet wrote:
> Mauro Molinari wrote:
>> Philippe Mulet ha scritto:
>>> If you cannot reduce it, but still could share the offending
>>> workspace, we could have a look at it then.
>>
>> Hi Philippe,
>> I could reduce the workspace to a bunch of classes that exhibit the
>> problem.
>> I'm waiting for your directives (please see my previous e-mail).
>>
>> Thank you very much for your support!
>>
>> Mauro.
> Thanks for entering bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=239229
Hi guys,
I think I can add a little to this discussion. I'm having what feels to me
suspiciously like the same problem Mauro reports. My case has a lot of
similarities. Like Mauro's problem, this involves a large application.
I'm still a greenhorn with Eclipse but my scenario is SO simple, I don't
believe I've got a build configuration problem. Here's my scenario in a
nutshell. To wit:
The problem Project:
A swing based GUI application of some 85 frames, in as many (source) files
- some 80,000+ lines of java - resulting in about 1533 classes. The GUI
uses ONE additional library (also over 80k lines of code) as an API. The
GUI is in an Eclipse workspace that includes the appropriate package
directory tree.
The API Library:
The API is a bit over 85k lines of code, contained in a package, in one
(source) file, and results in some 184 classes. It is kept in a directory
tree in a product installation directory space as class files; due to
architectural needs, a .jar file isn't used and would be a problem to
accommodate.
The Build Configuration:
GUI imported as a single project and the build is configured using Project
-> Properties -> Java Build Path -> Libraries -> Add External Class
Folder. The API's entry was moved it to the top under Order and Export (I
take it that the check-box means to include during export). The "External
Class Folder" is the parent of the package hierarchy, so the package is
included implicitly rather than explicitly.
(Note that there really isn't any other configuration that even begins to
work - except perhaps to use a .jar file instead of files and dirs for the
API. Everything else I've tried generates thousands of errors.)
The Problem:
Eclipse 3.4 complains about just one line of the GUI:
The project was not built since its build path is incomplete. Cannot find
the class file for <api.package>.<api_class>$<sub_class>. Fix the build...
and
The type <api.package>.<api_class>$<sub_class> cannot be resolved. It is
...
Error analysis:
The error is clearly mistaken. The class file is there along with the
others, and has no visible / apparent issues (permissions, etc). Further,
a compile operation from the command line of the following form works
perfectly every time:
javac -d <bin dir> -sourcepath <src dir> <src dir>.java
So, it's compiling directly from Eclipse's own source and depositing it
directly into Eclipse's own output location. _Clearly_ there's no issue
with the file itself as the error claims.
Only Known Workaround Gives More Data:
As the problem line of code was looking for a class to be returned from a
method, simply re-coding the method to return a different class that has
the capacity to return the given data worked. Thankfully, this was
possible. The resulting code builds without error using Project -> Clean.
HOWEVER, the code is STILL highlighted by the editor as a problem:
The method <methodName> from the type <apiClass> refers to the missing
type <apiClass>$<justDeletedSubClass>.
My guess is that this last bit of information will really help track this
down!
Please advise if you get this. Should I try to find the bug entry and add
this information there? Or, do you think this is a different bug? Please
advise.
Thanks,
Richard
|
|
|
| Re: Someone else with probably the same problem... Maybe the adtl data will help... [message #254700 is a reply to message #254691] |
Fri, 04 July 2008 03:26 |
| Eclipse User |
|
|
|
Originally posted by: mauro.molinari.cardinis.com
Hi Richard!
If you have a look to my bug report, I lastly found what is the problem
in my case: a malformed javadoc comment, not marked as such, is however
causing a problem to the compiler in Eclipse 3.4 (was not in Eclipse 3.3).
Regarding your problem, it seems a different problem. Looking at the
"The project was not built..." error message I would say this is a build
path problem rather than a compiler problem.
Have you tried to clean and build your project before making the
modification that you cite in your workaround? Did Eclipse still give
the same error?
Did the error occured in Eclipse 3.3?
My first suspect, given that you say that the offending classfile is
there (in the output folder), is that your Eclipse went out of synch
with the filesystem, so a Refresh issued at the root of your project
might have solved the issue.
I'm just guessing, of course.
HTH.
Mauro.
P.S.: by the way, I tracked down my own problem by setting up another
project with a copy-and-paste of the original one and then trying to
delete all the class files that I felt were not bound to the problem.
Then, I removed all the implementations and javadocs of the methods of
the classes that exhibited the problem, making sure that any single
change didn't affect the correct reproduction of the problem. I ended up
with something like 8 empty classes, so I could attach them to the bug
report. You might try to do the same in a new bug report, if you can't
find any solution to your problem.
|
|
|
| Re: Someone else with probably the same problem... Maybe the adtl data will help... [message #254739 is a reply to message #254700] |
Fri, 04 July 2008 14:25 |
| Eclipse User |
|
|
|
Originally posted by: rtroy.sciencetools.com
Mauro Molinari wrote:
> Hi Richard!
> If you have a look to my bug report, I lastly found what is the problem
> in my case: a malformed javadoc comment, not marked as such, is however
> causing a problem to the compiler in Eclipse 3.4 (was not in Eclipse 3.3).
Hi Mauro,
I don't believe there are _any_ javadoc entries, though there might be
some comments that look enough like javadoc to trigger a response - I
hadn't thought of that.
> Regarding your problem, it seems a different problem. Looking at the
> "The project was not built..." error message I would say this is a build
> path problem rather than a compiler problem.
I have completely ruled out any usual "configuration error" with the build
path. The message IS a red-herring as evidenced by the fact that
everything else about the build - all the other 184 classes - works just
fine. While it's only one class out of 185 that has an apparent problem,
the management of the import and file system level details - ownership,
permissions, etc - has all been identical for every file in the package.
Further, any change to the configuration (thus far and I've tried what I
think is literally everything even remotely possible) results in THOUSANDS
of errors (or sometimes only one or two complaining that the package isn't
found and just gives up). In short, it either finds the files in the
directory, or it doesn't - there is no partial loading of External Class
Folder libraries, or shouldn't be; that appears to be the bug. My hunches
are that something has got an inadvertent name-space issue, or some object
is "over-flowing" (memory issue?).
If I'm wrong, please inform!
> Have you tried to clean and build your project before making the
> modification that you cite in your workaround? Did Eclipse still give
> the same error?
> Did the error occured in Eclipse 3.3?
Yes, I've done 'cleans' _every_time_ as the only way I know for sure it
does the whole job. Except that, apparently it doesn't, as you reveal
below! ...In fact I've reinstalled a half dozen times, created new spaces,
imported this way, that way, and the other way, all to no avail. (I've
literally spent, by now, more than 10 hours on this problem - there's not
a lot left to try {with this version}.)
I haven't tried 3.3. I was hoping not to have to. However, given all the
fruitless time I've spent, perhaps I should have long ago! -smile-
> My first suspect, given that you say that the offending classfile is
> there (in the output folder), is that your Eclipse went out of synch
> with the filesystem, so a Refresh issued at the root of your project
> might have solved the issue.
I didn't notice "Refresh" before you pointed it out - doah! Right in front
of me!
I'll undo the workaround and see if it helps! However, I strongly doubt it
because I had done this so many times as "fresh installations." It's not
as if I was messing around with this one file all by itself (though I
certainly looked it over very carefully - sha1sum, etc).
> I'm just guessing, of course.
> HTH.
> Mauro.
> P.S.: by the way, I tracked down my own problem by setting up another
> project with a copy-and-paste of the original one and then trying to
> delete all the class files that I felt were not bound to the problem.
> Then, I removed all the implementations and javadocs of the methods of
> the classes that exhibited the problem, making sure that any single
> change didn't affect the correct reproduction of the problem. I ended up
> with something like 8 empty classes, so I could attach them to the bug
> report. You might try to do the same in a new bug report, if you can't
> find any solution to your problem.
Yes, that makes sense. I'll have to wait a day or two, though - 4th of
July and all...
Thanks for the suggestions - I really appreciate the help.
Richard
|
|
|
| Re: Someone else with probably the same problem... Maybe the adtl data will help... [message #254800 is a reply to message #254691] |
Mon, 07 July 2008 08:56 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
If you are able to do any kind of desktop sharing (such as with the ECF
tools built into Eclipse 3.4, or VNC or NetMeeting, etc) then I'd bet
one of the long-time users around here could probably help track it down
in a few minutes. The trouble with these kinds of problems is describing
symptoms, configurations, and suggestions in words that everyone
understands equally. Words are just not enough sometimes.
Eric
Richard wrote:
> Hi guys,
>
> I think I can add a little to this discussion. I'm having what feels to
> me suspiciously like the same problem Mauro reports. My case has a lot
> of similarities. Like Mauro's problem, this involves a large application.
>
> I'm still a greenhorn with Eclipse but my scenario is SO simple, I don't
> believe I've got a build configuration problem. Here's my scenario in a
> nutshell. To wit:
>
> The problem Project:
>
> A swing based GUI application of some 85 frames, in as many (source)
> files - some 80,000+ lines of java - resulting in about 1533 classes.
> The GUI uses ONE additional library (also over 80k lines of code) as an
> API. The GUI is in an Eclipse workspace that includes the appropriate
> package directory tree.
> The API Library:
>
> The API is a bit over 85k lines of code, contained in a package, in one
> (source) file, and results in some 184 classes. It is kept in a
> directory tree in a product installation directory space as class files;
> due to architectural needs, a .jar file isn't used and would be a
> problem to accommodate.
>
> The Build Configuration:
>
> GUI imported as a single project and the build is configured using
> Project -> Properties -> Java Build Path -> Libraries -> Add External
> Class Folder. The API's entry was moved it to the top under Order and
> Export (I take it that the check-box means to include during export).
> The "External Class Folder" is the parent of the package hierarchy, so
> the package is included implicitly rather than explicitly.
>
> (Note that there really isn't any other configuration that even begins
> to work - except perhaps to use a .jar file instead of files and dirs
> for the API. Everything else I've tried generates thousands of errors.)
>
> The Problem:
>
> Eclipse 3.4 complains about just one line of the GUI:
>
> The project was not built since its build path is incomplete. Cannot
> find the class file for <api.package>.<api_class>$<sub_class>. Fix the
> build...
>
> and
>
> The type <api.package>.<api_class>$<sub_class> cannot be resolved. It is ..
>
> Error analysis:
>
> The error is clearly mistaken. The class file is there along with the
> others, and has no visible / apparent issues (permissions, etc).
> Further, a compile operation from the command line of the following form
> works perfectly every time:
>
> javac -d <bin dir> -sourcepath <src dir> <src dir>.java
>
> So, it's compiling directly from Eclipse's own source and depositing it
> directly into Eclipse's own output location. _Clearly_ there's no issue
> with the file itself as the error claims.
>
> Only Known Workaround Gives More Data:
>
> As the problem line of code was looking for a class to be returned from
> a method, simply re-coding the method to return a different class that
> has the capacity to return the given data worked. Thankfully, this was
> possible. The resulting code builds without error using Project ->
> Clean. HOWEVER, the code is STILL highlighted by the editor as a problem:
>
> The method <methodName> from the type <apiClass> refers to the missing
> type <apiClass>$<justDeletedSubClass>.
>
> My guess is that this last bit of information will really help track
> this down!
>
> Please advise if you get this. Should I try to find the bug entry and
> add this information there? Or, do you think this is a different bug?
> Please advise.
>
> Thanks,
> Richard
>
|
|
| |
| Re: Someone else with probably the same problem... Maybe the adtl data will help... [message #254861 is a reply to message #254856] |
Tue, 08 July 2008 08:06 |
| Eclipse User |
|
|
|
Originally posted by: mauro.molinari.cardinis.com
Philippe Mulet ha scritto:
> FYI - I believe I have a fix at hand for
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=239229
>
> The problem could occur without javadoc. All it needs is a reference to
> an invalid type somewhere (could be as a reference in javadoc, or plain
> error in source code); where the invalid type is colliding with a truly
> existing subpackage. See bug 239229 for more details.
>
> The fix will be released for inclusion in 3.4.1, and you can get early
> access to it, by using a build from the 3.4 maintenance output:
>
> http://download.eclipse.org/eclipse/downloads/ (under 3.4.1 stream
> builds section). M20080703-0800 does NOT yet have this fix, but the next
> M-build will contain it; should be M20080709-0800 if the build machines
> are restored soon (we are having networking issues right now).
Thank you very much Philippe!
Mauro.
|
|
|
Goto Forum:
Current Time: Tue Jul 22 21:22:58 EDT 2025
Powered by FUDForum. Page generated in 0.09666 seconds |
Home