Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/pmd/pmd/issues/1207 below:

[java] Resolve explicit types using FQCNs, without hitting the classloader · Issue #1207 · pmd/pmd · GitHub

Many types are completely explicit in Java given the info that's present in the source file. These includes types in an extends/ implements clause, import statements, method and constructor formal parameter types, wildcard bounds, return types, (non-var) local variable types, etc. Even though the actual .class files may not be on our auxclasspath, we can resolve the qualified name of these in most cases, which could enhance the robustness of our type resolution when the auxclasspath is not set.

The key would be to build some part of our type resolution around TypeQualifiedNames.

• I think we could have a subclass of JavaTypeDefinition that wraps a TypeQualifiedName instead of necessarily a Class. For most operations of this class, we don't need a Class object anyway, since we return other type definitions for example.
• A clean solution would need a specialised data structure to resolve qualified names from simple names. This would declutter ClassTypeResolver, which mixes that logic with the rest for now, and sync our implementations
  • We could have a procedure that uses the import declarations, package declaration, and type declarations of the file to build this data structure and attach it to the compilation unit node.
  • That data structure could, given the simple name of a type, determine whether
    1. we can unambiguously resolve it to a FQCN, then it returns it
    2. we don't have enough info to resolve it unambiguously (e.g. in the presence of several wildcard import statements and no correct auxclasspath)
  • We could reuse that implementation in UnnecessaryFQCN, which currently takes its own decisions ad-hoc. With such a "TypeScope", UnnecessaryFQCN could be simply formulated as:
    • For each FQCN n in the file with simple name s,
      • if TypeScope(s) equals n, then add a violation
• Using simple lookups to that data structure, the QualifiedNameResolver could then populate the unambiguous types it finds with a type definition that wraps a qualified name.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4