Summary: | -deprecation not working? | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Wes Isberg <wes> |
Component: | Compiler | Assignee: | Adrian Colyer <adrian.colyer> |
Status: | RESOLVED INVALID | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | ||
Version: | 1.1.1 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Wes Isberg
2004-03-08 17:42:43 EST
I'll look into this in the codebase and see if I can figure out what's going on. Jim - if there was a conscious choice not to support this for some reason that would be good to know... thks. There is an issue with compiler modes and compilation units here, but I don't remember exactly what. While I was at Hursley we fixed a bug in the one test case that checked for deprecation warnings. This was failing on my machine because I was running on the JRE where the standard rt.jar had been compiled without information about deprecation messages. In this case it was a bug in the test case and not in the implementation. This looks like a different issue, but could be sensitive to other weird details about how deprecation is handled. There are special rules for not warning about deprecation in the same compilation unit. Could this particular example just be a minor difference between eclipse and javac's notion of a CU? Does this code show a deprecation error when compiling with our underlying eclipse compiler? As Jim says, this seems to be because the deprecated class is in the same CU as the using class. I tracked the arg parsing through, and -deprecation does set the appropriate options. If you put the deprecated class into a separate file, you get the expected deprecation messages. I've added a test case to ensure this remains so in the future. |