Working with plain Java projects that use OT-keywords as identifiers

[stephan]

It should be possible to use the OTDT also with plain Java projects that use OT keywords as identifiers. At least two levels of compatibility can be identified:

• browsing through plain Java jars where a package fragment "team" breaks the Java Model (packages appear as non-java folders, rather than as packages)
• compiling plain Java projects where all kinds of usages occur.

Currently, the OT/J compiler never accepts "team" and "within" as identifiers.

For building this could be done by the builder or by checking for the project nature "OTJavaNature". However, other clients like content assist, reconciler, etc. pp. need to be checked, too.

We'd need to check all locations that instantiate Scanner and see if they have sufficient information to switch between Java and OT/J modes.

[stephan]

r21800 makes the Scanner more configurable:

• support parsePureJavaOnly which completely disables all OT keywords

[stephan]

r21801 brings first usages of new flag from r21800:

• package explorer now recognizes packages with "team" in their name
• new package/type wizards also accept "team" as part of a package name
• other clients should benefit, too

[stephan]

r21802 adds implicit configuration for pure java scanning/parsing:

• CompilerOptions keep as option (not user configurable)
• JavaProject configures the option from the existance of an "OTJavaNature"
• many other classes to pass this bit along from project options to scanners (mainly the exact same data flows as for allowScopedKeywords)

TODO: now all non-OT projects store project specific settings. We should filter the pureJava setting when saving (and thus avoid saving if it's the only project specific setting).

TODO: 2 clients remain unconfigured due to lack of context:

• ASTRewrite#internaRewriteAst()
• ASTRewriteFormatter#formatNode()

These worked also prior to this patch:

• UI-level support is already fine with r21801.
• package and import declarations where already handled as a special case in the Scanner

This is new with this patch:

• using package names with "team" within the code (i.e., using fully qualified class names)
• using "team" and "within" as an identifier (variable, method, even class)

This should pretty much resolve the issue, just leaving it open to await test results and for checking the to TODOs above.

[stephan]

Tests pass, the remaining TODOs do not appear to be essential, closing.

[stephan]

Addendum:

• refactoring still can't handle OT-keywords used as identifiers, see org.eclipse.jdt.ui.tests.refactoring.ChangeSignatureTests.testGenerics04()

In order to support such scenarios, this method

org.eclipse.jdt.internal.corext.util.JavaConventionsUtil.validateIdentifier(String, IJavaElement)

would need to check the enclosing project of the IJavaElement to see if it has the OTJavaNature.

Deferring since this cannot be handled within the jdt/core, but requires help from the refactoring.adaptor. Sounds like overkill for now.