Bug 37122 - non-existent import flaged as "not used" instead of "not found"
Summary: non-existent import flaged as "not used" instead of "not found"
Status: RESOLVED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows 2000
: P3 minor (vote)
Target Milestone: 3.0 M1   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-04-30 22:43 EDT by David Williams CLA
Modified: 2003-06-02 06:12 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Williams CLA 2003-04-30 22:43:06 EDT
For a "wild card" import, e.g. import com.xyz.*;
if the package com.xyz does not exist AND it is not used in the class, it is 
flagged merely as "not used". 
Would be better if it was flagged as error "not found", since other compilers 
will fail when it is indeed not found. 
I list as minor, since user preferences can be set to flag "not used" as error, 
instead of warning, but ... that isn't quite the same.
Comment 1 Dirk Baeumer CLA 2003-05-02 04:28:00 EDT
Moving to Core
Comment 2 Philipe Mulet CLA 2003-05-05 06:55:11 EDT
import com.xyz.*; 
is properly reported as non-resolved import for me using R2.1 as I would expect.
Can you provide more steps to reproduce it ? Are you sure that such a package 
exists on your filesystem ?
Comment 3 David Williams CLA 2003-05-05 09:41:17 EDT
Yes, I think you're right. I originally had, say, two packages, com.xyz; and 
com.xyz.abc; (and wasn't using either, but had a left over import com.xyz.*;). 
Then I deleted com.xyz; but left com.xyz.abc; I think maybe it was the other 
compiler that was in error in telling me that com.xyz.*; could not be resolved, 
since com.xyz.abc; did still exist. Or maybe its one of those spec ambiguities. 
Thanks for looking at it. 
Comment 4 Philipe Mulet CLA 2003-05-06 07:40:30 EDT
We indeed will treat empty folder as packages where others will only do so when 
it contains a first unit. But this is a separate issue for which we already 
have a bug report. I think our behavior makes more sense though.

Closing