Bug 107332 - [compiler] wrong problem method generated for unused imports
Summary: [compiler] wrong problem method generated for unused imports
Status: RESOLVED DUPLICATE of bug 107282
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-18 11:19 EDT by Olivier Thomann CLA
Modified: 2005-10-20 10:43 EDT (History)
3 users (show)

See Also:


Attachments
Proposed fix (1.90 KB, patch)
2005-08-18 11:51 EDT, Olivier Thomann CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Thomann CLA 2005-08-18 11:19:43 EDT
When unused import is set to error, we can end up generating problem method
where the unused import problem is not in the message of the error.
This leads to a weird error at runtime.
We should not create a problem type at all for unused imports. So we should log
an error if unused import are set to error, but we should generate a valid class
file.
One user case is while debugging some imports can be added that will prevent the
code from executing once hot code replace has run.
Comment 1 Olivier Thomann CLA 2005-08-18 11:51:43 EDT
Created attachment 26240 [details]
Proposed fix

This patch creates a problem (an error) so that the problem view will show the
error. And you keep the dialog saying that the type contains errors before you
execute it.
But the reference context is not tagged as having error. This means that the
compilation unit is resolved and the code executes fine.
So the following code:
import java.util.*;

public class X {
		 public static void main(String argv[]) {
				 System.out.println("Hello, Word!");
		 }
}

would result with:
Hello, Word! at runtime instead of an error about unresolved compilation
errors.

We could generalize this fix for all non mandatory JLS errors (see bug 107282).
Comment 2 Philipe Mulet CLA 2005-09-06 03:42:12 EDT
See bug 107282 for argument against releasing this fix
Comment 3 Olivier Thomann CLA 2005-09-06 13:49:59 EDT
Then we should close as WONTFIX.
I still believe that the debugging use case with hotcode replace is painful for
the user.
When we have compile errors (unused imports) that spawns over the whole unit, we
don't give a useful message to the user since the java.lang.Error that we throw
doesn't contain any information relative to the unresolved compilation errors.
We would need to add a clinit that refers to these errors.
As long as the markers are created, the user can still see the errors and fix
them      prior to a build. During a build, the build would still show the
compile errors.
I think the problem methods/types should only be used when the code generation
cannot complete successfully. The unused imports have no impact on the code
generation. The .class file could be successfully generated as it would be
without the unused imports.
Just my two cents.
Comment 4 Olivier Thomann CLA 2005-10-20 10:43:08 EDT
Closing as dup of bug 107282. With fix for bug 107282, this is no longer an issue.

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