Bug 181682 - JavaConventions.validateJavaTypeName should list valid constants
Summary: JavaConventions.validateJavaTypeName should list valid constants
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.6 M5   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-09 21:05 EDT by Cameron Bateman CLA
Modified: 2010-01-25 02:03 EST (History)
3 users (show)

See Also:


Attachments
Proposed fix (1.98 KB, patch)
2009-12-09 12:08 EST, 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 Cameron Bateman CLA 2007-04-09 21:05:38 EDT
The deprecated version of the method internally calls the new version using as arguments CompilerOptions.VERSION_1_3 for the source and compliance level.  This is the indication as to what an API client should pass for these values since there is no documentation to this effect (!!).

Non-internal constants and better docs are required on this method to make the API usable.
Comment 1 Jerome Lanneluc CLA 2007-04-10 05:01:31 EDT
Actually, JavaCore#VERSION_x_y should be used. But I agree that the Javadoc is not clear on this point. Changing bug title to reflect real problem.
Comment 2 Cameron Bateman CLA 2007-04-10 14:48:54 EDT
It would also be a good idea to change the constant used in the deprecated method to use this constant.  When I do deprecation updates I usually follow whatever migration strategy is adopted inside the deprecated method (why I initially used the wrong consts).
Comment 3 Olivier Thomann CLA 2009-12-09 12:08:15 EST
Created attachment 154131 [details]
Proposed fix
Comment 4 Olivier Thomann CLA 2009-12-10 10:57:13 EST
Released for 3.6M5.
Verification needs to be done by checking the javadoc.
Comment 5 Srikanth Sankaran CLA 2010-01-25 02:03:16 EST
Verified for 3.6M5 by code inspection.