#64 Java 1.5 support

closed
None
5
2012-10-10
2004-08-21
Michael Studman
No

Hi.

I've attached a patch that adds initial support for Java
1.5 source code.

I've implemented the java 1.5 grammar; updated
TokenTypes with the new token types; replaced the 1.4
parser with the 1.5 parser in TreeWalker; and updated
certain checks so that they support 1.5 language
features or at least are less likely to choke on the
new nodes/node positions when they find them.


Here's an overview of the check changes I've done:


General check changes:

  • checks interested in package definitions changed to
    support cases when annotations are present on
    declaration (first child is no longer the package name)

  • many checks applicable to classes have been
    extended to support enum and enum constants; same
    has been done for checks supporting interfaces - now
    support same behaviour on annotations

Specific check changes:

  • LeftCurlyCheck - supports Java 1.5 constructs when
    calculating of correct left curly positions

  • HiddenFieldCheck - supports checking of fields in enum
    and enum constant class blocks

  • FinalClassCheck - ignores enum ctors

  • import checks changed to support static imports:

    • AvoidStarImportCheck
    • IllegalImportCheck
    • ImportOrderCheck
    • RedundantImportCheck
    • UnusedImportsCheck
  • javadoc checks changed to support and check
    javadoc on applicable Java 1.5 constructs:

    • JavadocMethodCheck - checks javadoc of
      annotation fields (which are akin to interface methods)
    • JavadocStyleCheck
    • JavadocTypeCheck - checks enum definitions and
      annotation definitions
    • JavadocVariableCheck - checks enum constants
      (akin to regular class/interface constants)
  • FinalParametersCheck - checks for-each clause
    parameter declarations for finality

  • ModifierOrderCheck - enhanced to check annotations
    (which are, in effect, special types of modifiers) are
    always first in set of modifiers

  • RedundantModifierCheck - enhanced to check
    redundant modifiers on annotation fields


Here's what I think needs to be done next:


  • Thorough examination of exisiting checks/creation of
    supplimental test input source to ensure full Java 1.5
    compatibility in all checks

  • Propose and implement new checks for Java 1.5-
    based coding standards

  • Decide if checkstyle is going to move its own code
    base to use Java 1.5 language features ("eating our own
    dog food", Oliver ;).


Here are some things to remember when
upgrading/testing checks for new language features:


  • PACKAGE_DEF node's first children may be
    ANNOTATION nodes (although this should only happen
    once per package and in the file "package-info.java" - a
    good candidate for the first Java 1.5-specific check, I
    think).

*STATIC_IMPORT's first child is the LITERAL_STATIC
node, then followed by the identifier

  • MODIFIERS node may contain zero or more
    ANNOTATION nodes (possibly interspersed with
    MODIFIER nodes and in any order)

  • LITERAL_FOR node may now have a FOREACH_CLAUSE
    instead of FOR_INIT, FOR_CONDITION & FOR_ITERATOR
    nodes

  • OBJECTBLOCKs have been reused for the body of
    ENUM_DEF, ENUM_CONSTANT_DEF and
    ANNOTATION_DEF nodes so they may no longer hold
    what you expect

  • ENUM_CONSTANT_DEF nodes may not have
    MODIFIERS (but they may have annotations) so if you
    add this to your default/supported node set along with
    other types (CLASS_DEF etc), remember to be prepared
    for the MODIFIERS node to be null.

  • CLASS_DEFs and INTERFACE_DEFs may have a
    TYPE_PARAMETERS node immediately after the name
    IDENT node

  • Generic method invocations Foo.<String>bar() will
    result in a TYPE_ARGUMENTS node situated between
    the "Foo" IDENT node and the "bar" IDENT node. This is
    similar for fully qualified type names in expressions. E.g.
    new com.foo.Bar<String>.SomeInnerClass<Integer> s =
    new com.foo.Bar<String>().new
    SomeInnerClass<Integer>();

  • PARAMETER_DEF nodes may contain a TRIPLE_DOT
    node immediately after the parameter type node.


Regards,
Michael Studman.

Discussion

  • Logged In: YES
    user_id=746148

    I believe this patch is already applied by Michael,
    so I close it.