Bug 216277 - Factorize JavaCore/CompilerOptions constants or else provide a safeguard against potential mismatches
Summary: Factorize JavaCore/CompilerOptions constants or else provide a safeguard agai...
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4   Edit
Hardware: PC All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-23 09:15 EST by Maxime Daniel CLA
Modified: 2011-03-29 09:14 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maxime Daniel CLA 2008-01-23 09:15:48 EST
Source based, v_833.

When I released the first patch for bug 100278, it contained a typo for the literal value of JavaCore.COMPILER_PB_UNUSED_DECLARED_THROWN_EXCEPTION_INCLUDE_UNCHECKED_EXCEPTIONS, introducing a mismatch with CompilerOptions.OPTION_ReportUnusedDeclaredThrownException, and consequently an errant behavior when looked at from the API users standpoint.

The simplest thing to do would be to initialize one of the constants series from the other's values. Since we do not want compiler to depend upon model, it would have to be the JavaCore constants initialized using the CompilerOptions ones. One issue with this is that then the resulting literal value would no more be displayed closed to the JavaCore constant. The remedy to this could come from bug 202490 and related ones (in that the literal value would then be explicit in the javadoc for the constant, lowering the need to display it in the code). Note that some means should be put in place anyway to test that the javadoc remains in sync with the literal value itself...
Comment 1 Philipe Mulet CLA 2008-01-23 09:33:36 EST
That would be good. Some test using reflect or so could be used.
Along the same lines, a test ensuring that PublicScanner is really a clone of Scanner would be good as well.