Code Monkey home page Code Monkey logo

pmd-jpinpoint-rules's People

Contributors

clanghout avatar dependabot[bot] avatar jangroot avatar jborgers avatar peterpaul-perfana avatar stokpop avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

pmd-jpinpoint-rules's Issues

Request for new rule: AvoidTimeUnitConfusion

Use unit like milliseconds or seconds in the name of time quantities like timeout, expirytime, timeToLive, to avoid confusion and errors about units.
For variable names and @value members

example:
bad:
@Autowired
public RetrieveCache(final @value("${cache.expiryTime}") long timeToLive) {
super(timeToLive);
}
good:
@Autowired
public RetrieveCache(final @value("${cache.expiryTimeSeconds}") long timeToLiveSeconds) {
super(timeToLiveSeconds);
}

Request for new rule: NotProperlySynchronizingOnFieldWhileUsingGuardedBy

Similar to NotProperlySynchronizingOnThisWhileUsingGuardedBy, see #43
Now for the field case.
Examples:

   import net.jcip.annotations.GuardedBy;
   class Bad1 {
        private final Object LOCK = new Object();
        @GuardedBy("LOCK")
        private String txt;

        public String getText() { return txt; } // bad
        public synchronized void setText(String t) { txt = t; } // bad
    }

    import net.jcip.annotations.GuardedBy;
    class Good1 {
        private final Object LOCK = new Object();
        @GuardedBy("LOCK")
        private String txt;

        public String getText() {
            synchronized(LOCK) { return txt; }
        }
        public void setText(String t) {
            synchronized(LOCK) { txt = t; }
        }
    }

Request for fix: AvoidImplicitelyRecompilingRegex String.split on external field

AvoidImplicitelyRecompilingRegex String.split fires on long regex, literals or by fields.
External fields, from other classes, cannot be checked and currently fire a violation. This can be a false positive. We want to avoid false positives, so external fields should be assumed not to be a problem.
Example:

public class Try {
    private static final String SMALL = "-.";
    private static final String LARGE = "------.-";
    public static void foo(String query) {
        query.split(Constants.SEP); //assumed good, external
        query.split(SMALL); //good
        query.split(LARGE); //bad
    }
}

Request for new rule: AvoidStaticXmlFactories

An XML Factory like DocumentBuilderFactory, TransformerFactory, MessageFactory is used as static field.

Problem: These factory objects are typically not thread-safe and rather expensive to create because of class loading.

Solution: Create the Factories as local variables and use command line arguments to specify the implementation class.

public class Bad1 {
private static final DocumentBuilderFactory DB_FACTORY = DocumentBuilderFactory.newInstance(); // bad
private static SAXParserFactory sp_factory; // bad
static MessageFactory M_FACTORY; // bad
static final TransformerFactory T_FACTORY = TransformerFactory.newInstance(); // bad
protected static final XMLInputFactory XI_FACTORY = XMLInputFactory.newInstance(); //bad
static XMLOutputFactory XO_Factory; //bad
static XMLEventFactory XE_Factory; //bad
static DatatypeFactory DT_Factory; //bad

SchemaFactory S_FACTORY = SchemaFactory.newInstance(); // good
private static CustomerFactory C_FACTORY; // good

public static void build() {
    DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance(); // good
    // use dbFactory
}

}

class CustomerFactory {
}

Request for extension: AvoidMutableStaticFields: support for static block

Static blocks are not yet supported, they should. Tests:

class Formatted {
private static final String[] names_violate;
private static final String[] names_ok;
private static final ThreadLocal[] FORMATTERS;
private static final String[] nonEmptyViolate;
private static final String[] emptyOk;
private static final Map mapOk;
private static final Map mapViolate;
@GuardedBy("lock")
private static final Map mapOkGuarded;
private static final ConcurrentMap mapSafe;

static {
    names_violate = new String[]{"aap", "noot", stringViolate1}; //bad
    names_ok = new String[]{};
    FORMATTERS = new ThreadLocal[NUMBER_OF_FORMATTERS]; //bad
    emptyOk = new String[0];
    nonEmptyViolate = new String[5]; // bad
    mapOk = Collections.emptyMap();
    mapViolate = new HashMap(); // HashMap is known mutable type // bad
    mapOkGuarded = new HashMap();
    mapSafe = new ConcurrentHashMap();
}

}

Request for false-positive fix: Exclude class annotated with @ConfigurationProperties from thread-safety rules

When using @ConfigurationProperties(prefix="") to inject configuration properties into a Spring-Boot application, Sonar returns the pmd:AvoidUnguardedAssignmentToNonFinalFieldsInSharedObjects warning. Since the setters of this class are only called once, this kind of thread-safety rules are not necessary in these cases and classes with this annotation can be excepted from this rule.
Kind regards,
Stijn Schmeink

Request for fix: False positive in pmd:MinimizeAttributesInSession

When calling method setAttribute on a class which is not an HttpSession, pmd:MinimizeAttributesInSession is still triggered resulting in a false positive. Possible cause is a literal scan for the method setAttribute without checking if it is actually called on an HttpSession.

Request for rule: Avoid expression in Spring Cacheable

Spring Expression Language (SpEL) expression is used for computing the key dynamically. Problem: evaluating the expression language is expensive, on every call.
Solution: use a custom KeyGenerator: keyGenerator=... instead of key=...

example:
class Bad1 {
@Cacheable(value = "Cache1", key = "#key1") // bad
public String bad1(final String key1) {
return getRemote(key1);
}
}

Create a rule that violates on improper annotation combinations

Make a rule that violates on annotation combinations that make no sense, like @ Data and @ EqualsHashCode (lombok); @ Configuration and @ Component (spring); @ Entity and @ Component (spring).

When analyzing violations of concurrency checks and equals-hashCode checks, it turned out some were false positives because code had wrong annotation combinations. So, these combinations should be correct, hence this rule.

Request for fix: False positive AvoidSpringMVCMemoryLeak

This code gives a false positive, please fix:

@RequestMapping(value = "/info/all", method = RequestMethod.GET)
public ResponseEntity agentInfoAll() {
    String result = getAllServers()
            .stream()
            .filter(server -> !server.startsWith(GROUP_OF_SERVERS_PREFIX))
            .map(server -> {
                CompletableFuture<ResponseEntity<String>> futureResponse =
                        CompletableFuture.supplyAsync(() -> agentClient.pingAgent(server), executor);
                ResponseEntity<String> response = futureResponse
                        .handle((res, ex) -> (res != null) ? res : ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body("Error pinging server: " + ex.getMessage()))
                        .join();
                return server + " : " + buildStatus(response) + "\n" + response.getBody() + "\n\n";
            })
            .collect(Collectors.joining());

    return ResponseEntity.ok().contentType(MediaType.TEXT_PLAIN).body(Pattern.compile("\n{2,}").matcher(result).replaceAll("\n\n"));
}

Make test classes map 1:1 on rules

Most Test classes have test cases code for one rule. Some Test classes contain code for multiple rules. Convert that to one Test class for each rule for clarity. In addition, make sure testClassName = ruleName + "Test"

AvoidApacheCommonsFileItemNonStreaming: improve rule definition

A number of improvements here:
Rules using type resolution should declare the attribute typeResolution="true" in the element.
I’d drop the [ancestor::CompilationUnit/ImportDeclaration/Name[starts-with(@image,'org.apache.commons.fileupload')]] check… we have type resolution to match types, and it should work even if using a fully qualified name instead of an import (a test case is missing here)
The first 2 start-with can probably me merged together by searching for ancestor:: MethodDeclaration//Type/…. This part will be simpler with the changes we are introducing to PMD 7, but in the meantime your approach is correct.
I see you added (jpinpoint-rules) to all rule’s description, but without context it will probably be confusing to users trying to understand what the problem is with their code… remember this will appear in both the report and on the online docs for the rule. What do you think?

Request for 2 new rules: Detecting @SuppressWarnings

Often critical rules are suppressed because they are not well understood by developers. We want to detect it when rules which can detect high risks problems are suppressed. False positives should be fixed in the rule. These rules are informative and not to break builds, so be on minor level. In addition we want to detect all suppressed rules. So, two rules:

  • UsingSuppressWarnings
  • UsingSuppressWarningsHighRisk

Request for new rule: check for synchronizing correctly when using @GuardedBy("this") on field

Request for new rule: check for synchronizing correctly when using @GuardedBy("this") on field.
Rule: NotProperlySynchronizingOnThisWhileUsingGuardedBy

Example tests:

class Bad1 {
        @GuardedBy("this")
        private String txt;

        public String getText() {
            return txt; // bad
        }
        public void setText(String t) {
            txt = t; // bad
        }
 }
 class Good1 {
        @GuardedBy("this")
        private String txt;

        public synchronized String getText() {
            return txt;
        }
        public synchronized void setText(String t) {
            txt = t;
        }
 }

Request for new rule: Synchronize For Key In @Cacheable with sync = "true"

The cache by default allows multiple threads accessing by the same key.

Problem: if the value of the key is not available from the cache, it will be fetched/computed by multiple threads while only one time is needed.

Solution: Let only the first accessing thread fetch/compute the value and block others until the value is in the cache. Add attribute sync = "true" to achieve this. (Assuming the cache implementation supports it.)

Improve rule definitions for PMD: AvoidCalendarDateCreation, AvoidConcatInAppend and AvoidConcatInLoop

A.o. add examples, standardize attribute usage, correct link.
Investigate:
For the concat rules, they don't seem to consider string literals in a special way… when writing "foo" + "bar", the compiler will do the concat in compile time, so there is no real performance penalty (same happens for final strings initialized upon declaration, but that one is way harder to detect under the current XPath support; and I'm unsure, but probably Java 8+ does the same for effectively final variables).

False positive on AvoidImplicitlyRecompilingPatterns for replaceAll

If the first argument to String replaceAll isn't actually a regex, it still reports a violation.
Checking String.split is fixed for this case. Checking other methods should be fixed as well, where applicable.

Test case from project code:

    public final static String PAYLOADDATA = "PAYLOADDATA";
    private String stringReplaceAllNonRegexOK() {
        String result = "some xml data with [PAYLOADDATA]";
        StringBuilder payloadData = new StringBuilder("some payload");
        result = result.replaceAll(PAYLOADDATA, payloadData.toString());
        return result;
    }

Request for new rule: AvoidUnguardedMutableInheritedFieldsInSharedObjects

If fields of singletons (@component) are used unguarded, this is thread-unsafe, or may mixup session data.
A special more hidden case is when a @component inherits its fields from an ordinary class (no @component), that fields cannot be checked. At declaration point it is not known to be a @component.
We have covered assignments to inherited fields.
We cannot detect ordinary use of those fields because they may be immutable/unmodifyable.
We can check for mutating methods.

We assume methods starting with:
add, set, put, clear, remove, replace
mutate the object. Detect those for this new rule.

Request for rule enhancement: UnconditionalStringOperationOnLogArgument not just String operations

Enhance rule with calling an operation, examples:
bad:

LOG.debug("Complete Soap response: {}", getSoapMsgAsString(context.getMsg())); // bad

good:

if (LOG.isDebugEnabled()) { // good
    LOG.debug("Complete Soap response: {}", getSoapMsgAsString(context.getMsg()));
}

To avoid too many false positives, we require one or more arguments for the operation. Also we exclude simple obj.get(arg) calls, like list.get(0) and map.get(key) which are typically fast.

Rule should be renamed to 'UnconditionalOperationOnLogArgument' ('String' removed.)

Request for 2 new rules for detecting concurrency bugs

After extensive investigation we found a concurrency bug in vendor platform code of a online store. It lead to a memory leak which caused costly downtime. We want these kinds of bugs to be found with new rules.

We have two rules for use of unguarded fields and assignments to it for shared objects. We can extend these rules for objects using synchronized in one or another way. Synchronized is meant for multi-threaded context, so it is shared by threads and the object itself should be thread-safe. I think this applies for most common/typical cases. So fields should be properly guarded and assignments to it should be guarded.
Names:

  • AvoidUnguardedMutableFieldsInObjectsUsingSynchronized
  • AvoidUnguardedAssignmentToNonFinalFieldsInObjectsUsingSynchronized

Request for new rule: HttpClients should have disabled connection state

HttpClients should have disabled connection state to reuse TLS connections. In cloud environment sessions are not sticky and connections are stateless. HttpClients should be configured to disable connection state, otherwise TLS connections will not be reused and performance will suffer.

Correct:

return HttpClientBuilder.create()
                .setConnectionManager(conMgr)
                .disableConnectionState()
                .build();

Also support

HttpClients.custom()
HttpAsyncClientBuilder

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.