Bug 261323 - [1.5][compiler] Static import shown as unused when class field is an annotation value
Summary: [1.5][compiler] Static import shown as unused when class field is an annotati...
Status: VERIFIED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4.1   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.5 M5   Edit
Assignee: Srikanth Sankaran CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-16 05:03 EST by Robert Munteanu CLA
Modified: 2009-01-27 10:53 EST (History)
2 users (show)

See Also:


Attachments
Sample class which reproduces the problem (174 bytes, text/x-java)
2009-01-16 05:03 EST, Robert Munteanu CLA
no flags Details
Junit Test (1.98 KB, patch)
2009-01-23 01:02 EST, Srikanth Sankaran CLA
no flags Details | Diff
Test patch for 3.4 maintenance branch (1.99 KB, patch)
2009-01-23 01:28 EST, Srikanth Sankaran CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Munteanu CLA 2009-01-16 05:03:17 EST
Created attachment 122783 [details]
Sample class which reproduces the problem

Build ID: M20080911-1700

Steps To Reproduce:
1. Create a static class property 
2. In the same class, create a static import for that property
3. Annotate the class, and give the unqualified property name as a value for that property

At that moment the static import is marked as unused, even though it is used by the annotation.

According to the JLS, the annotation value must be a constant expression ( which the plain field name is not, unless statically imported ).


More information:
Comment 1 Philipe Mulet CLA 2009-01-21 07:09:18 EST
Srikanth - pls have a look at it
Comment 2 Srikanth Sankaran CLA 2009-01-22 06:31:37 EST
Unable to reproduce this: Tested with the following versions:

3.4.1 Build id: M20080911-1700
3.5 M2 Build id: I20080918-0100
3.5 M3 Build id: I20081030-1917
3.5 M4 Build id: I20081211-1908
HEAD 

I uniformly see only the single diagnostic :

Unnecessary @SuppressWarnings("unchecked")	SomeTest.java	_pasted_code_/src/com	line 5	Java Problem

Perhaps, some special settings for warnings be in place for this to show up ? 



Comment 3 Robert Munteanu CLA 2009-01-22 06:38:12 EST
(In reply to comment #2)
> Perhaps, some special settings for warnings be in place for this to show up ?

In the preferences, please set Java -> Compiler -> Errors/Warnings -> Unnecessary code -> Unused imports to 'Warning'
Comment 4 Srikanth Sankaran CLA 2009-01-22 06:49:29 EST
(In reply to comment #3)
> (In reply to comment #2)
> > Perhaps, some special settings for warnings be in place for this to show up ?
> In the preferences, please set Java -> Compiler -> Errors/Warnings ->
> Unnecessary code -> Unused imports to 'Warning'

I had assumed that this setting was indeed set to 'Warning' since I had noticed
that if I change the test case to // comment out the line containing the SuppressWarnings annotation, I do get a warning about unused static imports.

Anyways, I have double checked now that this setting *is* set to Warning.

Do you have happen to have any other versions of eclipse lying around that you can quickly check against ? Any of the 3.5 milestone builds of recent vintage ?





Comment 5 Robert Munteanu CLA 2009-01-22 07:48:24 EST
Does not show up in I20081211-1908
Comment 6 Srikanth Sankaran CLA 2009-01-22 22:20:43 EST
(In reply to comment #5)
> Does not show up in I20081211-1908

Thanks. That is 3.5 M4 build (latest). For closing this as not reproducible, personally I would feel more comfortable if I have a version where it fails and the HEAD version where it passes and then to track the difference down to an intermediate change (either intended or otherwise).

I'll ask my team mates and see if any one is able to reproduce it.

At a minimum, I can add your test case to the test harness.

 

Comment 7 Srikanth Sankaran CLA 2009-01-23 01:02:11 EST
Created attachment 123481 [details]
Junit Test 


Test to make sure that alleged warning is not issued. This test passes on HEAD as of now without any attendant code change.
Comment 8 Srikanth Sankaran CLA 2009-01-23 01:28:35 EST
Created attachment 123483 [details]
Test patch for 3.4 maintenance branch


This test passes on 3.4 top of branch without any attendant code changes. In the event, the defect stays unreproducible, we may as well add the test to 3.4
Comment 9 Philipe Mulet CLA 2009-01-23 04:05:08 EST
Re: comment 6
>At a minimum, I can add your test case to the test harness.
Very good. Adding a regression test to a closed bug is important, even if we cannot reproduce it (so that we wouldn't start seeing it occur in the future)
Comment 10 Philipe Mulet CLA 2009-01-23 04:19:54 EST
Re: patch in comment 7
We normally number our tests in sequence (it should be numbered test267). Also we try to sort all methods alphabetically.
Comment 11 Philipe Mulet CLA 2009-01-23 04:20:30 EST
Released test for 3.5M5.
Closing as invalid.
Comment 12 Kent Johnson CLA 2009-01-27 10:53:05 EST
Verified for 3.5M5 using I20090126-1300