PMD is a static source code analyzer. It finds common programming flaws like
+unused variables, empty catch blocks, unnecessary object creation, and
+so forth. It’s mainly concerned with Java and Apex, but supports six other
+languages.
+
+
PMD features many built-in checks (in PMD lingo, rules), which are documented
+for each language in our Rule references. We
+also support an extensive API to write your own rules,
+which you can do either in Java or as a self-contained XPath query.
+
+
PMD is most useful when integrated into your build process. It can then be
+used as a quality gate, to enforce a coding standard for your codebase. Among other
+things, PMD can be run:
The rest of this page exposes the contents of the documentation site thematically,
+which you can further scope down using the blue filter buttons. To navigate the site,
+you may also use the search bar in the top right, or the sidebar on the left.
This page demonstrates how you the integration of a script called ScrollTo, which is used here to link definitions of a JSON code sample to a list of definitions for that particular term. The scenario here is that the JSON blocks are really long, with extensive nesting and subnesting, which makes it difficult for tables below the JSON to adequately explain the term in a usable way.
+{
+ "apples": "red fruit at the store",
+ "bananas": "yellow bananas in a bunch",
+ "carrots": "orange vegetables that grow in the ground",
+ "dingbats": "a type of character symbol on a computer",
+ "eggs": "chickens lay them, and people eat them",
+ "falafel": "a Mediterranean sandwich consisting of lots of different stuff i don't know much about",
+ "giraffe": "tall animal, has purple tongue",
+ "hippo": "surprisingly dangerous amphibian",
+ "igloo": "an ice shelter made by eskimos",
+ "jeep: "the only car that starts with a j",
+ "kilt": "something worn by scottish people, not a dress",
+ "lamp": "you use it to read by your bedside at night"
+ "manifold": "an intake mechanism on a car, like a valve, i think",
+ "octopus": "eight tentacles, shoots ink, lives in dark caves, very mysterious",
+ "paranoia": "the constant feeling that others are out to get you, conspiring against your success",
+ "qui": "a life force that runs through your body",
+ "radical": "someone who opposes the status quo in major ways",
+ "silly": "how I feel writing this dummy copy",
+ "taffy": "the sweets children like the most and dentists hate the worst",
+ "umbrella": "an invention that has not had any advancements in 200 years",
+ "vampire": "a paranormal figure that is surprisingly in vogue despite its basic nature",
+ "washington": "the place where tom was born",
+ "xylophone": "some kind of pinging instrument used to sound chime-like notes",
+ "yahoo": "an expression of exuberance, said under breath when something works right",
+ "zeta": "the way british people pronounce z",
+ "alpha": "the original letter of the alphabet, which has since come to mean the first. however, i think the original symbol of alpha is actually an ox. it is somewhat of a mystery to linquists as to the exact origin of the letter alpha, but it basically represents the dawn of the alphabet, which proved to be a huge step forward for human thought and expression.",
+ "beta": "the period of time when something is finished but undergoing testing by a group of people.",
+ "cappa": "how italians refer to their baseball caps",
+ "dunno": "informal expression for 'don't know'"
+ }
+
+
+
+
+
+
+
+
+
+
+
+
apples
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer magna massa, euismod sed rutrum at, ullamcorper quis tellus. Vestibulum erat purus, aliquet sit amet pellentesque eget, tempus at ante. Nulla justo nisi, elementum nec nisi eget, consectetur varius tortor.
+
+
bananas
Curabitur quis nibh sed eros viverra tempus et quis lorem. Nulla convallis sit amet risus vitae rutrum. Nulla at faucibus lectus. Pellentesque tortor nisl, interdum ac quam non, egestas congue massa. Vestibulum non porttitor lacus. Nam tincidunt arcu lectus. Donec eget ornare neque, hendrerit ornare lectus. In ac pretium odio.
+
+
carrots
Vivamus pulvinar vestibulum pharetra. Vivamus vitae diam iaculis, posuere mi sed, dignissim massa. Nunc vitae aliquet urna. Proin sed pulvinar ex. Maecenas nisl lorem, rutrum sit amet hendrerit sed, posuere at odio. Sed consectetur semper tristique. Vivamus finibus varius felis at convallis. Fusce in dictum nunc.
+
+
dingbats
Curabitur feugiat lorem eget elit ullamcorper tincidunt. In euismod diam aliquet tortor fermentum tempor. Fusce quam felis, commodo viverra orci vitae, scelerisque aliquet risus.
+
+
eggs
Duis est nunc, fringilla eu ligula et, varius dignissim dui. Vivamus in tellus vitae ipsum vehicula fermentum at congue tellus. Suspendisse fermentum, magna vitae aliquet sodales, tellus nisi rutrum arcu, vitae auctor dolor quam ac tellus. Cras posuere augue erat, in sagittis quam lacinia id.
+
+
falafel
Praesent auctor a enim non lacinia. Integer sodales aliquet mi vel dapibus. Donec consequat justo eget nisi lacinia, eu sodales ligula molestie. Sed sapien nulla, rhoncus at elementum a,
+
+
giraffe
Nullam venenatis at lectus sed pharetra. Sed hendrerit ligula lectus, non pellentesque diam faucibus sit amet. Aliquam dictum hendrerit pellentesque. Cras eu nisl sagittis, faucibus velit sit amet, sagittis odio. Donec vulputate ex vitae purus
+
+
hippo
Cras nec pretium nulla. Suspendisse tempus tortor vel venenatis pulvinar. Integer varius tempor enim fringilla tincidunt. Phasellus magna turpis, auctor vitae elit eget, fringilla pellentesque est. Phasellus ut porta risus. Curabitur iaculis sapien sed venenatis auctor. Integer eu orci at lectus eleifend auctor id rutrum urna.
+
+
igloo
Suspendisse tempus tortor vel venenatis pulvinar. Integer varius tempor enim fringilla tincidunt. Phasellus magna turpis, auctor vitae elit eget, fringilla pellentesque est. Phasellus ut porta risus.
+
+
jeep
Nulla vitae metus rutrum, condimentum orci nec, maximus est. Aenean sit amet ante nec elit dignissim faucibus eget quis quam.
+
+
kilt
Morbi maximus, erat vel rhoncus sagittis, dolor purus dignissim ante, sit amet pharetra ex justo vitae ipsum. Nulla consequat interdum neque
+
+
lamp
Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Mauris aliquam dapibus blandit. Donec porta, enim hendrerit venenatis vulputate, orci diam lacinia nibh, faucibus rutrum dolor dui ut quam.
+
+
manifold
Donec finibus massa vel nisi ullamcorper, vitae ornare enim euismod. Aliquam auctor quam erat. Duis interdum rutrum orci, ac interdum urna pharetra eget.
+
+
octopus
Nulla id egestas enim. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse potenti. Curabitur eu lobortis ligula.
+
+
paranoia
Aenean hendrerit mauris ipsum, non laoreet ipsum luctus vel. Curabitur tristique auctor elit ut pulvinar. Quisque arcu arcu, condimentum aliquam sodales nec, dignissim nec justo. Nunc tristique sem felis, pharetra euismod lorem volutpat sed. Ut porttitor metus sit amet elit rhoncus semper.
+
+
qui
Quisque rhoncus cursus felis vel elementum. Vestibulum dignissim molestie tortor nec facilisis. Praesent a nibh condimentum, porta nulla egestas, auctor eros
+
+
radical
Etiam hendrerit interdum tellus, at aliquet sapien egestas in. Aenean eu urna nisl. Cras vitae risus pharetra, elementum mauris nec, auctor lectus. Fusce pellentesque venenatis dictum. Proin at augue at mauris finibus semper ultricies sed eros.
+
+
silly
Praesent pulvinar consequat posuere. Morbi egestas rhoncus felis, id fermentum metus lobortis in. Vestibulum nibh orci, euismod eget vestibulum nec, vehicula vitae tortor. Aenean ullamcorper enim nunc, eu auctor ligula auctor eget.
+
+
taffy
Etiam et arcu vel lacus aliquet lobortis in in massa. Nunc non mollis elit. Aenean accumsan orci quis risus aliquam, non gravida nulla molestie. Mauris pharetra libero et magna aliquam aliquam. Integer quis luctus dolor.
+
+
umbrella
Fusce molestie finibus malesuada. Nullam ac egestas quam, id venenatis ligula. Pellentesque pulvinar elit et vestibulum fringilla. Cras volutpat sed quam ornare scelerisque. Vivamus volutpat ante pretium scelerisque tempus. Etiam venenatis tempor nisl dignissim sollicitudin. Curabitur ac risus vitae dolor pretium posuere vel vitae diam. Donec in odio arcu.
+
+
vampire
Vestibulum pretium condimentum commodo. Integer placerat leo non ipsum ultrices, ac convallis elit varius. Vestibulum ultricies, justo eu rutrum molestie, quam arcu euismod sapien, vel gravida ipsum nulla eget erat.
+
+
washington
Nunc ac quam eu risus dictum sodales. Nam ac risus iaculis, aliquet sem eu, mollis mauris. Curabitur pretium facilisis orci ut lacinia. Sed fermentum leo a odio blandit rutrum. Phasellus at nibh vel odio interdum vulputate ac eget urna. Nam eu arcu dapibus, sodales ligula nec, volutpat ipsum. Suspendisse auctor tellus vitae libero euismod venenatis.
+
+
xylophone
Sed molestie lobortis ante sit amet hendrerit. Sed pharetra nisi sed interdum pulvinar. Nunc efficitur erat non aliquam mattis. Sed id nisl mattis lacus vehicula volutpat vitae vel massa. Curabitur interdum velit odio, vitae sollicitudin nunc rutrum non.
+
+
yahoo
Nunc commodo consectetur scelerisque. Proin fermentum ligula ac quam finibus tincidunt. Aenean venenatis nisi et semper semper. Nunc sodales velit ipsum, ac pellentesque augue placerat eu.
+
+
zeta
Nullam ac suscipit odio. Curabitur viverra arcu ut egestas sollicitudin. Fusce sodales varius lectus ut tristique. Etiam eget nunc ornare, aliquet tortor eget, consequat mauris. Integer sit amet fermentum augue.
+
+
alpha
Praesent nec neque ac tellus sodales eleifend nec vel ipsum. Cras et semper risus. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Integer mattis leo nisl, a tincidunt lectus tristique eget. Donec finibus lobortis viverra. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Vivamus egestas pulvinar odio non vehicula. Morbi malesuada leo eget nisl sagittis aliquet.
+
+
+
beta
Mauris a libero vel enim pharetra interdum non a quam. Sed tincidunt ut elit sed dignissim. Suspendisse vitae tellus dapibus, fermentum lacus ac, fermentum lacus. Nam ante odio, fringilla ac elementum a, mollis sed tellus.
+
+
cappa
Nam molestie semper nulla et molestie. Ut facilisis, ipsum sed convallis posuere, mi mauris bibendum erat, nec egestas ipsum est nec dolor.
+
+
dunno
Etiam et metus congue, commodo libero et, accumsan sem. Aliquam erat volutpat. Quisque tincidunt, tortor non blandit ullamcorper, orci mauris dignissim augue, eget vehicula nulla justo sed dolor. Nunc ac urna quis nisi maximus pharetra in a mauris. Proin metus mi, venenatis vitae tristique sed, fermentum at purus. Aliquam erat volutpat. Maecenas efficitur sodales nibh, ac hendrerit felis facilisis et. Interdum et malesuada fames ac ante ipsum primis in faucibus.
+
+
+
+
+
+
+
+
+
+
Note: This was mostly an experiment to see if there was a better way to document a long JSON code example. I haven't actually used this approach in my own documentation.
+
+
+
+
+
+
+
+ Tags:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/js/toc.js b/js/toc.js
new file mode 100644
index 0000000000..a54d172efc
--- /dev/null
+++ b/js/toc.js
@@ -0,0 +1,82 @@
+// https://github.com/ghiculescu/jekyll-table-of-contents
+(function($){
+ $.fn.toc = function(options) {
+ var defaults = {
+ noBackToTopLinks: false,
+ title: '',
+ minimumHeaders: 3,
+ headers: 'h1, h2, h3, h4',
+ listType: 'ol', // values: [ol|ul]
+ showEffect: 'show', // values: [show|slideDown|fadeIn|none]
+ showSpeed: 'slow' // set to 0 to deactivate effect
+ },
+ settings = $.extend(defaults, options);
+
+ var headers = $(settings.headers).filter(function() {
+ // get all headers with an ID
+ var previousSiblingName = $(this).prev().attr( "name" );
+ if (!this.id && previousSiblingName) {
+ this.id = $(this).attr( "id", previousSiblingName.replace(/\./g, "-") );
+ }
+ return this.id;
+ }), output = $(this);
+ if (!headers.length || headers.length < settings.minimumHeaders || !output.length) {
+ return;
+ }
+
+ if (0 === settings.showSpeed) {
+ settings.showEffect = 'none';
+ }
+
+ var render = {
+ show: function() { output.hide().html(html).show(settings.showSpeed); },
+ slideDown: function() { output.hide().html(html).slideDown(settings.showSpeed); },
+ fadeIn: function() { output.hide().html(html).fadeIn(settings.showSpeed); },
+ none: function() { output.html(html); }
+ };
+
+ var get_level = function(ele) { return parseInt(ele.nodeName.replace("H", ""), 10); }
+ var highest_level = headers.map(function(_, ele) { return get_level(ele); }).get().sort()[0];
+ var return_to_top = '';
+
+ var level = get_level(headers[0]),
+ this_level,
+ html = settings.title + " <"+settings.listType+">";
+ headers.on('click', function() {
+ if (!settings.noBackToTopLinks) {
+ window.location.hash = this.id;
+ }
+ })
+ .addClass('clickable-header')
+ .each(function(_, header) {
+ this_level = get_level(header);
+ if (!settings.noBackToTopLinks && this_level === highest_level) {
+ $(header).addClass('top-level-header').after(return_to_top);
+ }
+ if (this_level === level) // same level as before; same indenting
+ html += "
" + header.innerHTML + "";
+ else if (this_level <= level){ // higher level than before; end parent ol
+ for(i = this_level; i < level; i++) {
+ html += "
"
+ }
+ html += "
" + header.innerHTML + "";
+ }
+ else if (this_level > level) { // lower level than before; expand the previous to contain a ol
+ for(i = this_level; i > level; i--) {
+ html += "<"+settings.listType+">
This product is licensed under a “BSD-style” license; see below for the full text.
+
+
Part of this product (mostly the package net.sourceforge.pmd.lang.vm)
+is licensed under the Apache License, Version 2.0;
+see below for the full text.
+
+
BSD-style license
+
+
+Copyright (c) 2002-2009, InfoEther, Inc
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are
+met:
+
+ * Redistributions of source code must retain the above copyright
+ notice, this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+ * The end-user documentation included with the redistribution, if
+ any, must include the following acknowledgement:
+ "This product includes software developed in part by support from
+ the Defense Advanced Research Project Agency (DARPA)"
+ * Neither the name of InfoEther, LLC nor the names of its
+ contributors may be used to endorse or promote products derived from
+ this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
+IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
+TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
+PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER
+OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
+PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+
+
Apache License, Version 2.0
+
+
+ Apache License
+ Version 2.0, January 2004
+ http://www.apache.org/licenses/
+
+ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+ 1. Definitions.
+
+ "License" shall mean the terms and conditions for use, reproduction,
+ and distribution as defined by Sections 1 through 9 of this document.
+
+ "Licensor" shall mean the copyright owner or entity authorized by
+ the copyright owner that is granting the License.
+
+ "Legal Entity" shall mean the union of the acting entity and all
+ other entities that control, are controlled by, or are under common
+ control with that entity. For the purposes of this definition,
+ "control" means (i) the power, direct or indirect, to cause the
+ direction or management of such entity, whether by contract or
+ otherwise, or (ii) ownership of fifty percent (50%) or more of the
+ outstanding shares, or (iii) beneficial ownership of such entity.
+
+ "You" (or "Your") shall mean an individual or Legal Entity
+ exercising permissions granted by this License.
+
+ "Source" form shall mean the preferred form for making modifications,
+ including but not limited to software source code, documentation
+ source, and configuration files.
+
+ "Object" form shall mean any form resulting from mechanical
+ transformation or translation of a Source form, including but
+ not limited to compiled object code, generated documentation,
+ and conversions to other media types.
+
+ "Work" shall mean the work of authorship, whether in Source or
+ Object form, made available under the License, as indicated by a
+ copyright notice that is included in or attached to the work
+ (an example is provided in the Appendix below).
+
+ "Derivative Works" shall mean any work, whether in Source or Object
+ form, that is based on (or derived from) the Work and for which the
+ editorial revisions, annotations, elaborations, or other modifications
+ represent, as a whole, an original work of authorship. For the purposes
+ of this License, Derivative Works shall not include works that remain
+ separable from, or merely link (or bind by name) to the interfaces of,
+ the Work and Derivative Works thereof.
+
+ "Contribution" shall mean any work of authorship, including
+ the original version of the Work and any modifications or additions
+ to that Work or Derivative Works thereof, that is intentionally
+ submitted to Licensor for inclusion in the Work by the copyright owner
+ or by an individual or Legal Entity authorized to submit on behalf of
+ the copyright owner. For the purposes of this definition, "submitted"
+ means any form of electronic, verbal, or written communication sent
+ to the Licensor or its representatives, including but not limited to
+ communication on electronic mailing lists, source code control systems,
+ and issue tracking systems that are managed by, or on behalf of, the
+ Licensor for the purpose of discussing and improving the Work, but
+ excluding communication that is conspicuously marked or otherwise
+ designated in writing by the copyright owner as "Not a Contribution."
+
+ "Contributor" shall mean Licensor and any individual or Legal Entity
+ on behalf of whom a Contribution has been received by Licensor and
+ subsequently incorporated within the Work.
+
+ 2. Grant of Copyright License. Subject to the terms and conditions of
+ this License, each Contributor hereby grants to You a perpetual,
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+ copyright license to reproduce, prepare Derivative Works of,
+ publicly display, publicly perform, sublicense, and distribute the
+ Work and such Derivative Works in Source or Object form.
+
+ 3. Grant of Patent License. Subject to the terms and conditions of
+ this License, each Contributor hereby grants to You a perpetual,
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+ (except as stated in this section) patent license to make, have made,
+ use, offer to sell, sell, import, and otherwise transfer the Work,
+ where such license applies only to those patent claims licensable
+ by such Contributor that are necessarily infringed by their
+ Contribution(s) alone or by combination of their Contribution(s)
+ with the Work to which such Contribution(s) was submitted. If You
+ institute patent litigation against any entity (including a
+ cross-claim or counterclaim in a lawsuit) alleging that the Work
+ or a Contribution incorporated within the Work constitutes direct
+ or contributory patent infringement, then any patent licenses
+ granted to You under this License for that Work shall terminate
+ as of the date such litigation is filed.
+
+ 4. Redistribution. You may reproduce and distribute copies of the
+ Work or Derivative Works thereof in any medium, with or without
+ modifications, and in Source or Object form, provided that You
+ meet the following conditions:
+
+ (a) You must give any other recipients of the Work or
+ Derivative Works a copy of this License; and
+
+ (b) You must cause any modified files to carry prominent notices
+ stating that You changed the files; and
+
+ (c) You must retain, in the Source form of any Derivative Works
+ that You distribute, all copyright, patent, trademark, and
+ attribution notices from the Source form of the Work,
+ excluding those notices that do not pertain to any part of
+ the Derivative Works; and
+
+ (d) If the Work includes a "NOTICE" text file as part of its
+ distribution, then any Derivative Works that You distribute must
+ include a readable copy of the attribution notices contained
+ within such NOTICE file, excluding those notices that do not
+ pertain to any part of the Derivative Works, in at least one
+ of the following places: within a NOTICE text file distributed
+ as part of the Derivative Works; within the Source form or
+ documentation, if provided along with the Derivative Works; or,
+ within a display generated by the Derivative Works, if and
+ wherever such third-party notices normally appear. The contents
+ of the NOTICE file are for informational purposes only and
+ do not modify the License. You may add Your own attribution
+ notices within Derivative Works that You distribute, alongside
+ or as an addendum to the NOTICE text from the Work, provided
+ that such additional attribution notices cannot be construed
+ as modifying the License.
+
+ You may add Your own copyright statement to Your modifications and
+ may provide additional or different license terms and conditions
+ for use, reproduction, or distribution of Your modifications, or
+ for any such Derivative Works as a whole, provided Your use,
+ reproduction, and distribution of the Work otherwise complies with
+ the conditions stated in this License.
+
+ 5. Submission of Contributions. Unless You explicitly state otherwise,
+ any Contribution intentionally submitted for inclusion in the Work
+ by You to the Licensor shall be under the terms and conditions of
+ this License, without any additional terms or conditions.
+ Notwithstanding the above, nothing herein shall supersede or modify
+ the terms of any separate license agreement you may have executed
+ with Licensor regarding such Contributions.
+
+ 6. Trademarks. This License does not grant permission to use the trade
+ names, trademarks, service marks, or product names of the Licensor,
+ except as required for reasonable and customary use in describing the
+ origin of the Work and reproducing the content of the NOTICE file.
+
+ 7. Disclaimer of Warranty. Unless required by applicable law or
+ agreed to in writing, Licensor provides the Work (and each
+ Contributor provides its Contributions) on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ implied, including, without limitation, any warranties or conditions
+ of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+ PARTICULAR PURPOSE. You are solely responsible for determining the
+ appropriateness of using or redistributing the Work and assume any
+ risks associated with Your exercise of permissions under this License.
+
+ 8. Limitation of Liability. In no event and under no legal theory,
+ whether in tort (including negligence), contract, or otherwise,
+ unless required by applicable law (such as deliberate and grossly
+ negligent acts) or agreed to in writing, shall any Contributor be
+ liable to You for damages, including any direct, indirect, special,
+ incidental, or consequential damages of any character arising as a
+ result of this License or out of the use or inability to use the
+ Work (including but not limited to damages for loss of goodwill,
+ work stoppage, computer failure or malfunction, or any and all
+ other commercial damages or losses), even if such Contributor
+ has been advised of the possibility of such damages.
+
+ 9. Accepting Warranty or Additional Liability. While redistributing
+ the Work or Derivative Works thereof, You may choose to offer,
+ and charge a fee for, acceptance of support, warranty, indemnity,
+ or other liability obligations and/or rights consistent with this
+ License. However, in accepting such obligations, You may act only
+ on Your own behalf and on Your sole responsibility, not on behalf
+ of any other Contributor, and only if You agree to indemnify,
+ defend, and hold each Contributor harmless for any liability
+ incurred by, or claims asserted against, such Contributor by reason
+ of your accepting any such warranty or additional liability.
+
+ END OF TERMS AND CONDITIONS
+
+ APPENDIX: How to apply the Apache License to your work.
+
+ To apply the Apache License to your work, attach the following
+ boilerplate notice, with the fields enclosed by brackets "[]"
+ replaced with your own identifying information. (Don't include
+ the brackets!) The text should be enclosed in the appropriate
+ comment syntax for the file format. We also recommend that a
+ file or class name and description of purpose be included on the
+ same "printed page" as the copyright notice for easier
+ identification within third-party archives.
+
+ Copyright [yyyy] [name of copyright owner]
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/licenses/LICENSE b/licenses/LICENSE
new file mode 100644
index 0000000000..e04b3d02e3
--- /dev/null
+++ b/licenses/LICENSE
@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2016 Tom Johnson
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/licenses/LICENSE-BSD-NAVGOCO.txt b/licenses/LICENSE-BSD-NAVGOCO.txt
new file mode 100644
index 0000000000..7fdefc3903
--- /dev/null
+++ b/licenses/LICENSE-BSD-NAVGOCO.txt
@@ -0,0 +1,27 @@
+/* This license pertains to the Navgoco jQuery component used for the sidebar. */
+
+Copyright (c) 2013, Christodoulos Tsoulloftas, http://www.komposta.net
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without modification,
+are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+ this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+ this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of the nor the names of its
+ contributors may be used to endorse or promote products derived from this
+ software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
+INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
+OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+OF THE POSSIBILITY OF SUCH DAMAGE.
\ No newline at end of file
diff --git a/news.html b/news.html
new file mode 100644
index 0000000000..cde532d205
--- /dev/null
+++ b/news.html
@@ -0,0 +1,1435 @@
+
+
+
+
+
+
+
+
+News | PMD Source Code Analyzer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Operation metric. Can be calculated on any non-abstract operation.
+
+
Description
+
+
Number of independent paths through a block of code [Lanza05].
+Formally, given that the control flow graph of the block has n vertices, e
+edges and p connected components, the cyclomatic complexity of the block is
+given by CYCLO = e - n + 2p [McCabe76]. In practice it can be
+calculated by counting control flow statements following the standard rules given
+below.
+
+
The standard version of the metric complies with McCabe’s original definition:
+
+
+
Methods have a base complexity of 1.
+
+1 for every control flow statement (if, catch, throw, do,
+while, for, break, continue) and conditional expression (?:).
+
else, finally and default don’t count;
+
+1 for every boolean operator (&&, ||) in the guard condition of a control
+flow statement.
Note: While Java 11 is required for building, running PMD only requires Java 7 (or Java 8 for Apex and the Designer).
+
+
You’ll need to either check out the source code or download the latest source release. Assuming you’ve got the latest source release, unzip it to a directory:
+
+
[tom@hal building]$ ls -l
+total 5716
+-rw-rw-r-- 1 tom tom 5837216 Jul 17 13:09 pmd-src-6.30.0-SNAPSHOT.zip
+[tom@hal building]$ unzip -q pmd-src-6.30.0-SNAPSHOT.zip
+[tom@hal building]$
+
+
+
Now cd down into the pmd directory:
+
+
[tom@hal building]$ cd pmd-src-6.30.0-SNAPSHOT
+[tom@hal pmd-src-6.30.0-SNAPSHOT]$ ls -l | grep pom.xml
+-rw-rw-r-- 1 tom tom 36482 14\. Nov 17:36 pom.xml
+[tom@hal pmd-src-6.30.0-SNAPSHOT]$
+
+
+
That’s the project configuration for maven… let’s compile!
Now the source and binary distribution zip files can be found in the folder pmd-dist/target.
+
+
Notes:
+
+
+
The rules that have already been written are specified in the src/main/resources/rulesets/ directories of
+the specific languages, e.g. pmd-java/src/main/resources/rulesets.
+They’re also in the jar file that’s included with both the source and binary distributions.
+
+
+
A paucity of detail, I’m sure you’d agree. If you think this document can be improved,
+please post here and let me know how. Thanks!
$ run.sh ast-dump --help
+Usage: ast-dump [options]
+ Options:
+ --encoding, -e
+ Encoding of the source file.
+ Default: UTF-8
+ --file
+ The file to dump
+ --format, -f
+ The output format.
+ Default: xml
+ --help, -h
+ Display usage.
+ --language, -l
+ Specify the language to use.
+ Default: java
+ --read-stdin, -i
+ Read source from standard input
+ Default: false
+ -P
+ Properties for the renderer.
+ Syntax: -Pkey=value
+ Default: {}
+
+Available languages: apex ecmascript java jsp modelica plsql pom scala text vf vm wsdl xml xsl
+Available formats: xml XML format with the same structure as the one used in XPath
++ Properties
+ + singleQuoteAttributes Use single quotes to delimit attribute values (default true)
+ + lineSeparator Line separator to use. The default is platform-specific. (default \n)
+ + renderProlog True to output a prolog (default true)
+ + renderCommonAttributes True to render attributes like BeginLine, EndLine, etc. (default false)
+
For JavaCC grammars you should subclass JavaCCTokenizer wich has many examples you could follow, you should also take the Python implementation as reference
Write the fully-qualified name of your Language class to the file src/main/resources/META-INF/services/net.sourceforge.pmd.cpd.Language
+
+
+
Update the test that asserts the list of supported languages by updating the SUPPORTED_LANGUAGES constant in BinaryDistributionIT
+
+
+
+
+
Please don’t forget to add some test, you can again.. look at Go implementation ;)
+
+
If you read this far, I’m keen to think you would also love to support some extra CPD configuration (ignore imports or crazy things like that)
+ If that’s your case , you came to the right place!
+
+
+
You can add your custom properties using a Token filter
+
+
+
+
For Antlr grammars all you need to do is implement your own AntlrTokenFilter
Add a Maven dependency on pmd-lang-test (scope test) in your pom.xml.
+This contains utilities to test your Tokenizer.
+
+
For simple tests, create a test class extending from CpdTextComparisonTest.
+That class is written in Kotlin, but you can extend it in Java as well.
+
+
To add tests, you need to write regular JUnit @Test-annotated methods, and
+call the method doTest with the name of the test file.
+
+
For example, for the Dart language:
+
+
+publicclassDartTokenizerTestextendsCpdTextComparisonTest{
+
+ /**********************************
+ Implementation of the superclass
+ ***********************************/
+
+
+ publicDartTokenizerTest(){
+ super(".dart");// the file extension for the dart language
+ }
+
+ @Override
+ protectedStringgetResourcePrefix(){
+ // If your class is in src/test/java /some/package
+ // you need to place the test files in src/test/resources/some/package/cpdData
+ return"cpdData";
+ }
+
+ @Override
+ publicTokenizernewTokenizer(){
+ // Override this abstract method to return the correct tokenizer
+ returnnewDartTokenizer();
+ }
+
+ /**************
+ Test methods
+ ***************/
+
+
+ @Test// don't forget the JUnit annotation
+ publicvoidtestLiterals(){
+ // This will look for a file named literals.dart
+ // in the directory identified by getResourcePrefix,
+ // tokenize it, then compare the result against a baseline
+ // literals.txt file in the same directory
+
+ // If the baseline file does not exist, it is created automatically
+ doTest("literals");
+ }
+
+}
+
Ideally an AST parser should be implemented as a JJT file (see VmParser.jjt or Java.jjt for example)
+
There is nothing preventing any other parser implementation, as long as you have some way to convert an input stream into an AST tree. Doing it as a JJT simplifies maintenance down the road.
For each AST node that your parser can generate, there should be a class
+
The name of the AST class should be “AST” + “whatever is the name of the node in JJT file”.
+
+
For example, if JJT contains a node called “IfStatement”, there should be a class called “ASTIfStatement”
+
+
+
Each AST class should have two constructors: one that takes an int id; and one that takes an instance of the parser, and an int id
+
It’s a good idea to create a parent AST class for all AST classes of the language. This simplifies rule creation later. (see SimpleNode for Velocity and AbstractJavaNode for Java for example)
+
Note: These AST node classes are generated usually once by javacc/jjtree and can then be modified as needed.
+
+
+
4. Compile your parser (if using JJT)
+
+
An ant script is being used to compile jjt files into classes. This is in pmd-<lang>/src/main/ant/alljavacc.xml file.
+
Create alljavacc.xml file for your language, you can use one from pmd-java as an example.
+
You would probably want to adjust contents of the <delete> tag: start with an empty <fileset> and add there <include>s for those AST nodes you had to manually rewrite (moving those node classes from autogenerated directory to the regular source tree).
+
+
+
5. Create a TokenManager
+
+
Create a new class that implements the TokenManager interface (see VmTokenManager or JavaTokenManager for example)
+
+
+
6. Create a PMD parser “adapter”
+
+
Create a new class that extends AbstractParser
+
There are two important methods to implement
+
+
createTokenManager method should return a new instance of a token manager for your language (see step #5)
+
parse method should return the root node of the AST tree obtained by parsing the Reader source
+
See VmParser class as an example
+
+
+
+
+
7. Create a rule violation factory
+
+
Extend AbstractRuleViolationFactory(see VmRuleViolationFactory for example)
+
The purpose of this class is to create a rule violation instance specific to your language
+
+
+
8. Create a version handler
+
+
Extend AbstractLanguageVersionHandler(see VmHandler for example)
+
This class is sort of a gateway between PMD and all parsing logic specific to your language. It has 3 purposes:
+
+
getRuleViolationFactory method returns an instance of your rule violation factory (see step #7)
+
getParser returns an instance of your parser adapter (see step #6)
+
getDumpFacade returns a VisitorStarter that allows to dump a text representation of the AST into a writer (likely for debugging purposes)
+
+
+
+
+
9. Create a parser visitor adapter
+
+
If you use JJT to generate your parser, it should also generate an interface for a parser visitor (see VmParserVisitor for example)
+
Create a class that implements this auto-generated interface (see VmParserVisitorAdapter for example)
+
The purpose of this class is to serve as a pass-through visitor implementation, which, for all AST types in your language, just executes visit on the base AST type
+
+
+
10. Create a rule chain visitor
+
+
Extend AbstractRuleChainVisitor(see VmRuleChainVisitor for example)
+
This class should implement two important methods:
+
+
indexNodes generates a map of “node type” to “list of nodes of that type”. This is used to visit all applicable nodes when a rule is applied.
+
visit method should evaluate what kind of rule is being applied, and execute appropriate logic. Usually it will just check if the rule is a “parser visitor” kind of rule specific to your language, then execute the visitor. If it’s an XPath rule, then we just need to execute evaluate on that.
+
+
+
+
+
11. Make PMD recognize your language
+
+
Create your own subclass of net.sourceforge.pmd.lang.BaseLanguageModule. (see VmLanguageModule or JavaLanguageModule as an example)
+
You’ll need to refer the rule chain visitor created in step #10.
+
Add for each version of your language a call to addVersion in your language module’s constructor.
+
Create the service registration via the text file src/main/resources/META-INF/services/net.sourceforge.pmd.lang.Language. Add your fully qualified class name as a single line into it.
+
+
+
12. Add AST regression tests
+
+
For languages, that use an external library for parsing, the AST can easily change when upgrading the library.
+Also for languages, where we have the grammar under our control, it useful to have such tests.
+
+
The tests parse one or more source files and generate a textual representation of the AST. This text is compared
+against a previously recorded version. If there are differences, the test fails.
+
+
This helps to detect anything in the AST structure, that changed, maybe unexpectedly.
+
+
+
Create a test class in the package net.sourceforge.pmd.lang.$lang.ast with the name $langTreeDumpTest.
+
This test class must extend net.sourceforge.pmd.lang.ast.test.BaseTreeDumpTest. Note: This class
+is written in kotlin and is available in the module “lang-test”.
+
+
Add a default constructor, that calls the super constructor like so:
Implement the method getParser(). It must return a
+subclass of net.sourceforge.pmd.lang.ast.test.BaseParsingHelper. See
+net.sourceforge.pmd.lang.ecmascript.ast.JsParsingHelper for a example.
+With this parser helper you can also specify, where the test files are searched, by using
+the method withResourceContext(Class<?>, String).
+
+
Add one or more test methods. Each test method parses one file and compares the result. The base
+class has a helper method doTest(String) that does all the work. This method just needs to be called:
On the first test run the test fails. A text file (with the extension .txt) is created, that records the
+current AST. On the next run, the text file is used as comparison and the test should pass. Don’t forget
+to commit the generated text file.
+
+
+
A complete example can be seen in the JavaScript module: net.sourceforge.pmd.lang.ecmascript.ast.JsTreeDumpTest.
+The test resources are in the subpackage “testdata”: pmd-javascript/src/test/resources/net/sourceforge/pmd/lang/ecmascript/ast/testdata/.
+
+
The Scala module also has a test, written in Kotlin instead of Java:
+net.sourceforge.pmd.lang.scala.ast.ScalaParserTests.
+
+
13. Create an abstract rule class for the language
+
+
Extend AbstractRule and implement the parser visitor interface for your language (see AbstractVmRule for example)
+
All other rules for your language should extend this class. The purpose of this class is to implement visit methods for all AST types to simply delegate to default behavior. This is useful because most rules care only about specific AST nodes, but PMD needs to know what to do with each node - so this just lets you use default behavior for nodes you don’t care about.
+
+
+
14. Create rules
+
+
Rules are created by extending the abstract rule class created in step 13 (see EmptyForeachStmtRule for example)
+
Creating rules is already pretty well documented in PMD - and it’s no different for a new language, except you may have different AST nodes.
+
+
+
15. Test the rules
+
+
See BasicRulesTest for example
+
You have to create a rule set for your language (see vm/basic.xml for example)
+
For each rule in this set you want to test, call addRule method in setUp of the unit test
+
+
This triggers the unit test to read the corresponding XML file with rule test data (see EmptyForeachStmtRule.xml for example)
+
This test XML file contains sample pieces of code which should trigger a specified number of violations of this rule. The unit test will execute the rule on this piece of code, and verify that the number of violations matches
+
+
+
+
To verify the validity of the created ruleset, create a subclass of AbstractRuleSetFactoryTest (see RuleSetFactoryTest in pmd-vm for example).
+This will load all rulesets and verify, that all required attributes are provided.
+
+
Note: You’ll need to add your ruleset to rulesets.properties, so that it can be found.
+
+
+
+
Debugging with Rule Designer
+
+
When implementing your grammar it may be very useful to see how PMD parses your example files.
+This can be achieved with Rule Designer:
+
+
Override the getXPathNodeName in your AST nodes for Designer to show node names.
+
Make sure to override both jjtOpen and jjtClose in your AST node base class so that they set both start and end line and column for proper node bound highlighting.
+
Not strictly required but trivial and useful: implement syntax highlighting for Rule Designer:
+
Add a syntax highlighter implementation to net.sourceforge.pmd.util.fxdesigner.util.codearea.syntaxhighlighting (you could use Java as an example).
+
Register it in the AvailableSyntaxHighlighters enumeration.
+
Now build your implementation and place the target/pmd-ui-<version>-SNAPSHOT.jar to the lib directory inside your pmd-bin-... distribution (you have to delete old pmd-ui-*.jar from there).
PMD's Java module has an extensive framework for the calculation of metrics, which allows rule developers to implement and use new code metrics very simply. Most of the functionality of this framework is abstracted in such a way that any PMD supported language can implement such a framework without too much trouble. Here's how.
The framework is pretty simple. On a high level, a Metric<N> describes some numeric computation on a node of type N.
+You should wrap it into a MetricKey<N>, so that it can be cached on nodes (implemented by MetricsUtil).
+
+
At the very least, a metrics framework has those two components and is just a convenient way to compute and memoize
+metrics on a single file. The expressive power of metrics can be improved by implementing signature matching capabilities,
+which allows a metric to count signatures matching a specific pattern (a mask) over a whole class. This was originally
+designed to work across files, given a working usage resolution. However, making that work with incremental analysis is
+harder than it looks, and has been rescheduled to another project.
+
+
Implementation of a new framework
+
+
+
Implement metrics (typically in an internal package)
+
Create some public enums/ utility classes to expose metric keys
You can match the signature of anything: method, field, class, package… It depends on what’s useful for you.
+Suppose you want to be able to match signatures for nodes of type N. What you have to do then is the following:
+
+
+
Create a class implementing the interface Signature<N>. Signatures describe basic information about the node,
+which typically includes most of the modifiers they declare (eg visibility, abstract or virtual, etc.).
+It’s up to you to define the right level of detail, depending on the accuracy of the pattern matching required.
+
Make type N implement SignedNode<N>. This makes the node capable of giving its signature. Factory methods to
+build a Signature<N> from a N are a good idea.
+
Create signature masks. A mask is an object that matches some signatures based on their features. For example, with
+ the Java framework, you can build a JavaOperationSigMask that matches all method signatures with visibility
+ public. A sigmask implements SigMask<S>, where S is the type of signature your mask handles.
+
Create utility methods in your abstract class metric class to count signatures matching a specific mask.
+Example
Pmdtester is a regression testing tool that ensures no new problems and unexpected behaviors will be introduced to PMD after fixing an issue.
+It can also be used to verify, that new rules work as expected. It has been integrated into travis CI and is actually used automatically for PRs.
+Regression difference reports are commented back to the PR for the reviewer’s information e.g. https://github.com/pmd/pmd/pull/1265#issuecomment-408945709
+
+
Run pmdtester locally
+
Install pmdtester
+
+
gem install pmdtester --pre
+
+
Verifying your local changes and generate a diff-report locally
Want to know what’s coming? Or, better, wanna contribute ? Here is the page listing what are our plans -
+when we have ones, for the future of PMD. It also give you hints at part of the code we would like to clean -
+that you may want to clean to contribute to the project!
+
+
Of course, an easy way to contribute is too check out the bug tracker and see if you can fix some issues -
+some could be quite easy, we simply have not the time to look at them all!
+
+
At last, if you want to contribute, register on the pmd-devel mailing list, and come discuss with us!
+
+
Roadmap
+
+
This roadmap contains all the different ‘workshops’ PMD’s developers are working right now.
+
+
+
Better symbol analysis: See below.
+
Data Flow Analysis: See below.
+
Code Cleanups: See below.
+
+
+
Please note that, of course, there is no warranty about when those ‘features’ will be finished, if they ever are.
+
+
Better symbol analysis
+
+
Currently PMD only looks at one source file at a time. Instead, it should resolve symbols across classes.
+This will eliminate some open bugs and enable a lot more rules to be written. However, it’ll taken some doing,
+because it’ll require parsing of class files. Lots of work here.
+
+
Data flow analysis (DFA)
+
+
Raik Schroeder, a graduate student at Fachhochschule Stralsund has written a DFA layer that should enable
+us to write some more complicated rules - stuff like common subexpression elimination, loop invariant code motion
+(and code hoisting suggestions), shrink wrapping, and partial redundancy elimination. The code is currently in the net.sourceforge.pmd.dfa packages, and we’re going through it now figuring out what rules we can write
+that use it. We should be able to use it to simplify some current rules, as well.
+
+
Other changes we’ll like to see…
+
+
These are things which really should be done, but just haven’t been gotten to yet:
+
+
+
Enhance Rule Designer to allow testing of the violation suppress Regex and XPath.
+
Remove the type resolution specific rules. Merge these back into the
+standard rules. In general, a Rule should use TR when it can, and fall
+back on non-TR approach otherwise. No need for separate Rules for TR/non-TR.
+
Reconcile the util.designer and util.viewer packages. Two versions of the
+same thing. Designer is more up to date, but Viewer has a nice MVC design.
+
Need a JUnit test to check for “dead” Rules, that is those not used by any RuleSet.
+
Rule JUnit tests should verify the Test class follows expected naming
+conventions just like the Rules need to.
+
Do we have a rule to style check for multiple declarations and chained
+assignments? (e.g. int a, b; int a = b = x;)
+
+
+
These are food for thought, perhaps future items. If you think you’d like to
+work on one of these, check with pmd-devel to see what the current thoughts
+on the topic.
+
+
+
+
CPD needs work on use of Language. It currently is hardcoded to only
+handled Java 1.4. Integrate CPD needs into core PMD where appropriate.
+Otherwise, drive CPD behavior based off of core PMD, instead of duplicating
+some logic.
+
+
+
Need a more flexible and powerful scheme for classifying files to various
+Languages. At a minimum, should have the ability to specify which
+file extensions you want to be used for a language (e.g. not everyone uses
+.jsp for JSP extensions, some use .jspx, .xhtml, etc.). Also, consider
+hooks into the LanguageVersionDiscoverer process for classifying a
+File/String to a LanguageVersion of a specific Language, one could imaging
+using a ‘magic’ system like Unix uses to tell different versions of files
+apart based on actual content.
+
+
+
Should we change Node interface to something like ‘Node<T extends Node<T>>’,
+and then declare the language specific node interfaces to be something like
+‘JavaNode extends Node<JavaNode>’? This could allow anything on the Node
+interface to return the language specific node type instead of generic
+node. For example, ASTStatement.jjtGetParent() to return a JavaNode,
+instead of a Node. This is a rather huge change, as the Node interface is
+one of the pervasive things in the PMD code base. Is the extra work of using
+the Node interface with properly with generics, worth the omission of
+occasional some casting?
+
+
+
Should multiple Languages be able to claim a single source file? Imagine
+XML format JSP file, for which you’ve defined a ruleset which uses JSP and
+XML rules. Stating that certain XML rules also can map to the JSP language
+extensions could be useful. This means Source file to LanguageVersion
+mapping is not 1-1, but 1-many, we’d need to deal with this accordingly.
+
+
+
Additional changes to Rule organization within RuleSets as discussed on
+this forum thread.
+
+
+
Figure out a way to allow Rules to deal with parentheses and blocks, which
+introduce certain repetitive (and generally ignorable for most Rules)
+structures into the AST tree. Some rules are making special effort
+(e.g. ConfusingTernaryRule) to detect these AST patterns. Perhaps a
+“normalized” AST structure can be created which will make the AST appear
+consistent regardless of how many parens are presented, or how many blocks
+have been created (e.g. default block inserted, duplicates collapsed).
+This should be configurable on per Rule basis similar to TR and SymbolTable.
+
+
+
+
Code cleanups
+
+
Some of the code is a bit sloppy:
+
+
+
RuleSetFactory is a mess. It needs to be refactored into something that has layers, or decorators, or something.
+
Cleanups would be welcome for ConstructorCallsOverridableMethod and DoubleCheckedLocking
+
The Designer GUI is a bit messed up; the bottom panes look funny.
+
The grammar has some odd bits:
+
+
BlockStatement has an odd hack for class definitions inside methods
+
enumLookahead() seems like a bit of overkill, can it use Modifiers somehow?
+
The whole “discardable node” thing seems wasteful
+
Does ExtendsList need that ‘extendsMoreThanOne’ thing?
+
ClassOrInterfaceBodyDeclaration has a monstrous lookahead to check for enums
+
ClassOrInterfaceType gloms together dotted names… is that the right thing to do?
When improving PMD over time, some rules might become obsolete. This could be because the underlying
+technology a specific rule is checking (such as a specific JVM version) is not relevant anymore or a rule
+has been replaced by a better implementation.
+
+
In order to remove the requirement to maintain such rules forever, these rules can be marked as deprecated.
+This means, that such rules can entirely be removed in the future.
+However, the rules must not be removed immediately, since that would break any (custom) ruleset, that
+references this rule.
+
+
This policy tries to establish some ground rules about how and when rules are deprecated and removed.
+The main goal is, to maintain compatibility of custom rulesets throughout the deprecation process.
+
+
Renaming rules
+
+
If a rule is enhanced, it might make sense to also rename the rule, to reflect that enhancement. However,
+simply renaming the rule would break existing (custom) ruleset. Therefore the following procedure should be used:
+
+
+
Rename the rule to the new name (and also the rule tests and resources)
+
+
Add a deprecated rule reference with the old name, that points to the new rule name:
Note: When referencing the complete rulesets or categories,
+these deprecated rule references are ignored, so that the rule is not used twice.
+
+
Moving rules between categories
+
+
Every rule is in one category. It might happen, that the focus of the rule shifts and it makes more
+sense, if it would be in a different, better fitting category.
+
+
+
Move the rule to the new category (and also the rule tests and resources)
+
+
Add a deprecated rule reference in the old category, that points to the rule in the new category:
Note: When referencing the complete rulesets or categories,
+these deprecated rule references are ignored, so that the rule is not used twice, if both categories
+are used.
+
+
Deprecating rules
+
+
Before a rule can be removed, it must have been marked as deprecated:
This has the effect, that it is automatically disabled if the complete ruleset or category
+is referenced. The rule can still be used, if it is referenced directly.
+
+
The reasons for the deprecation should be explained in the rule description. If there is a replacement rule
+available, then this rule should be mentioned in the description as well.
+
+
Removing rules
+
+
Removing rules completely can only be done
+
+
+
if the rules have been deprecated before
+
for a new major release.
+
+
+
Removing a rule from a ruleset or category will break any custom ruleset, that references
+this rule directly. Therefore rules can only be removed with the next major release of PMD.
+
+
Rule property compatibility
+
+
Renaming or removing rule properties is not backwards compatible and can only be done
+with a major release of PMD.
+
+
In order to prepare for the change, properties can be deprecated as well: If the property description
+starts with the magic string deprecated!, then this property is rendered in the rule documentation
+as deprecated. However, there is no automatic check done if such a property is used and no
+deprecation warning is issued with the log.
+
+
Therefore, the process for renaming a property looks like this:
+
+
+
Create a new property with the same type and new name
+
Prefix the description of the old property with deprecated! and also add a explanation
+either in the property description or in the rule description, which property should be used
+instead of the deprecated property.
+
Adjust the rule implementation to first check the old property. If it has a value other than the
+default value, then the old (deprecated) property has been used and a deprecation warning should
+be logged. If the new property is used (it has a value other than the default), then it takes
+preference, but the deprecation warning for the old property should still be issued.
+
The deprecated property can be removed with the next major release of PMD.
+
+
+
Changing the default value of a property might have some results, that make the rule
+behavioral incompatible: E.g. it could find many more violations with a different default
+configuration and therefore lead to a sudden increase of violations after a PMD upgrade.
+It should be judged per case, whether the new default can be considered compatible or not.
+If it is not compatible, then the new default value should be configured only with the next
+major release of PMD.
The documentation sources can be found in two places based on how they are generated:
+
+
the ones that are manually written (like the one you are reading);
+
and the ones that are generated automatically from the category files. All the rule documentation
+pages are generated that way.
+
+
+
Handwritten documentation
+
+
All handwritten documentation is stored in the subfolders under docs/pages. The folder structure resembles the sidebar structure.
+Since all pages use a simple permalink, in the rendered html pages, all pages are flattened in one directory.
+This makes it easy to view the documentation also offline.
+
+
Rule documentation
+
+
The categories for a language %lang% are located in
+pmd-%lang%/src/main/resources/category/%lang% . So for Java the categories
+can be found under pmd-java/src/main/resources/category/java.
+The XML category files in this directory are transformed during build into markdown pages
+describing the rules they contain. These pages are placed under docs/ like the handwritten
+documentation, and are then rendered with Jekyll like the rest of them. The rule documentation
+generator is the separate submodule pmd-doc.
+
+
Modifying the documentation of a rule should thus not be done on the markdown page,
+but directly on the XML rule tag corresponding to the rule, in the relevant
+category file.
+
+
The XML documentation of rules can contain GitHub flavoured markdown.
+Just wrap the markdown inside CDATA section in the xml. CDATA sections preserve
+all formatting inside the delimiters, and allow to write code samples without
+ escaping special xml characters. For example:
+
<rule ...>
+ <description>
+ <![CDATA[
+ Full description, can contain markup
+
+ And paragraphs
+ ]]>
+ </description>
+ ...
+</rule>
+
+
+
Custom Liquid Tags
+
+
We have some additional custom liquid tags that help in writing the documentation.
For the javadoc tags, the standard PMD maven modules are already defined as namespaces, e.g. core, java, apex, ….
+
+
For the implementation of these tags, see the _plugins folder.
+
+
Building
+
+
There are two ways, to execute jekyll:
+
+
+
+
Using bundler. This will install all the needed ruby packages locally and execute jekyll:
+
+
# this is required only once, to download and install the dependencies
+bundle install
+# this builds the documentation under _site
+bundle exec jekyll build
+# this runs a local webserver as http://localhost:4005
+bundle exec jekyll serve
+
+
+
+
Using docker. This will create a local docker image, into which all needed ruby
+packages and jekyll is installed.
+
+
# this is required only once to create a local docker image named "pmd-doc"
+docker build --no-cache -t pmd-doc .
+# this builds the documentation under _site
+docker run --rm=true -v "$PWD:/src" pmd-doc build -H 0.0.0.0
+# this runs a local webserver as http://localhost:4005
+docker run --rm=true -v "$PWD:/src" -p 4005:4005 pmd-doc serve -H 0.0.0.0
+
+
+
+
+
The built site is stored locally in the (git ignored) directory _site. You can
+point your browser to _site/index.html to see the pmd documentation.
+
+
Alternatively, you can start the local webserver, that will serve the documentation.
+Just go to http://localhost:4005.
+If a page is modified, the documentation will automatically be rendered again and
+all you need to do, is refreshing the page in your browser.
+
+
See also the script pmd-jekyll.sh.
+It starts the jekyll server in the background and doesn’t block the current shell.
+
+
The sidebar
+
+
The sidebar is stored as a YAML document under _data/sidebars/pmd_sidebar.yml.
+
+
Make sure to add an entry there, whenever you create a new page.
+
+
The frontmatter
+
+
Each page in jekyll begins with a YAML section at the beginning. This section
+is separated by 3 dashes (---). Example:
+
+
---
+title: Writing Documentation
+last_update: August 2017
+permalink: pmd_devdocs_writing_documentation.html
+---
+
+Some Text
+
+# Some header
+
+
+
There are a couple of possible fields. Most important and always
+required are title and permalink.
+
+
By default, a page toc (table of contents) is automatically generated.
+You can prevent this with “toc: false”.
+
+
You can add keywords, that will be used for the on-site search: “keywords: documentation, jekyll, markdown”
+
+
It’s useful to maintain a last_update field. This will be added at the bottom of the
+page.
+
+
A summary can also be provided. It will be added in a box before the content.
{% include note.html content="This is a note." %}
+
+
+
It renders as:
+
+
Note: This is a note.
+
+
Other available types are:
+
+
+
note.html
+
tip.html
+
warning.html
+
important.html
+
+
+
A callout is created like this:
+
+
{% include callout.html content="This is a callout of type default.<br/><br/>There are the following types available: danger, default, primary, success, info, and warning." type="default" %}
+
+
+
It renders as:
+
+
This is a callout of type default.
There are the following types available: danger, default, primary, success, info, and warning.
+
+
Code samples with syntax highlighting
+
+
This is as easy as:
+
+
``` java
+public class Foo {
+ public void bar() { System.out.println("x"); }
+}
+```
+
mvn verify -pl pmd-doc. This only checks links within the site. HTTP links can be checked
+by specifying -Dpmd.doc.checkExternalLinks=true on the command line.
Operation metric, class metric. Can be computed on classes, enums and
+concrete operations.
+
+
Description
+
+
Number of usages of foreign attributes, both directly and through accessors.
+High values of ATFD (> 3 for an operation) may suggest that the class or operation
+breaks encapsulation by relying on the internal representation of the classes
+it uses instead of the services they provide.
+
+
ATFD can be used to detect God Classes and Feature Envy. [Lanza05]
+
+
Class Fan Out Complexity (CLASS_FAN_OUT)
+
+
Operation metric, class metric. Can be computed on classes, enums and
+concrete operations.
+
+
Description
+
This counts the number of other classes a given class or operation relies on.
+Classes from the package java.lang are ignored by default (can be changed via options).
+Also primitives are not included into the count.
+
+
Code example
+
+
importjava.util.*;
+importjava.io.IOException;
+
+publicclassFoo{// total 8
+ publicSetset=newHashSet();// +2
+ publicMapmap=newHashMap();// +2
+ publicStringstring="";// from java.lang -> does not count by default
+ publicDoublenumber=0.0;// from java.lang -> does not count by default
+ publicint[]intArray=newint[3];// primitive -> does not count
+
+ @Deprecated// from java.lang -> does not count by default
+ @Override// from java.lang -> does not count by default
+ publicvoidfoo(Listlist)throwsException{// +1 (Exception is from java.lang)
+ thrownewIOException();// +1
+ }
+
+ publicintgetMapSize(){
+ returnmap.size();// +1 because it uses the Class from the 'map' field
+ }
+}
+
+
+
Options
+
+
+
Option includeJavaLang: Also include classes from the package java.lang
+
+
+
Cyclomatic Complexity (CYCLO)
+
+
Operation metric. Can be calculated on any non-abstract operation.
+
+
Description
+
+
Number of independent paths through a block of code [Lanza05].
+Formally, given that the control flow graph of the block has n vertices, e
+edges and p connected components, the cyclomatic complexity of the block is
+given by CYCLO = e - n + 2p [McCabe76]. In practice it can be
+calculated by counting control flow statements following the standard rules given
+below.
+
+
The standard version of the metric complies with McCabe’s original definition:
+
+
+
Methods have a base complexity of 1.
+
+1 for every control flow statement (if, case, catch, throw, do,
+while, for, break, continue) and conditional expression (?:)
+[Sonarqube]. Notice switch cases count as one, but not the
+switch itself: the point is that a switch should have the same complexity
+value as the equivalent series of if statements.
+
else, finally and default don’t count;
+
+1 for every boolean operator (&&, ||) in the guard condition of a control
+flow statement. That’s because Java has short-circuit evaluation semantics for
+boolean operators, which makes every boolean operator kind of a control flow
+statement in itself.
Option CycloVersion#IGNORE_BOOLEAN_PATHS: Boolean operators are not counted,
+nor are empty fall-through cases in switch statements. You can use this
+option to get results similar to those of the old StdCyclomaticComplexityRule,
+which is to be replaced.
+
Option CycloVersion#CONSIDER_ASSERTS: Assert statements are counted as if
+they were if (..) throw new AssertionError(..). Compatible with
+IGNORE_BOOLEAN_PATHS.
+
+
+
Lines of Code (LoC)
+
+
Operation metric, class metric. Can be calculated on any of those nodes.
+
+
Description
+
+
Simply counts the number of lines of code the operation or class takes up in
+the source. This metric doesn’t discount comments or blank lines. See also
+NCSS.
+
+
Non-commenting source statements (NCSS)
+
+
Operation metric, class metric. Can be calculated on any of those nodes.
+
+
Description
+
+
Number of statements in a class or operation. That’s roughly equivalent to
+counting the number of semicolons and opening braces in the program. Comments
+and blank lines are ignored, and statements spread on multiple lines count as
+only one (e.g. int\n a; counts a single statement).
+
+
The standard version of the metric is based off JavaNCSS’s version
+[JavaNcss]:
+
+
+
+1 for any of the following statements: if, else, while, do, for,
+switch, break, continue, return, throw, synchronized, catch,
+finally.
+
+1 for each assignment, variable declaration (except for loop initializers)
+or statement expression. We count variables declared on the same line (e.g.
+int a, b, c;) as a single statement.
+
Contrary to Sonarqube, but as JavaNCSS, we count type declarations (class,
+interface, enum, annotation), and method and field declarations
+[Sonarqube].
+
Contrary to JavaNCSS, but as Sonarqube, we do not count package declaration
+and import declarations as statements. This makes it easier to compare nested
+classes to outer classes. Besides, it makes for class metric results that
+actually represent the size of the class and not of the file. If you don’t
+like that behaviour, use the COUNT_IMPORTS option.
Option NcssVersion#COUNT_IMPORTS: Import and package statements are counted
+as well. This version fully complies with JavaNCSS.
+
+
+
NPath complexity (NPath)
+
+
Operation metric. Can be computed on any non-abstract operation.
+
+
Description
+
+
Number of acyclic execution paths through a piece of code. This is related to
+cyclomatic complexity, but the two metrics don’t count the same thing: NPath
+counts the number of distinct full paths from the beginning to the end of the
+method, while Cyclo only counts the number of decision points. NPath is not
+computed as simply as Cyclo. With NPath, two decision points appearing sequentially
+have their complexity multiplied.
+
+
The fact that NPath multiplies the complexity of statements makes it grow
+exponentially: 10 if - else statements in a row would give an NPath of 1024,
+while Cyclo would evaluate to 20. Methods with an NPath complexity over 200 are
+generally considered too complex.
+
+
We compute NPath recursively, with the following set of rules:
+
+
An empty block has a complexity of 1.
+
The complexity of a block is the product of the NPath complexity of its
+statements, calculated as follows:
+
+
The complexity of for, do and while statements is 1, plus the
+complexity of the block, plus the complexity of the guard condition.
+
The complexity of a cascading if statement (if .. else if ..) is the
+number of if statements in the chain, plus the complexity of their guard
+condition, plus the complexity of the unguarded else block (or 1 if there
+is none).
+
The complexity of a switch statement is the number of cases, plus the
+complexity of each case block. It’s equivalent to the complexity of the
+equivalent cascade of if statements.
+
The complexity of a ternary expression (?:) is the complexity of the guard
+condition, plus the complexity of both expressions. It’s equivalent to the
+complexity of the equivalent if .. else construct.
+
The complexity of a try .. catch statement is the complexity of the try
+block, plus the complexity of each catch block.
+
The complexity of a return statement is the complexity of the expression
+(or 1 if there is none).
+
All other statements have a complexity of 1 and are discarded from the product.
After block 0, the control flow can either execute block 1 or 2 before jumping
+to block 3. From block three, the control flow will again have the choice
+between blocks 4 and 5 before jumping to block 6. The first if offers 2
+choices, the second offers 3, so the cyclomatic complexity of this method is
+2 + 3 = 5. NPath, however, sees 2 * 3 = 6 full paths from the beginning to the end.
+
+
Number Of Public Attributes (NOPA)
+
Class metric. Can be computed on classes.
+
+
Number Of Accessor Methods (NOAM)
+
Class metric. Can be computed on classes.
+
+
Tight Class Cohesion (TCC)
+
+
Class metric. Can be computed on classes and enums.
+
+
Description
+
+
The relative number of method pairs of a class that access in common at
+least one attribute of the measured class. TCC only counts
+direct attribute accesses, that is, only those attributes that are accessed in
+the body of the method [BK95].
+
+
TCC is taken to be a reliable cohesion metric for a class. High values (>70%)
+indicate a class with one basic function, which is hard to break into subcomponents.
+On the other hand, low values (<50%) may indicate that the class tries to do too much and
+defines several unrelated services, which is undesirable.
+
+
TCC can be used to detect God Classes and Brain Classes [Lanza05].
+
+
Weighted Method Count (WMC)
+
+
Class metric. Can be computed on classes and enums.
+
+
Description
+
+
Sum of the statistical complexity of the operations in the class. We use
+CYCLO to quantify the complexity of an operation
+[Lanza05].
+
+
Options
+
+
WMC uses the same options as CYCLO, which are provided to CYCLO when
+computing it.
+
+
Weight Of Class (WOC)
+
+
Class metric. Can be computed on classes.
+
+
Description
+
+
Number of “functional” public methods divided by the total number of
+public methods. Our definition of “functional method” excludes
+constructors, getters, and setters.
+
+
This metric tries to quantify whether the measured class’ interface reveals
+more data than behaviour. Low values (less than 30%) indicate that the class
+reveals much more data than behaviour, which is a sign of poor encapsulation.
+
+
This metric is used to detect Data Classes, in conjunction with WMC,
+NOPA and NOAM.
+
+
References
+
+
BK95: Bieman, Kang; Cohesion and reuse in an object-oriented system.
+In Proceedings ACM Symposium on Software Reusability, 1995.
+
+
Lanza05: Lanza, Marinescu; Object-Oriented Metrics in Practice, 2005.
+
+
McCabe76: McCabe, A Complexity Measure, in Proceedings of the 2nd ICSE (1976).
In short, JSP files that are XHTML-compliant, are supported.
+Except for files that contain inline DTDs; only references to external
+DTD files are supported (having inline DTD will result in a parsing
+error).
+
+
The XHTML support means that:
+
+
+
+
opening tags must be accompanied by corresponding closing tags
+(or they must be empty tags). This means that currently a “<HR>”
+tag without corresponding closing tag will result in a parsing error.
+
+
+
attribute values must be surrounded by single or double quotes. This means that the following syntax
+will result in a parsing error:
+
+
<MyTag myAttr1=true myAttr2=1024/>
+
+
+
< and > characters must be escaped, or put inside a CDATA section.
+
+
PMD creates a “Abstract Syntax Tree” representation of source code; the rules use such a tree as input.
+For JSP files, the following constructs are parsed into nodes of the tree:
JSP-directives, JSP-declarations, JSP-comments, JSP-scriptlets, JSP-expressions,
+Expression Language expressions, JSF value bindings
+
everything else is seen as flat text nodes.
+
+
+
+
Java code (e.g. in JSP-scriptlets) and EL expressions are not parsed or
+further broken down. If you want to create rules that check the code
+inside EL expressions or JSP scriptlets (a.o.), you currently would
+have to do “manual” string manipulation (e.g. using regular expressions).
+
+
+
+
How to use it
+
+
Using the command-line interface, two new options can be used in the arguments string:
+
+
+
“-jsp” : this triggers checking JSP files (they are not checked by default)
+
“-nojava” : this tells PMD not to check java source files (they are checked by default)
+
+
+
Using the Ant task, you decide if PMD must check JSP files by choosing
+what files are given to the PMD task. If you use a fileset that
+contains only “.java” files, JSP files obviously will not be checked.
+
+
If you want to call the PMD API for checking JSP files, you should investigate the javadoc of PMD.
The API of PMD has been growing over the years and needs to be cleaned up. The goal is, to
+have a clear separation between a well-defined API and the implementation, which is internal.
+This should help us in future development. This however entails some incompatibilities and
+deprecations, see also the sections New API support guidelines and
+[Planned API removals](#planned-api-removals] below.
+
+
Full Antlr Support
+
+
PMD 6 only supports JavaCC based grammars, but with Antlr parsers
+can be generated as well. PMD 7 adds full support for grammars written in Antlr, which allows
+to leverage existing grammars.
We have quite some ideas how we want to improve the documentation. The goal is, that the documentation is
+up to date and nearly complete. One big task is, how the built-in rules are presented, so that users
+can easier see, what exactly is available and decide, which rules are useful for the project at hand.
PMD 6 supports XPath 1.0 via the Jaxen library. This library is old and unmaintained creating some problems
+(one of which is duplicated classes in the package org.w3c.dom which is a Java API actually).
+Therefore XPath 1.0 support will be dropped and we upgrade our XPath 2.0 implementation with Saxon moving
+on to Saxon HE. This will eventually add support in PMD for XPath 3.1.
Like the main PMD API, the Java AST has been growing over time and the grammar doesn’t support
+all edge cases (e.g. annotation are not supported everywhere). The goal is to simplify the AST by reducing
+unnecessary nodes and abstractions and fix the parsing issues.
+This helps in the end to provide a better type resolution implementation, but changing the AST is a breaking
+API change.
+
+
Some first results of the Java AST changes are for now documented in the Wiki:
+Java clean changes.
+
+
Miscellaneous
+
+
There are also some small improvements, refactoring and internal tasks that are planned for PMD 7.
Until now, all released public members and types were implicitly considered part
+of PMD’s public API, including inheritance-specific members (protected members, abstract methods).
+We have maintained those APIs with the goal to preserve full binary compatibility between minor releases,
+only breaking those APIs infrequently, for major releases.
+
+
In order to allow PMD to move forward at a faster pace, this implicit contract will
+be invalidated with PMD 7.0.0. We now introduce more fine-grained distinctions between
+the type of compatibility support we guarantee for our libraries, and ways to make
+them explicit to clients of PMD.
+
+
.internal packages and @InternalApi annotation
+
+
Internal API is meant for use only by the main PMD codebase. Internal types and methods
+may be modified in any way, or even removed, at any time.
+
+
Any API in a package that contains an .internal segment is considered internal.
+The @InternalApi annotation will be used for APIs that have to live outside of
+these packages, e.g. methods of a public type that shouldn’t be used outside of PMD (again,
+these can be removed anytime).
+
+
@ReservedSubclassing
+
+
Types marked with the @ReservedSubclassing annotation are only meant to be subclassed
+by classes within PMD. As such, we may add new abstract methods, or remove protected methods,
+at any time. All published public members remain supported. The annotation is not inherited, which
+means a reserved interface doesn’t prevent its implementors to be subclassed.
+
+
@Experimental
+
+
APIs marked with the @Experimental annotation at the class or method level are subject to change.
+They can be modified in any way, or even removed, at any time. You should not use or rely
+ on them in any production code. They are purely to allow broad testing and feedback.
+
+
@Deprecated
+
+
APIs marked with the @Deprecated annotation at the class or method level will remain supported
+until the next major release but it is recommended to stop using them.
+
+
The transition
+
+
All currently supported APIs will remain so until 7.0.0. All APIs that are to be moved to
+.internal packages or hidden will be tagged @InternalApi before that major release, and
+the breaking API changes will be performed in 7.0.0.
+
+
Planned API removals
+
+
List of currently deprecated APIs
+
+
Warning: This list is not exhaustive. The ultimate reference is whether
+an API is tagged as @Deprecated or not in the latest minor release. During the development of 7.0.0,
+we may decide to remove some APIs that were not tagged as deprecated, though we’ll try to avoid it.
net.sourceforge.pmd.lang.dart.antlr4.Dart2Lexer will be renamed to DartLexer and moved to package
+net.sourceforge.pmd.lang.dart.ast with PMD 7. All other classes in the old package will be removed.
XML rule definition in rulesets: In PMD 7, the language attribute will be required on all rule
+elements that declare a new rule. Some base rule classes set the language implicitly in their
+constructor, and so this is not required in all cases for the rule to work. But this
+behavior will be discontinued in PMD 7, so missing language attributes are now
+reported as a forward compatibility warning.
The maven module net.sourceforge.pmd:pmd-scala is deprecated. Use net.sourceforge.pmd:pmd-scala_2.13
+or net.sourceforge.pmd:pmd-scala_2.12 instead.
+
+
+
Rule implementation classes are internal API and should not be used by clients directly.
+The rules should only be referenced via their entry in the corresponding category ruleset
+(e.g. <rule ref="category/java/bestpractices.xml/AbstractClassWithoutAbstractMethod" />).
+
+
While we definitely won’t move or rename the rule classes in PMD 6.x, we might consider changes
+in PMD 7.0.0 and onwards.
+
+
+
+
Deprecated APIs
+
+
Internal API
+
+
Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0.
+You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.
Note: Experimental APIs are identified with the annotation Experimental,
+see its javadoc for details
+
+
+
The experimental methods in BaseLanguageModule have been replaced by a
+definitive API.
+
+
+
6.23.0
+
+
Deprecated APIs
+
+
Internal API
+
+
Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0.
+You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.
As part of the changes we’d like to do to AST classes for 7.0.0, we would like to
+hide some methods and constructors that rule writers should not have access to.
+The following usages are now deprecated in the Apex, Javascript, PL/SQL, Scala and Visualforce ASTs:
+
+
+
Manual instantiation of nodes. Constructors of node classes are deprecated and
+marked InternalApi. Nodes should only be obtained from the parser,
+which for rules, means that they never need to instantiate node themselves.
+Those constructors will be made package private with 7.0.0.
+
Subclassing of abstract node classes, or usage of their type. The base classes are internal API
+and will be hidden in version 7.0.0. You should not couple your code to them.
+
+
In the meantime you should use interfaces like VfNode or
+Node, or the other published interfaces in this package,
+to refer to nodes generically.
+
Concrete node classes will be made final with 7.0.0.
+
+
+
Setters found in any node class or interface. Rules should consider the AST immutable.
+We will make those setters package private with 7.0.0.
The implementation classes of TokenManager (eg VfTokenManager) are deprecated and should not be used outside of our implementation.
+This also affects CPD-only modules.
+
+
+
These deprecations are added to the following language modules in this release.
+Please look at the package documentation to find out the full list of deprecations.
Outside of these packages, these changes also concern the following TokenManager
+implementations, and their corresponding Parser if it exists (in the same package):
Multiple fields, constructors and methods in XPathRule. See javadoc for details.
+
+
+
6.22.0
+
+
Deprecated APIs
+
+
Internal API
+
+
Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0.
+You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.
Many APIs of net.sourceforge.pmd.lang.metrics, though most of them were internal and
+probably not used directly outside of PMD. Use MetricsUtil as
+a replacement for the language-specific façades too.
Several methods of ASTTryStatement, replacements with other names
+have been added. This includes the XPath attribute @Finally, replace it with a test for child::FinallyStatement.
+
Several methods named getGuardExpressionNode are replaced with getCondition. This affects the
+following nodes: WhileStatement, DoStatement, ForStatement, IfStatement, AssertStatement, ConditionalExpression.
+
ASTYieldStatement will not implement TypeNode
+anymore come 7.0.0. Test the type of the expression nested within it.
As part of the changes we’d like to do to AST classes for 7.0.0, we would like to
+hide some methods and constructors that rule writers should not have access to.
+The following usages are now deprecated in the JSP AST (with other languages to come):
+
+
+
Manual instantiation of nodes. Constructors of node classes are deprecated and
+marked InternalApi. Nodes should only be obtained from the parser,
+which for rules, means that they never need to instantiate node themselves.
+Those constructors will be made package private with 7.0.0.
+
Subclassing of abstract node classes, or usage of their type. The base classes are internal API
+and will be hidden in version 7.0.0. You should not couple your code to them.
+
+
In the meantime you should use interfaces like JspNode or
+Node, or the other published interfaces in this package,
+to refer to nodes generically.
+
Concrete node classes will be made final with 7.0.0.
+
+
+
Setters found in any node class or interface. Rules should consider the AST immutable.
+We will make those setters package private with 7.0.0.
As part of the changes we’d like to do to AST classes for 7.0.0, we would like to
+hide some methods and constructors that rule writers should not have access to.
+The following usages are now deprecated in the VM AST (with other languages to come):
+
+
+
Manual instantiation of nodes. Constructors of node classes are deprecated and
+marked InternalApi. Nodes should only be obtained from the parser,
+which for rules, means that they never need to instantiate node themselves.
+Those constructors will be made package private with 7.0.0.
+
Subclassing of abstract node classes, or usage of their type. The base classes are internal API
+and will be hidden in version 7.0.0. You should not couple your code to them.
+
+
In the meantime you should use interfaces like VmNode or
+Node, or the other published interfaces in this package,
+to refer to nodes generically.
+
Concrete node classes will be made final with 7.0.0.
+
+
+
Setters found in any node class or interface. Rules should consider the AST immutable.
+We will make those setters package private with 7.0.0.
The production and node ASTCursorBody was unnecessary, not used and has been removed. Cursors have been already
+parsed as ASTCursorSpecification.
+
+
6.21.0
+
+
Deprecated APIs
+
+
Internal API
+
+
Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0.
+You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.
CharStream, JavaCharStream,
+SimpleCharStream: these are APIs used by our JavaCC
+implementations and that will be moved/refactored for PMD 7.0.0. They should not
+be used, extended or implemented directly.
+
All classes generated by JavaCC, eg JJTJavaParserState.
+This includes token classes, which will be replaced with a single implementation, and
+subclasses of ParseException, whose usages will be replaced
+by just that superclass.
+
+
+
For removal
+
+
+
pmd-core
+
+
Many methods on the Node interface
+and AbstractNode base class. See their javadoc for details.
Several methods of ASTTryStatement, replacements with other names
+have been added. This includes the XPath attribute @Finally, replace it with a test for child::FinallyStatement.
+
Several methods named getGuardExpressionNode are replaced with getCondition. This affects the
+following nodes: WhileStatement, DoStatement, ForStatement, IfStatement, AssertStatement, ConditionalExpression.
+
ASTYieldStatement will not implement TypeNode
+anymore come 7.0.0. Test the type of the expression nested within it.
Each renderer has now a new method Renderer#setUseShortNames which
+is used for implementing the “shortnames” CLI option. The method is automatically called by PMD, if this
+CLI option is in use. When rendering filenames to the report, the new helper method
+AbstractRenderer#determineFileName should be used. This will change
+the filename to a short name, if the CLI option “shortnames” is used.
+
+
Not adjusting custom renderers will make them render always the full file names and not honoring the
+CLI option “shortnames”.
The method AbstractPMDProcessor#filenameFrom has been
+deprecated. It was used to determine a “short name” of the file being analyzed, so that the report
+can use short names. However, this logic has been moved to the renderers.
+
The method Report#metrics and Report have
+been deprecated. They were leftovers from a previous deprecation round targeting
+StatisticalRule.
+
+
+
Internal APIs
+
+
Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.
Reminder: Please don’t use members marked with the annotation InternalApi, as they will likely be removed, hidden, or otherwise intentionally broken with 7.0.0.
+
+
+
In ASTs
+
+
As part of the changes we’d like to do to AST classes for 7.0.0, we would like to
+hide some methods and constructors that rule writers should not have access to.
+The following usages are now deprecated in the Java AST (with other languages to come):
+
+
+
Manual instantiation of nodes. Constructors of node classes are deprecated and marked InternalApi. Nodes should only be obtained from the parser, which for rules, means that never need to instantiate node themselves. Those constructors will be made package private with 7.0.0.
+
Subclassing of abstract node classes, or usage of their type. Version 7.0.0 will bring a new set of abstractions that will be public API, but the base classes are and will stay internal. You should not couple your code to them.
+
+
In the meantime you should use interfaces like JavaNode or Node, or the other published interfaces in this package, to refer to nodes generically.
+
Concrete node classes will be made final with 7.0.0.
+
+
+
Setters found in any node class or interface. Rules should consider the AST immutable. We will make those setters package private with 7.0.0.
The DumpFacades in all languages, that could be used to transform a AST into a textual representation,
+will be removed with PMD 7. The rule designer is a better way to inspect nodes.
+
The start scripts run.sh, pmd.bat and cpd.bat support the new environment variable PMD_JAVA_OPTS.
+This can be used to set arbitrary JVM options for running PMD, such as memory settings (e.g. PMD_JAVA_OPTS=-Xmx512m)
+or enable preview language features (e.g. PMD_JAVA_OPTS=--enable-preview).
+
+
The previously available variables such as OPTS or HEAPSIZE are deprecated and will be removed with PMD 7.0.0.
+
+
Deprecated API
+
+
+
+
CodeClimateRule is deprecated in 7.0.0 because it was unused for 2 years and
+created an unwanted dependency.
+Properties “cc_categories”, “cc_remediation_points_multiplier”, “cc_block_highlighting” will also be removed.
+See #1702 for more.
+
+
+
The Apex ruleset rulesets/apex/ruleset.xml has been deprecated and will be removed in 7.0.0. Please use the new
+quickstart ruleset rulesets/apex/quickstart.xml instead.
The properties framework is about to get a lifting, and for that reason, we need to deprecate a lot of APIs
+to remove them in 7.0.0. The proposed changes to the API are described on the wiki
+
+
Changes to how you define properties
+
+
+
+
Construction of property descriptors has been possible through builders since 6.0.0. The 7.0.0 API will only allow
+construction through builders. The builder hierarchy, currently found in the package net.sourceforge.pmd.properties.builders,
+is being replaced by the simpler PropertyBuilder. Their APIs enjoy a high degree of source compatibility.
+
+
+
Concrete property classes like IntegerProperty and StringMultiProperty will gradually
+all be deprecated until 7.0.0. Their usages should be replaced by direct usage of the PropertyDescriptor
+interface, e.g. PropertyDescriptor<Integer> or PropertyDescriptor<List<String>>.
+
+
+
Instead of spreading properties across countless classes, the utility class PropertyFactory will become
+from 7.0.0 on the only provider for property descriptor builders. Each current property type will be replaced
+by a corresponding method on PropertyFactory:
MethodProperty, FileProperty, TypeProperty and their multi-valued counterparts
+are discontinued for lack of a use-case, and have no planned replacement in 7.0.0 for now.
+
+
+
+
+
+
Here’s an example:
+
// Before 7.0.0, these are equivalent:
+IntegerPropertymyProperty=newIntegerProperty("score","Top score value",1,100,40,3.0f);
+IntegerPropertymyProperty=IntegerProperty.named("score").desc("Top score value").range(1,100).defaultValue(40).uiOrder(3.0f);
+
+// They both map to the following in 7.0.0
+PropertyDescriptor<Integer>myProperty=PropertyFactory.intProperty("score").desc("Top score value").require(inRange(1,100)).defaultValue(40);
+
+
+
You’re highly encouraged to migrate to using this new API as soon as possible, to ease your migration to 7.0.0.
preferredRowCount is deprecated with no intended replacement. It was never implemented, and does not belong
+in this interface. The methods uiOrder and compareTo(PropertyDescriptor) are deprecated for the
+same reason. These methods mix presentation logic with business logic and are not necessary for PropertyDescriptors to work.
+PropertyDescriptor will not extend Comparable<PropertyDescriptor> anymore come 7.0.0.
+
The method propertyErrorFor is deprecated and will be removed with no intended
+replacement. It’s really just a shortcut for prop.errorFor(rule.getProperty(prop)).
+
T valueFrom(String) and String asDelimitedString(T) are deprecated and will be removed. These were
+used to serialize and deserialize properties to/from a string, but 7.0.0 will introduce a more flexible
+XML syntax which will make them obsolete.
+
isMultiValue and type are deprecated and won’t be replaced. The new XML syntax will remove the need
+for a divide between multi- and single-value properties, and will allow arbitrary types to be represented.
+Since arbitrary types may be represented, type will become obsolete as it can’t represent generic types,
+which will nevertheless be representable with the XML syntax. It was only used for documentation, but a
+new way to document these properties exhaustively will be added with 7.0.0.
+
errorFor is deprecated as its return type will be changed to Optional<String> with the shift to Java 8.
+
+
+
Deprecated APIs
+
+
For internalization
+
+
+
+
The implementation of the adapters for the XPath engines Saxon and Jaxen (package net.sourceforge.pmd.lang.ast.xpath)
+are now deprecated. They’ll be moved to an internal package come 7.0.0. Only Attribute remains public API.
The method getVariableName on those two nodes will be removed, too.
+
+
+
+
All these are deprecated because those nodes may declare several variables at once, possibly
+with different types (and obviously with different names). They both implement Iterator<ASTVariableDeclaratorId>
+though, so you should iterate on each declared variable. See #910.
+
+
+
Visitor decorators are now deprecated and will be removed in PMD 7.0.0. They were originally a way to write
+composable visitors, used in the metrics framework, but they didn’t prove cost-effective.
The LanguageModules of several languages, that only support CPD execution, have been deprecated. These languages
+are not fully supported by PMD, so having a language module does not make sense. The functionality of CPD is
+not affected by this change. The following classes have been deprecated and will be removed with PMD 7.0.0:
Optional AST processing stages like symbol table, type resolution or data-flow analysis will be reified
+in 7.0.0 to factorise common logic and make them extensible. Further explanations about this change can be
+found on #1426. Consequently, the following APIs are deprecated for
+removal:
A couple of methods and fields in net.sourceforge.pmd.properties.AbstractPropertySource have been
+deprecated, as they are replaced by already existing functionality or expose internal implementation
+details: propertyDescriptors, propertyValuesByDescriptor,
+copyPropertyDescriptors(), copyPropertyValues(), ignoredProperties(), usesDefaultValues(),
+useDefaultValueFor().
+
+
+
Some methods in net.sourceforge.pmd.properties.PropertySource have been deprecated as well:
+usesDefaultValues(), useDefaultValueFor(), ignoredProperties().
+
+
+
The class net.sourceforge.pmd.lang.rule.AbstractDelegateRule has been deprecated and will
+be removed with PMD 7.0.0. It is internally only in use by RuleReference.
+
+
+
The default constructor of net.sourceforge.pmd.lang.rule.RuleReference has been deprecated
+and will be removed with PMD 7.0.0. RuleReferences should only be created by providing a Rule and
+a RuleSetReference. Furthermore the following methods are deprecated: setRuleReference(),
+hasOverriddenProperty(), usesDefaultValues(), useDefaultValueFor().
+
+
+
+
6.7.0
+
+
+
+
All classes in the package net.sourceforge.pmd.lang.dfa.report have been deprecated and will be removed
+with PMD 7.0.0. This includes the class net.sourceforge.pmd.lang.dfa.report.ReportTree. The reason is,
+that this class is very specific to Java and not suitable for other languages. It has only been used for
+YAHTMLRenderer, which has been rewritten to work without these classes.
+
+
+
The nodes RUNSIGNEDSHIFT and RSIGNEDSHIFT are deprecated and will be removed from the AST with PMD 7.0.0.
+These represented the operator of ShiftExpression in two cases out of three, but they’re not needed and
+make ShiftExpression inconsistent. The operator of a ShiftExpression is now accessible through
+ShiftExpression#getOperator.
+
+
+
+
6.5.0
+
+
+
+
The utility class net.sourceforge.pmd.lang.java.ast.CommentUtil has been deprecated and will be removed
+with PMD 7.0.0. Its methods have been intended to parse javadoc tags. A more useful solution will be added
+around the AST node FormalComment, which contains as children JavadocElement nodes, which in
+turn provide access to the JavadocTag.
+
+
All comment AST nodes (FormalComment, MultiLineComment, SingleLineComment) have a new method
+getFilteredComment() which provide access to the comment text without the leading /* markers.
+
+
+
The method AbstractCommentRule.tagsIndicesIn() has been deprecated and will be removed with
+PMD 7.0.0. It is not very useful, since it doesn’t extract the information
+in a useful way. You would still need check, which tags have been found, and with which
+data they might be accompanied.
+
+
+
+
6.4.0
+
+
+
The following classes in package net.sourceforge.pmd.benchmark have been deprecated: Benchmark, Benchmarker,
+BenchmarkReport, BenchmarkResult, RuleDuration, StringBuilderCR and TextReport. Their API is not supported anymore
+and is disconnected from the internals of PMD. Use the newer API based around TimeTracker instead, which can be found
+in the same package.
+
The class net.sourceforge.pmd.lang.java.xpath.TypeOfFunction has been deprecated. Use the newer TypeIsFunction in the same package.
+
The typeof methods in net.sourceforge.pmd.lang.java.xpath.JavaFunctions have been deprecated.
+Use the newer typeIs method in the same class instead..
+
The methods isA, isEither and isNeither of net.sourceforge.pmd.lang.java.typeresolution.TypeHelper.
+Use the new isExactlyAny and isExactlyNone methods in the same class instead.
+
+
+
6.2.0
+
+
+
+
The static method PMDParameters.transformParametersIntoConfiguration(PMDParameters) is now deprecated,
+for removal in 7.0.0. The new instance method PMDParameters.toConfiguration() replaces it.
+
+
+
The method ASTConstructorDeclaration.getParameters() has been deprecated in favor of the new method
+getFormalParameters(). This method is available for both ASTConstructorDeclaration and
+ASTMethodDeclaration.
+
+
+
+
6.1.0
+
+
+
The method getXPathNodeName is added to the Node interface, which removes the
+use of the toString of a node to get its XPath element name (see #569).
+
+
The default implementation provided in AbstractNode, will
+be removed with 7.0.0
+
With 7.0.0, the Node.toString method will not necessarily provide its XPath node
+name anymore.
+
+
+
+
The interface net.sourceforge.pmd.cpd.Renderer has been deprecated. A new interface
+net.sourceforge.pmd.cpd.renderer.CPDRenderer has been introduced to replace it. The main
+difference is that the new interface is meant to render directly to a java.io.Writer
+rather than to a String. This allows to greatly reduce the memory footprint of CPD, as on
+large projects, with many duplications, it was causing OutOfMemoryErrors (see #795).
+
+
net.sourceforge.pmd.cpd.FileReporter has also been deprecated as part of this change, as it’s no longer needed.
+
+
+
+
6.0.1
+
+
+
The constant net.sourceforge.pmd.PMD.VERSION has been deprecated and will be removed with PMD 7.0.0.
+Please use net.sourceforge.pmd.PMDVersion.VERSION instead.
The Java rule LooseCoupling in ruleset java-typeresolution is deprecated. Use the rule with the same name from category bestpractices instead.
+
+
+
The Java rule CloneMethodMustImplementCloneable in ruleset java-typeresolution is deprecated. Use the rule with the same name from category errorprone instead.
+
+
+
The Java rule UnusedImports in ruleset java-typeresolution is deprecated. Use the rule with
+the same name from category bestpractices instead.
+
+
+
The Java rule SignatureDeclareThrowsException in ruleset java-typeresolution is deprecated. Use the rule with the same name from category design instead.
+
+
+
The Java rule EmptyStaticInitializer in ruleset java-empty is deprecated. Use the rule EmptyInitializer, which covers both static and non-static empty initializers.`
+
+
+
The Java rules GuardDebugLogging (ruleset java-logging-jakarta-commons) and GuardLogStatementJavaUtil
+(ruleset java-logging-java) have been deprecated. Use the rule GuardLogStatement, which covers all cases regardless of the logging framework.
The Java rule AvoidFinalLocalVariable (java-codestyle) has been deprecated
+and will be removed with PMD 7.0.0. The rule is controversial and also contradicts other existing
+rules such as LocalVariableCouldBeFinal. If the goal is to avoid defining
+constants in a scope smaller than the class, then the rule AvoidDuplicateLiterals
+should be used instead.
The Java rule LoggerIsNotStaticFinal (java-errorprone) has been deprecated
+and will be removed with PMD 7.0.0. The rule is replaced by ProperLogger.
+
+
+
The Java rule DataflowAnomalyAnalysis (java-errorprone)
+is deprecated in favour of UnusedAssignment (java-bestpractices),
+which was introduced in PMD 6.26.0.
It uses Jekyll to generate the static html pages. Jekyll is
+executed by github for every push to the repository. Please note, that it takes some time
+until Jekyll has been executed and due to caching, the homepage is not updated immediately.
+It usually takes 15 minutes.
The PMD documentation of the latest release is simply copied as static html into the folder latest/.
+This makes the latest release documentation available under the stable URL
+https://pmd.github.io/latest/. This URL is also used for the sitemap.xml.
+
+
+
Documentation for previous releases are still being kept under the folders pmd-<version>/.
+
+
+
Building the page locally
+
+
Since the repository contains the documentation for many old PMD releases, it is quite big. When executing
+Jekyll to generate the site, it copies all the files to the folder _site/ - and this can take a while.
+
+
In order to speed things up locally, consider to add pmd-* to the exclude patterns in _config.yml. See
+also the comments in this file.
+
+
Then it is a matter of simply executing bundle exec jekyll serve. This will generate the site and host
+it on localhost, so you can test the page at http://127.0.0.1:4000.
+
+
Updates during a release
+
+
When creating a new PMD release, some content of the main page need to be updated as well.
+This done as part of the Release process, but is
+summarized here as well:
+
+
+
The versions (e.g. pmd.latestVersion) needs to be updated in _config.yml
+
+
This is needed to generate the correct links and texts for the latest version on landing page
+
+
+
The new PMD documentation needs to be copied to /pmd-<version>/
+
Then this folder needs to copied to /latest/, actually replacing the old version.
+
A new blog post with release notes is added: /_posts/YYYY-mm-dd-PMD-<version>.md
+
The sitemap sitemap.xml is regenerated
+
+
+
Some of these steps are automated through do-release.sh (like blog post), some are manual steps
+(updating the version in _config.yml) and other steps are done on the travis-ci-build (like
+copying the new documentation).
+
+
Adding a new blog post
+
+
Adding a new blog post is as easy as:
+
+
+
Creating a new file in the folder “_posts”: /_posts/YYYY-mm-dd-<title>.md
+
The file name needs to fit this pattern. The date of the blog post is taken from the file name. The “"
+is used for the url.
+
The file is a markdown file starting with a frontmatter for jekyll. Just use this template for the new file:
+
+
+
---
+layout: post
+title: Title
+---
+
+Here comes the text
+
+
+
Once you commit and push it, Github will run Jekyll and update the page. The Jekyll templates take care that
+the new post is recognized and added to the news section and also on the news subpage.
Compilation and checkstyle is verified already by travis build: PRs are automatically checked.
+
If it is a bug fix, a new unit test, that reproduces the bug, is mandatory. Without such a test, we might accidentally reintroduce the bug again.
+
Add the appropriate labels on the github issue: If the PR fixes a bug, the label “a:bug” should be used.
+
Make sure, the PR is added to the appropriate milestone. If the PR fixes a bug, make sure, that the bug issue is added to the same milestone.
+
+
+
+
The actual merge commands:
+
+
We assume, that the PR has been created from the master branch. If this is not the case,
+then we’ll either need to rebase or ask for rebasing before merging.
+
+
git checkout master && git pull origin master # make sure, you have the latest code
+git fetch origin pull/123/head:pr-123 && git checkout pr-123 # creates a new temporary branch
+
Note: If the PR fixes a bug, verify, that we have a commit with the message
+“Fixes #issue-number”. If this doesn’t exist, you can add it to the commit message when
+updating the release notes: Update release notes, refs #123, fixes #issue-number.
+This will automatically close the github issue.
+
+
+
Now merge the pull request into the master branch:
+
+
git checkout master
+git merge --no-ff pr-123
+
+
+
Note: If there are merge conflicts, you’ll need to deal with them here.
+
+
+
Run the complete build: ./mvnw clean verify
+
+
Note: This will execute all the unit tests and the checkstyle tests. It ensures,
+that the complete project can be build and is functioning on top of the current master.
+
+
+
If the build was successful, you are ready to push:
+
+
git push origin master
+
+
+
Since the temporary branch is now not needed anymore, you can delete it:
+git branch -d pr-123.
+
+
+
+
Example 2: Merging PR #124 into a maintenance branch
+
+
We ask, to create every pull request against master, to make it easier to contribute.
+But if a pull request is intended to fix a bug in an older version of PMD, then we need to backport this pull request.
+
+
Creating a maintenance branch
+
+
For older versions, we use maintenance branches, like pmd/5.8.x. If there is no maintenance branch for
+the specific version, then we’ll have to create it first. Let’s say, we want a maintenance branch for
+PMD version 5.8.0, so that we can create a bugfix release 5.8.1.
+
+
+
+
We’ll simply create a new branch off of the release tag:
Now we’ll need to adjust the version, since it’s currently the same as the release version.
+We’ll change the version to the next patch version: “5.8.1-SNAPSHOT”.
+
+
./mvnw versions:set -DnewVersion=5.8.1-SNAPSHOT
+git add pom.xml \*/pom.xml
+git commit -m "prepare next version 5.8.1-SNAPSHOT"
+
+
+
+
+
Merging the PR
+
+
+
+
As above: Review the PR
+
+
+
Fetch the PR and rebase it onto the maintenance branch:
+
+
git fetch origin pull/124/head:pr-124 && git checkout pr-124 # creates a new temporary branch
+git rebase master --onto pmd/5.8.x
+./mvnw clean verify # make sure, everything works after the rebase
+
+
+
Note: You might need to fix conflicts / backport the commits for the older
+PMD version.
+
+
+
Update the release notes. See above for details.
+
+
+
Now merge the pull request into the maintenance branch:
Just to be sure, run the complete build again: ./mvnw clean verify.
+
+
+
If the build was successful, you are ready to push:
+
+
git push origin pmd/5.8.x
+
+
+
+
Since we have rebased the pull request, it won’t appear as merged on github.
+You need to manually close the pull request. Leave a comment, that it has been
+rebased onto the maintenance branch.
+
+
+
+
Merging into master
+
+
Now the PR has been merged into the maintenance branch, but it is missing in any later version of PMD.
+Therefore, we merge first into the next minor version maintenance branch (if existing):
+
+
git checkout pmd/5.9.x
+git merge pmd/5.8.x
+
+
+
After that, we merge the changes into the master branch:
+
+
git checkout master
+git merge pmd/5.9.x
+
+
+
Note: This ensures, that every change on the maintenance branch eventually ends
+up in the master branch and therefore in any future version of PMD.
+The downside is however, that there are inevitable merge conflicts for the maven pom.xml files, since
+every branch changed the version number differently.
+We could avoid this by merging only the temporary branch “pr-124” into each maintenance branch and
+eventually into master, with the risk of missing single commits in a maintenance branch, that have been
+done outside the temporary branch.
+
+
Merging vs. Cherry-Picking
+
+
We are not using cherry-picking, so that each fix is represented by a single commit.
+Cherry-picking would duplicate the commit and you can’t see in the log, on which branches the fix has been
+integrated (e.g. gitk and github show the branches, from which the specific commit is reachable).
+
+
The downside is a more complex history - the maintenance branches and master branch are “connected” and not separate.
This page describes the current status of the release process.
+
+
Since versions 5.4.5 / 5.5.4 there is an automated release process using travis-ci
+in place. However, there are still a few steps, that need manual examination.
+
+
Note: You can find a small shell script in the root of the repo: do-release.sh. This script guides you
+through the release process.
+
+
Preparations
+
+
Make sure code is up to date and everything is committed and pushed with git:
+
+
$ ./mvnw clean
+$ git pull
+$ git status
+
+
+
The Release Notes and docs
+
+
You can find the release notes here: docs/pages/release_notes.md.
+
+
The date (date +%d-%B-%Y) and the version (remove the SNAPSHOT) must be updated in docs/_config.yml, e.g.
The release type could be one of “bugfix”, “minor”, or “major”.
+
+
The release notes usual mention any new rules that have been added since the last release.
+Please double check the file pmd-core/src/main/resources/rulesets/releases/<version>.xml, so
+that all new rules are listed.
+
+
Add the new rules as comments to the quickstart rulesets:
We maintain a documentation for the next major release. Copy the API
+changes from the current release notes to this document: docs/pages/next_major_development.md.
Starting with PMD 6.23.0 we’ll provide small statistics for every release. This needs to be added
+to the release notes as the last section. To count the closed issues and pull requests, the milestone
+on github with the title of the new release is searched. Make sure, there is a milestone
+on https://github.com/pmd/pmd/milestones. The following snippet will
+create the numbers, that can be attached to the release notes as a last section:
Also move the previous version down into the “downloads” section.
+
+
Then create a new page for the new release, e.g. _posts/2020-03-12-PMD-6.22.0.md and copy
+the release notes into this page. This will appear under the news section.
The release is created using the maven-release-plugin. This plugin changes the version by basically
+removing the “-SNAPSHOT” suffix, builds the changed project locally, commits the version change, creates
+a new tag from this commit, changes the version of the project to the next snapshot, commits this change
+and pushes everything.
+
+
RELEASE_VERSION is the version of the release. It is reused for the tag. DEVELOPMENT_VERSION is the
+next snapshot version after the release.
Once the maven plugin has pushed the tag, travis-ci will start and build a new version from this tag. Since
+it is a tag build and a released version build, travis-ci will do a couple of additional stuff:
Upload the new binaries additionally to sourceforge, so that they can be downloaded from
+https://sourceforge.net/projects/pmd/files/pmd/, including the release notes. The new binaries are
+selected as the new default downloads for PMD.
+
Add the documentation of the new release to a subfolder on https://pmd.github.io, also make
+this folder available as latest.
If the release was done on a maintenance branch, such as pmd/5.4.x, then this branch should be
+merged into the next “higher” branches, such as pmd/5.5.x and master.
+
+
This ensures, that all fixes done on the maintenance branch, finally end up in the other branches.
+In theory, the fixes should already be there, but you never now.
+
+
Multiple releases
+
+
If releases from multiple branches are being done, the order matters. You should start from the “oldest” branch,
+e.g. pmd/5.4.x, release from there. Then merge (see above) into the next branch, e.g. pmd/5.5.x and release
+from there. Then merge into the master branch and release from there. This way, the last release done, becomes
+automatically the latest release on https://pmd.github.io/latest/ and on sourceforge.
+
+
(Optional) Create a new release branch
+
+
At some point, it might be time for a new maintenance branch. Such a branch is usually created from
+the master branch. Here are the steps:
+
+
+
Create a new branch: git branch pmd/5.6.x master
+
Update the version in both the new branch and master, e.g. mvn versions:set -DnewVersion=5.6.1-SNAPSHOT
+and mvn versions:set -DnewVersion=5.7.0-SNAPSHOT.
+
Update the release notes on both the new branch and master
Raik Schroeder - data flow analysis layer, YAHTMLRenderer
+
Steve Hawkins - rewrite of CPD based on Karp-Rabin string matching
+
Daniel Sheppard - XPath engine integration concept and implementation, advice on Jaxen extension function naming
+
Brian Ewins - complete rewrite of CPD based on the Burrows-Wheeler transform, fixed DocumentNavigator bug
+
+
+
Contributors
+
+
+
Andy Throgmorton - New XPath getCommentOn function, new rule DontCallThreadRun, fix for rule UseArraysAsList
+
Nicolas Dordet - Fixed an issue on CloseResource
+
Juan Jesús García de Soria - Rework CPD algorithm
+
Sergey Pariev - Fixed an ugly ArrayIndexOutOfBoundsException in CPD for Ruby
+
Chris Heister - Reported and noted proper fix for bug in IDEAJ renderer operations
+
Ralf Wagner - Reported bug in UselessOperationOnImmutable, reported and noted proper fix for broken XSLT
+
Caroline Rioux - Reported bug in ImmutableField
+
Miroslav Šulc - Reported bug in CloneMethodMustImplementCloneable
+
Thomas Steininger - Noticed redundant rule
+
Thomas Leplus - Contributed new rules LogicInversion, ExtendsObject, UselessParentheses, EmptyInitializer,
+EmptyStatementBlock, CheckSkipResult.Rewrote UselessStringValueOf, nice patch for ClassCastExceptionWithToArray
+
Paul Sundling - A nice documentation patch for ruleset links
+
Matt Koch - Added more detail to PMD XML report
+
Richard Hands - Fixed CPD symlink confusion
+
Oleg Skrypnyuk - reported a Java 1.5 grammar bug
+
Jeff Campbell - Found bug and suggested fix for problem with XMLRenderer and SuppressWarnings(“PMD”) annotations
+
Kris Jurka - CPD patch to accept “.C” as a filename extension for C/C++ files
+
Florian Deissenboeck - reported several Java 1.5 grammar bugs
+
Maarten ter Huurne - BooleanGetMethodName, AddEmptyString, Noticed misspelling in AvoidArrayLoops rule
+
Lukas Theussl - Patch to bring Maven configuration files up to date
+
Jason Bennett - Rewrite of annotation-based warning suppression to allow for rule-specific suppression,
+noticed useless line in XSLT scripts, fix for UnnecessaryLocalBeforeReturn, wrote NPathComplexity rule,
+patches to improve CyclomaticComplexity rule, Implemented: UseCollectionIsEmpty, NcssTypeCount, NcssMethodCount,
+NcssConstructor, Patch to detect comparison with new Object
Peter Van de Voorde - Rewrote the ‘create rule XML’ functionality in the designer utility
+
Josh Devins - Reported bug with annotation parsing
+
Alan Berg - Reported bug in Ant task
+
George Thomas - Wrote AvoidRethrowingException rule, new AvoidLosingExceptionInformation rule
+
Robert Simmons - Reported bug in optimizations package along with suggestions for fix
+
Brian Remedios - display cleanup of CPD GUI, code cleanup of StringUtil and various rules,
+cleanup of rule designer, code cleanup of net.sourceforge.pmd.ant.Formatter.java,
+code improvements to Eclipse plugin, created AbstractPoorMethodCall and refactored UseIndexOfChar
+
Max Tardiveau - A nice XML to HTML stylesheet for CPD.
+
Ernst Reissner - reported IdempotentOperations bug, reported CloneThrowsCloneNotSupportedException bug,
+reported Java 1.5 parsing bug, suggested InstantiationToGetClass, bug reports for
+UnusedPrivateField/CloseConnectionRule/ConstructorCallsOverridableMethodRule,
+and bug report and documentation suggestions for UseSingletonRule
+
Maarten Coene - bug report for UnnecessaryConversionTemporary
+
Jorn Stampehl - Reported bug in UnusedModifier, reported and fixed bugs in
+JUnitTestsShouldContainAsserts/CyclomaticComplexity/TooManyFields, noticed redundancy of ExplicitCallToFinalize,
+reported bug in AvoidCallingFinalize, reported bug in JUnitAssertionsShouldIncludeMessage,
+reported bug in bug report on JUnitTestsShouldContainAsserts
+
Ulrich Kriegel - reported Ant task documentation bug
+
Jarkko Hietaniemin - rewrote most of cpd.sh, many C grammar improvements, several CPD documentation suggestions,
+noted missing CPD scripts in binary release
+
Adam Zell - Reported bug in UselessOverridingMethod
+
Daniel Serodio - Reported bug in ExceptionSignatureDeclaration
+
John Redford - Reported bug in AvoidProtectedFieldInFinalClass
+
D’Arcy Smith - Reported bug in UncommentedEmptyConstructor, reported missing RuleViolation methods
+
Paul Field - Fixed bug in MissingBreakInSwitch, reported a bug in DontImportJavaLang
+
Attila Korompai - A nice patch to add messages to the NOPMD feature
+
Levent Gurses - Suggested JSP support for the copy/paste detector
+
Neil Cafferkey - Reported a typo in AssignmentInOperand
+
Noel Grandin - bug report for ImmutableField, bug report for MissingStaticMethodInNonInstantiatableClass,
+bug report for MissingBreakInSwitch, EqualsNull rule, bug report for IfElseStmtsMustUseBracesRule
+
Olaf Heimburger - wrote the UseProperClassLoader rule, code changes to get JDeveloper plugin working
+under JDev 10.1.3 EA, reported a possible NPE in ReportTree
+
Mohammad Farooq - Reported new JavaNCSS URL
+
Jeff Jensen - Reported missing XML schema references in documentation, wrote new XML schema, reported missing
+schema refs in example rulesets, suggested posting XML schema on PMD site, discussion of
+‘comments in catch block’ feature, suggested description attribute in property element
+
Christopher Stach - bug report for VariableNamingConventions, bug report for CallSuperInConstructor,
+many bug reports for rules that didn’t handle Java 1.5 constructs
+
Matthew Harrah - noticed missing element in UseCorrectExceptionLogging definition, script bug report
+
Mike Kaufman - Reported abug in UnnecessaryCaseChange
+
Elliotte Rusty Harold - reported bug in UseAssertSameInsteadOfAssertTrue,
+suggested creating a new ruleset containing rules in each release, UncommentedEmptyConstructor suggestions,
+noted missed case for UnusedFormalParameter, documentation suggestions,
+reported mistake in UnnecessaryLocalBeforeReturn message,
+bug report 1371757 for misleading AvoidSynchronizedAtMethodLevel example,
+bug report 1293277 for duplicated rule messages, bug report for ConstructorCallsOverridableMethod,
+suggestion for improving command line interface, misspelling report, suggestion for improving Designer
+startup script, “how to make a ruleset” documentation suggestions, noticed outdated Xerces jars,
+script renaming suggestions, UseLocaleWithCaseConversions rule suggestion
+
David Karr - reported stale XPath documentation
+
Dawid Weiss - Reported bug in UnusedPrivateMethod
+
Shao Lo - Reported bug in CPD
+
Mathieu Champlon - Added language support to the CPD Ant task
+
Uroshnor - Reported bug in UseNotifyAllInsteadOfNotify
+
Jan Koops - Noted missing data in MemberValuePair nodes, bug report for JBuilder plugin
+
Will Sargent - Implemented AvoidThreadGroup, AvoidThrowingCertainExceptionTypesRule,
+AvoidCatchingNPERule, ExceptionAsFlowControlRule, URL updates for ‘Similar projects’ page
+
Benoit Xhenseval - noted Maven plugin bug (http://jira.codehaus.org/browse/MPPMD-24),
+bug report for UnusedPrivateMethod, suggestion to add elapsed time to XML report,
+bug report for ImmutableField, many bug reports (with good failure cases!), Ant task patch and bug report,
+XSLT patch, suggestion for improving XML report
+
Barak Naveh - Reported and fixed bug in CallSuperInConstructor
+
Bhatia Saurabh - Reported a grammar bug, reported a bug in UseStringBufferLength
+
Chris Erskine - found bad link, documentation suggestions
+
mhilpert - Reported bugs in UseIndexOfChar and LoggerIsNotStaticFinal
+
David Corley - Priority filtering XSLT, reported release packaging problem, implemented nifty
+Javascript folding for XML report, demo is here,
+suggestion for min priority on the command line
+
Jon Doh - Reported parser bug
+
Brian R - suggestions for improving UseIndexOfChar, documentation suggestion
+
Didier Duquennoy - bug reports for InefficientStringBuffering/ConsecutiveLiteralAppends/AppendCharacterWithChar,
+several bug reports for InefficientStringBuffering, bug report for ImmutableField, suggestions for
+improving Benchmark utility, bug report for InefficientStringBuffering, bug report for
+AvoidConcateningNonLiteralsInStringBuffer, reported a missed hit for EqualsNull, bug report for
+MissingStaticMethodInNonInstantiatableClass, pmd-netbeans feedback
+
Paul Smith - patch to fix Ant task ‘minimum priority’ attribute
+
Erik Thauvin - reported IDEA integration problem
+
John Kenny - reported bug in ConsecutiveLiteralAppends
+
Tom Judge - patch for fix to C/C++ multiline literal support for CPD, patch for including .cc files in
+C++ CPD checks, patch for JDK compatibility problems
+
Sean Mountcastle - reported documentation bug
+
Greg Broderick - provided patch for ‘minimum priority’ support
+
George Sexton - Bug report 1379701 for CompareObjectsWithEquals, suggested new rule for Additional String
+Concatenation Warnings in StringBuffer.
+
Johan Stuyts - improvements to UncommentedEmptyConstructor, nice patch for UncommentedEmptyConstructor and
+UncommentedEmptyMethod, patch to allow empty catch blocks with comments in them, patch to clean up build environment
+
Bruce Kelly - bug report 1378358 for StringInstantiation, bug report 1376756 for UselessOverridingMethod,
+bug report 1376760 for InefficientStringBuffering
+
Isaac Babsky - tweak for pmd.bat
+
Hendrik Maryns - reported bug 1375290 for SuppressWarnings facility
+
Wim Deblauwe - suggested UseAssertNullInsteadOfAssertTrue,
+bug report 1373510 for UseAssertSameInsteadOfAssertTrue, suggested putting property names/values in generated docs,
+UselessOverridingMethod, reported bug in JUnitTestsShouldContainAsserts,
+front page and “how to make a ruleset” patches, noted problems with web site rule index,
+bug report for JUnitTestsShouldContainAsserts, Clover license coordination and implementation,
+UseCorrectExceptionLogging, coordinated and coded a much nicer asXML() implementation,
+suggested cleanup of UnusedFormalParameter, Javadoc patch, SystemPrintln bug report,
+helped get Ant task and CLI squared away with Java 1.5 params, Java 1.5-specific bug reports,
+suggested improvements for ExceptionSignatureDeclaration
+
Sean Montgomery - bug report 1371980 for InefficientStringBuffering
+
Jean-Marc Vanel - suggested enhancements to the PMD scoreboard
+
Andriy Rozeluk - suggested UseStringBufferLength, bug report 1306180 for
+AvoidConcatenatingNonLiteralsInStringBuffer, reported bug 1293157 for UnusedPrivateMethod,
+suggested UnnecessaryCaseChange, bug report for SimplifyConditional, suggested UnnecessaryLocalBeforeReturn,
+suggestions for improving BooleanInstantiation, UnnecessaryReturn, AvoidDuplicateLiterals RFEs and bug reports,
+various other RFEs and thoughtful discussions as well
+
Bruno Juillet - suggested reporting suppressed warnings, bug report for missing package/class/method names,
+patch for Ant task’s excludeMarker attribute, bug report on ruleset overrides
+
Derek Hofmann - suggestion for adding –skip-duplicate-files option for CPD, bug report for CPD skipping header
+files when in C/C++ mode
+
Mark Holczhammer - bug report for InefficientStringBuffering
+
Raja Rajan - 2 bug reports for CompareObjectswithEquals
+
Jeff Chamblee - suggested better message for UnnecessaryCaseChange, bug report for CompareObjectsWithEquals
+
Dave Brosius - suggested MisleadingVariableName rule, a couple of nice patches to clean up some string handling
+inefficiencies, non-static class usages, and unclosed streams/readers - found with Findbugs, I daresay :-)
+
Chris Grindstaff - fixed SWTException when Eclipse plugin is run on a file with syntax error
+
Eduard Naum - fixed JDK 1.3 runtime problems in Eclipse plugin
+
Jacques Lebourgeois - fix for UTF8 characters in Eclipse plugin
+
dvholten - suggestions for improving OverrideBothEqualsAndHashcode, formatting suggestions for HTML report,
+test cases for ConstructorCallsOverridableMethod, reported several NullAssignment bugs
+
Brian Duff - helped get Oracle JDeveloper plugin working
+
Sivakumar Mambakkam - bug report 1314086 for missing name in SimpleRuleSetNameMapper
+
Rodrigo Ruiz - bug report 1312723 for FieldDeclaration nodes inside interfaces, bug report 1312754 for
+pmd.bat option handling, bug report 1312720 (and code fix!) for DefaultPackage, bug report 1309235 for TooManyFields
+
Lori Olson - JBuilder plugin suggestions and prerelease tests,
+found copy/paste bug in rule descriptions
+
Thomas Dudziak - bug report 1304739 for StringInstantiation
+
Pieter Bloemendaal - reported JDK 1.3 parsing bug 1292609, command line docs bug report,
+bug report for UnusedPrivateMethod, found typo in ArrayIsStoredDirectly, bug report for
+AvoidReassigningParametersRule
+
shawn2005 - documentation bug report
+
Andrew Taylor - bug report for StringInstantiation
+
S. David Pullara - bug report for AvoidConcateningNonLiteralsInStringBuffer, bug report for ImmutableField
+
Maarten Bodewes - bug report for ImmutableField
+
Peter Frandsen - PackageCase rule, NoPackage rule
+
Noureddine Bekrar - French translation of some PMD documentation
+
Martin Jost - bug report for JDeveloper plugin
+
Guillaume Boudreau - patches to fix problems with CPD’s FileFinder and NTFS and SCCS
+
Sylvain Veyrie - bug report for MethodReturnsInternalArray
+
Randy Ray - bug report for ArrayIsStoredDirectly
+
Klaus - Suggestion for improving UseSingleton
+
Nicolai Czempin - Bug report for UnnecessaryParentheses, various rule suggestions, additional PMD backronyms
+
Kevin Routley - reported Ant task dependency problem, reported problems with RuleSetFactory unit tests
+
Dennis Klemann - noted that errors were missing from text report, reported Java 1.5 parsing bug with
+ExceptionSignatureDeclaration, reported fix for pmd.bat problem
+
Tor Norbye - Suggested CompareObjectsWithEquals
+
Thomas Skariah - bug reports for MethodArgumentCouldBeFinal and AvoidReassigningParameters
+
Tom Parker - bug report for MethodReturnsInternalArray, found missed case in NullAssignment, suggested addition
+to UnnecessaryBooleanAssertion, suggested splitting up AvoidThrowingCertainExceptionTypes,
+AvoidInstantiatingObjectsInLoops bug report, AtLeastOneConstructor bug report
Maik Schreiber - AccessNode bug report, other bug reports
+
Lokesh Gupta - improvements to the AST viewer
+
Jesse Glick - improvements to
+VariableNamingConventionsRule, patch for UnusedModifierRule, bug fix for VariableNameDeclarations rule,
+an excellent discussion on the UnnecessaryConstructorRule
+
Nicolas Liochon - CloneShouldCallSuperCloneRule implementation
+
Slava Pestov - Suggestions for jEdit plugin enhancements.
+
Olivier Mengué - Diagnosed and patched XML report character encoding problems
Vladimir Bossicard - suggested AbstractNamingRule, test package
+organization suggestions, VBHTMLRenderer, numerous feature requests and bug reports, several rule suggestions
+derived from JUnit-Addons, evangelism :-)
Alan Hohn - for adding Standard and modified cyclomatic complexity rules
+
Jan van Nunen - for adding CPD support for Matlab, Objective-C, Python, Scala and various bug fixes
+
Juan Martín Sotuyo Dodero - for many bugfixes/pull requests improving Java grammar and performance
+
+
+
Organizations
+
+
+
+
+
+ MicroDoc for sponsoring PMD development.
+ MicroDoc is a software business serving an international customer base. Since 1991 MicroDoc
+ has grown into a technology oriented software engineering and professional services company.
+ Our focus on complex software technology and software infrastructure made us a well
+ respected partner for large corporations and even for other software businesses.
+
+
+
+
+
+ AE for the JSP integration and especially for writing the JSP grammar.
+
+
+
+
+
+ DARPA for funding
+ the Ultra*Log and Cougaar
+ effort which spawned PMD.
+
+
+
+
+
+ SourceForge for providing hosting services for PMD.
+
+ Cenqua for
+ giving us a free Clover license and doing a nice FishEye run.
+
+
+
+
+
+ YourKit is kindly supporting open source projects with its full-featured Java Profiler.
+ YourKit, LLC is creator of innovative and intelligent tools for profiling
+ Java and .NET applications. Take a look at YourKit's leading software products:
+ YourKit Java Profiler and
+ YourKit .NET Profiler.
+
Have this clear: having a projects with no pmd violations does not mean at all, I repeat,
+it does not mean at all, not at the minimum expected, that the project has any quality.
+For illustrating this I’ll tell a little story taken from my work (a sadly real story).
+Some classes had fields that were reported as unused, (unused code ruleset) as developers
+saw this, they wanted to remove the violation, (not fix the code, fix the violation) so
+the action took was to add useless log sentences with something like:
+‘unused variable ‘+unusedVariable. Believe it or not, the code was worse than the original
+and reported less pmd violations.
+
+
In a more positive way: use the rules as you see them fix, don’t try to remove violations
+per-se, try to review the code and see if the particular cases you are using are correct or not.
+
+
Development
+
+
In which order are nodes visited?
+
+
The parser performs a depth-first traversal.
+Consider the given source:
+
+
public class Foo {
+ String name;
+ private class Bar {
+ String x;
+ }
+ int total;
+}
+
+
+
The visiting order here will be:
+
+
+
Class Foo
+
Field name
+
Class Bar
+
Field x
+
Field total
+
+
+
Note that the total field of Foo will be visited after visiting the fields in Bar.
+You must take this into account for certain rules.
+
+
Is there a simple way of getting fields from a given class?
+
+
Yes, the symbol table can supply that information.
July 2007 - Ryan Slobojan’s article on InfoQ
+discusses the PMD 4.0 release.
+
+
+
July 2006 - Paul Duvall’s article “Automation for the people: Continuous Inspection” on
+developerWorks discusses CPD.
+
+
+
June 2006 - Andrew Glover’s article “In pursuit of code quality: Tame the chatterbox” on
+developerWorks
+discusses PMD and JavaNCSS.
+
+
+
June 2006 - Tom Copeland’s article “Static Electricity: Better Living with Static Code Analysis” in
+Better Software discusses
+PMD/CPD analyses of Azureus and Columba.
+
+
+
April 2006 - John Ferguson Smart’s article “PMD Squashes Code Bugs” on
+DevX discusses PMD and the Eclipse plugin. Lots of screenshots!
+
+
+
November 2005 - Mike Clark’s article “Staying Out of Code Debt” on
+StickyMinds
+mentions both PMD and CPD as useful code-checking tools.
+
+
+
October 2005 - Levent Gurses’ article “Improving Code Quality with PMD and Eclipse” in
+EclipseZone talks about the PMD Eclipse plugin and explains many
+different facets of PMD - XPath, writing rules, the AST, all that. Good stuff!
+
+
+
June 2005 - Amit Chaturvedi’s article “Java & Static Analysis” in
+Doctor Dobb’s Journal talks about PMD and shows a
+screenshot of the rule designer
+
+
+
March 2005 - Kirk Knoernschild’s article “Benefits of the Build” in
+Doctor Dobb’s Journal mentions PMD as a way
+to automate code reviews
QALab - Aggregates PMD + Checkstyle + FindBugs and tracks problems over time
+
+
+
XRadar - Using PMD, CPD, and lots of other projects to give measurements on
+standard software metrics such as package metrics and dependencies, code size and complexity, code duplications,
+coding violations and code-style violations.
Flaw Detector - In beta, does control/data flow analysis
+to detect NullPointerExceptions
+
JStyle - $995, nice folks, lots of metrics and rules
+
JTest - Very nice with tons of features,
+but also very expensive and requires a running X server (or Xvfb) to run on
+Linux. They charge $500 to move a license from one machine to another.
+
Lint4J - Lock graph, DFA, and type analysis, many EJB checks
+
SolidSDD - Code
+duplication detection, nice graphical reporting. Free licensing available for Educational or OSS use.
+
+
+
Similar to CPD
+
+
Commercial
+
+
+
Simian - fast, works with Java, C#, C, CPP, COBOL, JSP, HTML
Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0.
+You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.
The Apex language support has been bumped to version 50 (Winter ‘21). All new language features are now properly
+parsed and processed. Especially the Safe Navigation Operator is now supported.
+See also Salesforce Winter ‘21 Release Notes
+
+
+
New Rules
+
+
+
The new Apex rule OperationWithLimitsInLoop (apex-performance)
+finds operations in loops that may hit governor limits such as DML operations, SOQL
+queries and more. The rule replaces the three rules “AvoidDmlStatementsInLoops”, “AvoidSoqlInLoops”,
+and “AvoidSoslInLoops”.
+
+
+
Renamed Rules
+
+
+
The Java rule DoNotCallSystemExit has been renamed to
+DoNotTerminateVM, since it checks for all the following calls:
+System.exit(int), Runtime.exit(int), Runtime.halt(int). All these calls terminate
+the Java VM, which is bad, if the VM runs an application server which many independent applications.
The AnyTokenizer is used for languages, that don’t have an own lexer/grammar based tokenizer.
+AnyTokenizer now handles string literals and end-of-line comments. Fortran, Perl and Ruby have
+been updated to use AnyTokenizer instead of their old custom tokenizer based on AbstractTokenizer.
+See #2758 for details.
+
+
AbstractTokenizer and the custom tokenizers of Fortran, Perl and Ruby are deprecated now.
net.sourceforge.pmd.lang.dart.antlr4.Dart2Lexer will be renamed to DartLexer and moved to package
+net.sourceforge.pmd.lang.dart.ast with PMD 7. All other classes in the old package will be removed.
Note: The Pattern Matching for instanceof, Records, and Sealed Classes are all preview language features of OpenJDK 15
+and are not enabled by default. In order to
+analyze a project with PMD that uses these language features, you’ll need to enable it via the environment
+variable PMD_JAVA_OPTS and select the new language version 15-preview:
Note: Support for Java 13 preview language features have been removed. The version “13-preview” is no longer available.
+
+
Changes in how tab characters are handled
+
+
In the past, tab characters in source files has been handled differently in different languages by PMD.
+For instance in Java, tab characters had a width of 8 columns, while C# used only 1 column. Visualforce instead
+used 4 columns.
+
+
This has been unified now so that tab characters are consistently now always 1 column wide.
+
+
This however might be a incompatible change, if you’re using the properties “BeginColumn” or “EndColumn”
+additionally to “BeginLine” and “EndLine” of a Token/AST node in order to highlight
+where a rule violation occurred in the source file. If you have logic there that deals with tab characters,
+you most likely can remove this logic now, since tab characters are now just “normal” characters
+in terms of string processing.
This PMD release ships a new version of the pmd-designer.
+For the changes, see PMD Designer Changelog.
+
+
New Rules
+
+
+
The new Java rule AvoidReassigningCatchVariables (java-bestpractices) finds
+cases where the variable of the caught exception is reassigned. This practice is surprising and prevents
+further evolution of the code like multi-catch.
+
+
+
Modified Rules
+
+
+
+
The Java rule CloseResource (java-errorprone) has a new property
+closeNotInFinally. With this property set to true the rule will also find calls to close a
+resource, which are not in a finally-block of a try-statement. If a resource is not closed within a
+finally block, it might not be closed at all in case of exceptions.
+
+
As this new detection would yield many new violations, it is disabled by default. It might be
+enabled in a later version of PMD.
+
+
+
+
Deprecated Rules
+
+
+
The Java rule DataflowAnomalyAnalysis (java-errorprone)
+is deprecated in favour of UnusedAssignment (java-bestpractices),
+which was introduced in PMD 6.26.0.
+
+
+
Fixed Issues
+
+
+
core
+
+
#724: [core] Avoid parsing rulesets multiple times
XML rule definition in rulesets: In PMD 7, the language attribute will be required on all rule
+elements that declare a new rule. Some base rule classes set the language implicitly in their
+constructor, and so this is not required in all cases for the rule to work. But this
+behavior will be discontinued in PMD 7, so missing language attributes are now
+reported as a forward compatibility warning.
The new Java rule UnusedAssignment (java-bestpractices) finds assignments
+to variables, that are never used and are useless. The new rule is supposed to entirely replace
+DataflowAnomalyAnalysis.
+
+
+
Modified rules
+
+
+
The Java rule ArrayIsStoredDirectly (java-bestpractices) now ignores
+by default private methods and constructors. You can restore the old behavior by setting the new property
+allowPrivate to “false”.
Up until now the PMD Scala module has been compiled against scala 2.13 only by default.
+However, this makes it impossible to use pmd as a library in scala projects,
+that use scala 2.12, e.g. in sbt plugins. Therefore PMD now provides cross compiled pmd-scala
+modules for both versions: scala 2.12 and scala 2.13.
+
+
The new modules have new maven artifactIds. The old artifactId net.sourceforge.pmd:pmd-scala:6.25.0
+is still available, but is deprecated from now on. It has been demoted to be just a delegation to the new
+pmd-scala_2.13 module and will be removed eventually.
The command line version of PMD continues to use scala 2.13.
+
+
New Rules
+
+
+
+
The new Java Rule UnnecessaryCast (java-codestyle)
+finds casts that are unnecessary while accessing collection elements.
+
+
+
The new Java Rule AvoidCalendarDateCreation (java-performance)
+finds usages of java.util.Calendar whose purpose is just to get the current date. This
+can be done in a more lightweight way.
+
+
+
The new Java Rule UseIOStreamsWithApacheCommonsFileItem (java-performance)
+finds usage of FileItem.get() and FileItem.getString(). These two methods are problematic since
+they load the whole uploaded file into memory.
+
+
+
+
Modified rules
+
+
+
+
The Java rule UseDiamondOperator (java-codestyle) now by default
+finds unnecessary usages of type parameters, which are nested, involve wildcards and are used
+within a ternary operator. These usages are usually only unnecessary with Java8 and later, when
+the type inference in Java has been improved.
+
+
In order to avoid false positives when checking Java7 only code, the rule has the new property
+java7Compatibility, which is disabled by default. Settings this to “true” retains
+the old rule behaviour.
+
+
+
+
Fixed Issues
+
+
+
apex-bestpractices
+
+
#2554: [apex] Exception applying rule UnusedLocalVariable on trigger
+
+
+
core
+
+
#971: [apex][plsql][java] Deprecate overly specific base rule classes
+
#2451: [core] Deprecate support for List attributes with XPath 2.0
+
#2599: [core] Fix XPath 2.0 Rule Chain Analyzer with Unions
+
#2483: [lang-test] Support cpd tests based on text comparison.
+For details see
+Testing your implementation
+in the developer documentation.
+
+
+
c#
+
+
#2551: [c#] CPD suppression with comments doesn’t work
#2573: [java] DefaultPackage: Allow package default JUnit 5 Test methods
+
+
+
java-design
+
+
#2563: [java] UselessOverridingMethod false negative with already public methods
+
#2570: [java] NPathComplexity should mention the expected NPath complexity
+
+
+
java-errorprone
+
+
#2544: [java] UseProperClassLoader can not detect the case with method call on intermediate variable
+
+
+
java-performance
+
+
#2591: [java] InefficientStringBuffering/AppendCharacterWithChar: Fix false negatives with concats in appends
+
#2600: [java] UseStringBufferForStringAppends: fix false negative with fields
+
+
+
scala
+
+
#2547: [scala] Add cross compilation for scala 2.12 and 2.13
+
+
+
+
+
API Changes
+
+
+
+
The maven module net.sourceforge.pmd:pmd-scala is deprecated. Use net.sourceforge.pmd:pmd-scala_2.13
+or net.sourceforge.pmd:pmd-scala_2.12 instead.
+
+
+
Rule implementation classes are internal API and should not be used by clients directly.
+The rules should only be referenced via their entry in the corresponding category ruleset
+(e.g. <rule ref="category/java/bestpractices.xml/AbstractClassWithoutAbstractMethod" />).
+
+
While we definitely won’t move or rename the rule classes in PMD 6.x, we might consider changes
+in PMD 7.0.0 and onwards.
+
+
+
+
Deprecated APIs
+
+
Internal API
+
+
Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0.
+You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.
Thanks to Fernando Cosso CPD can now find duplicates in XML files as well.
+This is useful to find duplicated sections in XML files.
+
+
Updated PMD Designer
+
+
This PMD release ships a new version of the pmd-designer.
+For the changes, see PMD Designer Changelog.
+
+
New Rules
+
+
+
+
The new Java Rule LiteralsFirstInComparisons (java-bestpractices)
+find String literals, that are used in comparisons and are not positioned first. Using the String literal
+as the receiver of e.g. equals helps to avoid NullPointerExceptions.
To facilitate healthy and constructive community behavior PMD adopts
+Contributor Convenant as its code of
+conduct.
+
+
Please note that this project is released with a Contributor Code of Conduct.
+By participating in this project you agree to abide by its terms.
+
+
You can find the code of conduct in the file code_of_conduct.md
+in our repository.
+
+
Performance improvements for XPath 2.0 rules
+
+
XPath rules written with XPath 2.0 now support conversion to a rulechain rule, which
+improves their performance. The rulechain is a mechanism that allows several rules
+to be executed in a single tree traversal. Conversion to the rulechain is possible if
+your XPath expression looks like //someNode/... | //someOtherNode/... | ..., that
+is, a union of one or more path expressions that start with //. Instead of traversing
+the whole tree once per path expression (and per rule), a single traversal executes all
+rules in your ruleset as needed.
+
+
This conversion is performed automatically and cannot be disabled. The conversion should
+not change the result of your rules, if it does, please report a bug at https://github.com/pmd/pmd/issues
+
+
Note that XPath 1.0 support, the default XPath version, is deprecated since PMD 6.22.0.
+We highly recommend that you upgrade your rules to XPath 2.0. Please refer to the migration guide.
+
+
Javascript improvements for ES6
+
+
PMD uses the Rhino library to parse Javascript.
+The default version has been set to ES6, so that some ECMAScript 2015 features are
+supported. E.g. let statements and for-of loops are now parsed. However Rhino does
+not support all features.
#384: [javascript] Trailing commas not detected on French default locale
+
+
+
+
+
API Changes
+
+
Deprecated APIs
+
+
Internal API
+
+
Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0.
+You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.
As part of the changes we’d like to do to AST classes for 7.0.0, we would like to
+hide some methods and constructors that rule writers should not have access to.
+The following usages are now deprecated in the Apex, Javascript, PL/SQL, Scala and Visualforce ASTs:
+
+
+
Manual instantiation of nodes. Constructors of node classes are deprecated and
+marked InternalApi. Nodes should only be obtained from the parser,
+which for rules, means that they never need to instantiate node themselves.
+Those constructors will be made package private with 7.0.0.
+
Subclassing of abstract node classes, or usage of their type. The base classes are internal API
+and will be hidden in version 7.0.0. You should not couple your code to them.
+
+
In the meantime you should use interfaces like VfNode or
+Node, or the other published interfaces in this package,
+to refer to nodes generically.
+
Concrete node classes will be made final with 7.0.0.
+
+
+
Setters found in any node class or interface. Rules should consider the AST immutable.
+We will make those setters package private with 7.0.0.
The implementation classes of TokenManager (eg VfTokenManager) are deprecated and should not be used outside of our implementation.
+This also affects CPD-only modules.
+
+
+
These deprecations are added to the following language modules in this release.
+Please look at the package documentation to find out the full list of deprecations.
Outside of these packages, these changes also concern the following TokenManager
+implementations, and their corresponding Parser if it exists (in the same package):
Note: The Text Blocks, Pattern Matching for instanceof and Records are all preview language features of OpenJDK 14
+and are not enabled by default. In order to
+analyze a project with PMD that uses these language features, you’ll need to enable it via the environment
+variable PMD_JAVA_OPTS and select the new language version 14-preview:
Note: Support for the extended break statement introduced in Java 12 as a preview language feature
+has been removed from PMD with this version. The version “12-preview” is no longer available.
+
+
Updated PMD Designer
+
+
This PMD release ships a new version of the pmd-designer.
+For the changes, see PMD Designer Changelog.
+
+
Apex Suppressions
+
+
In addition to suppressing violation with the @SuppressWarnings annotation, Apex now also supports
+the suppressions with a NOPMD comment. See Suppressing warnings.
+
+
Improved CPD support for C#
+
+
The C# tokenizer is now based on an antlr grammar instead of a manual written tokenizer. This
+should give more accurate results and especially fixes the problems with the using statement syntax
+(see #2139).
Note: As of PMD version 6.22.0, XPath versions 1.0 and the 1.0 compatibility mode are deprecated.
+XPath 2.0 is superior in many ways, for example for its support for type checking, sequence values,
+or quantified expressions. For a detailed but approachable review of the features of XPath 2.0 and above,
+see the Saxon documentation.
+
+
New Rules
+
+
+
+
The Rule CognitiveComplexity (apex-design) finds methods and classes
+that are highly complex and therefore difficult to read and more costly to maintain. In contrast
+to cyclomatic complexity, this rule uses “Cognitive Complexity”, which is a measure of how
+difficult it is for humans to read and understand a method.
+
+
+
The Rule TestMethodsMustBeInTestClasses (apex-errorprone) finds test methods
+that are not residing in a test class. The test methods should be moved to a proper test class.
+Support for tests inside functional classes was removed in Spring-13 (API Version 27.0), making classes
+that violate this rule fail compile-time. This rule is however useful when dealing with legacy code.
#2340: [plsql] Fixed parsing / as divide or execute
+
+
+
+
+
API Changes
+
+
Deprecated APIs
+
+
Internal API
+
+
Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0.
+You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.
Many APIs of net.sourceforge.pmd.lang.metrics, though most of them were internal and
+probably not used directly outside of PMD. Use MetricsUtil as
+a replacement for the language-specific façades too.
Several methods of ASTTryStatement, replacements with other names
+have been added. This includes the XPath attribute @Finally, replace it with a test for child::FinallyStatement.
+
Several methods named getGuardExpressionNode are replaced with getCondition. This affects the
+following nodes: WhileStatement, DoStatement, ForStatement, IfStatement, AssertStatement, ConditionalExpression.
+
ASTYieldStatement will not implement TypeNode
+anymore come 7.0.0. Test the type of the expression nested within it.
As part of the changes we’d like to do to AST classes for 7.0.0, we would like to
+hide some methods and constructors that rule writers should not have access to.
+The following usages are now deprecated in the JSP AST (with other languages to come):
+
+
+
Manual instantiation of nodes. Constructors of node classes are deprecated and
+marked InternalApi. Nodes should only be obtained from the parser,
+which for rules, means that they never need to instantiate node themselves.
+Those constructors will be made package private with 7.0.0.
+
Subclassing of abstract node classes, or usage of their type. The base classes are internal API
+and will be hidden in version 7.0.0. You should not couple your code to them.
+
+
In the meantime you should use interfaces like JspNode or
+Node, or the other published interfaces in this package,
+to refer to nodes generically.
+
Concrete node classes will be made final with 7.0.0.
+
+
+
Setters found in any node class or interface. Rules should consider the AST immutable.
+We will make those setters package private with 7.0.0.
As part of the changes we’d like to do to AST classes for 7.0.0, we would like to
+hide some methods and constructors that rule writers should not have access to.
+The following usages are now deprecated in the VM AST (with other languages to come):
+
+
+
Manual instantiation of nodes. Constructors of node classes are deprecated and
+marked InternalApi. Nodes should only be obtained from the parser,
+which for rules, means that they never need to instantiate node themselves.
+Those constructors will be made package private with 7.0.0.
+
Subclassing of abstract node classes, or usage of their type. The base classes are internal API
+and will be hidden in version 7.0.0. You should not couple your code to them.
+
+
In the meantime you should use interfaces like VmNode or
+Node, or the other published interfaces in this package,
+to refer to nodes generically.
+
Concrete node classes will be made final with 7.0.0.
+
+
+
Setters found in any node class or interface. Rules should consider the AST immutable.
+We will make those setters package private with 7.0.0.
Thanks to Anatoly Trosinenko PMD supports now a new language:
+Modelica is a language to model complex physical systems.
+Both PMD and CPD are supported and there are already 3 rules available.
+The PMD Designer supports syntax highlighting for Modelica.
+
+
While the language implementation is quite complete, Modelica support is considered experimental
+for now. This is to allow us to change the rule API (e.g. the AST classes) slightly and improve
+the implementation based on your feedback.
+
+
Simple XML dump of AST
+
+
We added a experimental feature to dump the AST of a source file into XML. The XML format
+is of course PMD specific and language dependent. That XML file can be used to execute
+(XPath) queries against without PMD. It can also be used as a textual visualization of the AST
+if you don’t want to use the Designer.
+
+
This feature is experimental and might change or even be removed in the future, if it is not
+useful. A short description how to use it is available under Creating XML dump of the AST.
+
+
Any feedback about it, especially about your use cases, is highly appreciated.
+
+
Updated Apex Support
+
+
+
The Apex language support has been bumped to version 48 (Spring ‘20). All new language features are now properly
+parsed and processed.
+
+
+
CPD XML format
+
+
The CPD XML output format has been enhanced to also report column information for found duplications
+in addition to the line information. This allows to display the exact tokens, that are considered
+duplicate.
+
+
If a CPD language doesn’t provide these exact information, then these additional attributes are omitted.
+
+
Each <file> element in the XML format now has 3 new attributes:
+
+
+
attribute endline
+
attribute column (if there is column information available)
+
attribute endcolumn (if there is column information available)
+
+
+
Modified Rules
+
+
+
+
The Java rule AvoidLiteralsInIfCondition (java-errorprone) has a new property
+ignoreExpressions. This property is set by default to true in order to maintain compatibility. If this
+property is set to false, then literals in more complex expressions are considered as well.
+
+
+
The Apex rule ApexCSRF (apex-errorprone) has been moved from category
+“Security” to “Error Prone”. The Apex runtime already prevents DML statements from being executed, but only
+at runtime. So, if you try to do this, you’ll get an error at runtime, hence this is error prone. See also
+the discussion on #2064.
+
+
+
The Java rule CommentRequired (java-documentation) has a new property
+classCommentRequirement. This replaces the now deprecated property headerCommentRequirement, since
+the name was misleading. (File) header comments are not checked, but class comments are.
+
+
+
+
Fixed Issues
+
+
+
apex
+
+
#2208: [apex] ASTFormalComment should implement ApexNode<T>
+
+
+
core
+
+
#1984: [java] Cyclomatic complexity is misreported (lack of clearing metrics cache)
+
#2006: [core] PMD should warn about multiple instances of the same rule in a ruleset
+
#2161: [core] ResourceLoader is deprecated and marked as internal but is exposed
#2214: [doc] Link broken in pmd documentation for writing Xpath rules
+
+
+
java
+
+
#2212: [java] JavaRuleViolation reports wrong class name
+
+
+
java-bestpractices
+
+
#2149: [java] JUnitAssertionsShouldIncludeMessage - False positive with assertEquals and JUnit5
+
+
+
java-codestyle
+
+
#2167: [java] UnnecessaryLocalBeforeReturn false positive with variable captured by method reference
+
+
+
java-documentation
+
+
#1683: [java] CommentRequired property names are inconsistent
+
+
+
java-errorprone
+
+
#2140: [java] AvoidLiteralsInIfCondition: false negative for expressions
+
#2196: [java] InvalidLogMessageFormat does not detect extra parameters when no placeholders
+
+
+
java-performance
+
+
#2141: [java] StringInstatiation: False negative with String-array access
+
+
+
plsql
+
+
#2008: [plsql] In StringLiteral using alternative quoting mechanism single quotes cause parsing errors
+
#2009: [plsql] Multiple DDL commands are skipped during parsing
+
+
+
+
+
API Changes
+
+
Deprecated APIs
+
+
Internal API
+
+
Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0.
+You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.
CharStream, JavaCharStream,
+SimpleCharStream: these are APIs used by our JavaCC
+implementations and that will be moved/refactored for PMD 7.0.0. They should not
+be used, extended or implemented directly.
+
All classes generated by JavaCC, eg JJTJavaParserState.
+This includes token classes, which will be replaced with a single implementation, and
+subclasses of ParseException, whose usages will be replaced
+by just that superclass.
+
+
+
For removal
+
+
+
pmd-core
+
+
Many methods on the Node interface
+and AbstractNode base class. See their javadoc for details.
Several methods of ASTTryStatement, replacements with other names
+have been added. This includes the XPath attribute @Finally, replace it with a test for child::FinallyStatement.
+
Several methods named getGuardExpressionNode are replaced with getCondition. This affects the
+following nodes: WhileStatement, DoStatement, ForStatement, IfStatement, AssertStatement, ConditionalExpression.
+
ASTYieldStatement will not implement TypeNode
+anymore come 7.0.0. Test the type of the expression nested within it.
The Java rules InvalidLogMessageFormat and MoreThanOneLogger
+(java-errorprone) now both support Log4j2. Note that the
+rule “InvalidSlf4jMessageFormat” has been renamed to “InvalidLogMessageFormat” to reflect the fact, that it now
+supports more than slf4j.
+
+
+
The Java rule LawOfDemeter (java-design) ignores now also Builders, that are
+not assigned to a local variable, but just directly used within a method call chain. The method, that creates
+the builder needs to end with “Builder”, e.g. newBuilder() or initBuilder() works. This change
+fixes a couple of false positives.
+
+
+
The Java rule DataflowAnomalyAnalysis (java-errorprone) doesn’t check for
+UR anomalies (undefined and then referenced) anymore. These checks were all false-positives, since actual
+UR occurrences would lead to compile errors.
+
+
+
The java rule DoNotUseThreads (java-multithreading) has been changed
+to not report usages of java.lang.Runnable anymore. Just using Runnable does not automatically create
+a new thread. While the check for Runnable has been removed, the rule now additionally checks for
+usages of Executors and ExecutorService. Both create new threads, which are not managed by a J2EE
+server.
This release of PMD brings support for Java 13. PMD can parse Switch Expressions
+with the new yield statement and resolve the type of such an expression.
Note: The Switch Expressions and Text Blocks are a preview language feature of OpenJDK 13
+and are not enabled by default. In order to
+analyze a project with PMD that uses these language features, you’ll need to enable it via the environment
+variable PMD_JAVA_OPTS and select the new language version 13-preview:
Note: Support for the extended break statement introduced in Java 12 as a preview language feature
+will be removed with the next PMD version 6.19.0.
+
+
Full support for Scala
+
+
Thanks to Chris Smith PMD now fully supports Scala. Now rules for analyzing Scala
+code can be developed in addition to the Copy-Paste-Detection (CPD) functionality. There are no rules yet, so
+contributions are welcome.
+
+
Additionally Scala support has been upgraded from 2.12.4 to 2.13.
+
+
New rule designer documentation
+
+
The documentation for the rule designer is now available on the main PMD documentation page:
+Rule Designer Reference. Check it out to learn
+about the usage and features of the rule designer.
+
+
New rules
+
+
+
+
The Java rule AvoidMessageDigestField (java-bestpractices) detects fields
+of the type java.security.MessageDigest. Using a message digest instance as a field would need to be
+synchronized, as it can easily be used by multiple threads. Without synchronization the calculated hash could
+be entirely wrong. Instead of declaring this as a field and synchronize access to use it from multiple threads,
+a new instance should be created when needed. This rule is also active when using java’s quickstart ruleset.
+
+
+
The Apex rule DebugsShouldUseLoggingLevel (apex-bestpractices) detects
+usages of System.debug() method calls that are used without specifying the log level. Having the log
+level specified provides a cleaner log, and improves readability of it.
+
+
+
+
Modified Rules
+
+
+
The Java rule CloseResource (java-errorprone) now ignores by default instances
+of java.util.stream.Stream. These streams are AutoCloseable, but most streams are backed by collections,
+arrays, or generating functions, which require no special resource management. However, there are some exceptions:
+The stream returned by Files::lines(Path) is backed by a actual file and needs to be closed. These instances
+won’t be found by default by the rule anymore.
+
+
+
Fixed Issues
+
+
+
all
+
+
#1465: [core] Stylesheet pmd-report.xslt fails to display filepath if ‘java’ in path
+
#1923: [core] Incremental analysis does not work with shortnames
+
#1983: [core] Avoid crashes with analysis cache when classpath references non-existing directories
Each renderer has now a new method Renderer#setUseShortNames which
+is used for implementing the “shortnames” CLI option. The method is automatically called by PMD, if this
+CLI option is in use. When rendering filenames to the report, the new helper method
+AbstractRenderer#determineFileName should be used. This will change
+the filename to a short name, if the CLI option “shortnames” is used.
+
+
Not adjusting custom renderers will make them render always the full file names and not honoring the
+CLI option “shortnames”.
The method AbstractPMDProcessor#filenameFrom has been
+deprecated. It was used to determine a “short name” of the file being analyzed, so that the report
+can use short names. However, this logic has been moved to the renderers.
+
The method Report#metrics and Report have
+been deprecated. They were leftovers from a previous deprecation round targeting
+StatisticalRule.
+
+
+
Internal APIs
+
+
Those APIs are not intended to be used by clients, and will be hidden or removed with PMD 7.0.0. You can identify them with the @InternalApi annotation. You’ll also get a deprecation warning.
This PMD release ships a new version of the pmd-designer.
+For the changes, see PMD Designer Changelog.
+It contains a new feature to edit test cases directly within the designer. Any feedback is highly appreciated.
+
+
Lua support
+
+
Thanks to the contribution from Maikel Steneker, and built on top of the ongoing efforts to fully support Antlr-based languages,
+PMD now has CPD support for Lua.
The Java rule CloseResource (java-errorprone) ignores now by default
+java.io.ByteArrayInputStream and java.io.CharArrayWriter. Such streams/writers do not need to be closed.
+
+
+
The Java rule MissingStaticMethodInNonInstantiatableClass (java-errorprone) has now
+the new property annotations.
+When one of the private constructors is annotated with one of the annotations, then the class is not considered
+non-instantiatable anymore and no violation will be reported. By default, Spring’s @Autowired and
+Java EE’s @Inject annotations are recognized.
+
+
+
+
Fixed Issues
+
+
+
core
+
+
#1913: [core] “-help” CLI option ends with status code != 0
+
+
+
doc
+
+
#1896: [doc] Error in changelog 6.16.0 due to not properly closed rule tag
+
#1898: [doc] Incorrect code example for DoubleBraceInitialization in documentation on website
+
#1906: [doc] Broken link for adding own CPD languages
+
#1909: [doc] Sample usage example refers to deprecated ruleset “basic.xml” instead of “quickstart.xml”
This PMD release ships a new version of the pmd-designer.
+For the changes, see PMD Designer Changelog.
+
+
PLSQL Grammar Updates
+
+
The grammar has been updated to support inline constraints in CREATE TABLE statements. Additionally, the
+CREATE TABLE statement may now be followed by physical properties and table properties. However, these
+properties are skipped over during parsing.
+
+
The CREATE VIEW statement now supports subquery views.
+
+
The EXTRACT function can now be parsed correctly. It is used to extract values from a specified
+datetime field. Also date time literals are parsed now correctly.
+
+
The CASE expression can now be properly used within SELECT statements.
+
+
Table aliases are now supported when specifying columns in INSERT INTO clauses.
+
+
New Rules
+
+
+
+
The Java rule DoubleBraceInitialization (java-bestpractices)
+detects non static initializers in anonymous classes also known as “double brace initialization”.
+This can be problematic, since a new class file is generated and object holds a strong reference
+to the surrounding class.
+
+
Note: This rule is also part of the Java quickstart ruleset (rulesets/java/quickstart.xml).
+
+
+
+
Modified Rules
+
+
+
+
The Java rule UnusedPrivateField (java-bestpractices) now ignores by
+default fields, that are annotated with the Lombok experimental annotation @Delegate. This can be
+customized with the property ignoredAnnotations.
+
+
+
The Java rule SingularField (java-design) now ignores by
+default fields, that are annotated with the Lombok experimental annotation @Delegate. This can be
+customized with the property ignoredAnnotations.
+
+
+
The Java rules UnsynchronizedStaticFormatter and
+UnsynchronizedStaticDateFormatter (java-multithreading)
+now prefer synchronized blocks by default. They will raise a violation, if the synchronization is implemented
+on the method level. To allow the old behavior, the new property allowMethodLevelSynchronization can
+be enabled.
+
+
+
The Java rule UseUtilityClass (java-design) has a new property ignoredAnnotations.
+By default, classes that are annotated with Lombok’s @UtilityClass are ignored now.
+
+
+
The Java rule NonStaticInitializer (java-errorprone) does not report
+non static initializers in anonymous classes anymore. For this use case, there is a new rule now:
+DoubleBraceInitialization (java-bestpractices).
+
+
+
The Java rule CommentDefaultAccessModifier (java-codestyle) was enhanced
+in the last version 6.15.0 to check also top-level types by default. This created many new violations.
+Missing the access modifier for top-level types is not so critical, since it only decreases the visibility
+of the type.
+
+
The default behaviour has been restored. If you want to enable the check for top-level types, you can
+use the new property checkTopLevelTypes.
+
+
+
The Java rule CloseResource (java-errorprone) now by default searches
+for any unclosed java.lang.AutoCloseable resource. This includes now the standard java.io.*Stream classes.
+Previously only SQL-related resources were considered by this rule. The types can still be configured
+via the types property. Some resources do not need to be closed (e.g. ByteArrayOutputStream). These
+exceptions can be configured via the new property allowedResourceTypes.
+In order to restore the old behaviour, just remove the type java.lang.AutoCloseable from the types
+property and keep the remaining SQL-related classes.
+
+
+
+
Deprecated Rules
+
+
+
The Java rule AvoidFinalLocalVariable (java-codestyle) has been deprecated
+and will be removed with PMD 7.0.0. The rule is controversial and also contradicts other existing
+rules such as LocalVariableCouldBeFinal. If the goal is to avoid defining
+constants in a scope smaller than the class, then the rule AvoidDuplicateLiterals
+should be used instead.
#1879: [pslql] ParseException when parsing LEFT JOIN
+
+
+
+
+
API Changes
+
+
Deprecated APIs
+
+
+
Reminder: Please don’t use members marked with the annotation InternalApi, as they will likely be removed, hidden, or otherwise intentionally broken with 7.0.0.
+
+
+
In ASTs
+
+
As part of the changes we’d like to do to AST classes for 7.0.0, we would like to
+hide some methods and constructors that rule writers should not have access to.
+The following usages are now deprecated in the Java AST (with other languages to come):
+
+
+
Manual instantiation of nodes. Constructors of node classes are deprecated and marked InternalApi. Nodes should only be obtained from the parser, which for rules, means that never need to instantiate node themselves. Those constructors will be made package private with 7.0.0.
+
Subclassing of abstract node classes, or usage of their type. Version 7.0.0 will bring a new set of abstractions that will be public API, but the base classes are and will stay internal. You should not couple your code to them.
+
+
In the meantime you should use interfaces like JavaNode or Node, or the other published interfaces in this package, to refer to nodes generically.
+
Concrete node classes will be made final with 7.0.0.
+
+
+
Setters found in any node class or interface. Rules should consider the AST immutable. We will make those setters package private with 7.0.0.
Thanks to the contributions from Maikel Steneker CPD for Matlab can
+now parse Matlab programs which use the question mark operator to specify access to
+class members:
CPD also understands now double quoted strings, which are supported since version R2017a of Matlab:
+
+
str = "This is a string"
+
+
+
Enhanced C++ support
+
+
CPD now supports digit separators in C++ (language module “cpp”). This is a C++14 feature.
+
+
Example: auto integer_literal = 1'000'000;
+
+
The single quotes can be used to add some structure to large numbers.
+
+
CPD also parses raw string literals now correctly (see #1784).
+
+
New Rules
+
+
+
+
The new Apex rule FieldNamingConventions (apex-codestyle) checks the naming
+conventions for field declarations. By default this rule uses the standard Apex naming convention (Camel case),
+but it can be configured through properties.
+
+
+
The new Apex rule FormalParameterNamingConventions (apex-codestyle) checks the
+naming conventions for formal parameters of methods. By default this rule uses the standard Apex naming
+convention (Camel case), but it can be configured through properties.
+
+
+
The new Apex rule LocalVariableNamingConventions (apex-codestyle) checks the
+naming conventions for local variable declarations. By default this rule uses the standard Apex naming
+convention (Camel case), but it can be configured through properties.
+
+
+
The new Apex rule PropertyNamingConventions (apex-codestyle) checks the naming
+conventions for property declarations. By default this rule uses the standard Apex naming convention (Camel case),
+but it can be configured through properties.
+
+
+
The new Java rule UseShortArrayInitializer (java-codestyle) searches for
+array initialization expressions, which can be written shorter.
+
+
+
+
Modified Rules
+
+
+
+
The Apex rule ClassNamingConventions (apex-codestyle) can now be configured
+using various properties for the specific kind of type declarations (e.g. class, interface, enum).
+As before, this rule uses by default the standard Apex naming convention (Pascal case).
+
+
+
The Apex rule MethodNamingConventions (apex-codestyle) can now be configured
+using various properties to differenciate e.g. static methods and test methods.
+As before, this rule uses by default the standard Apex naming convention (Camel case).
+
+
+
The Java rule FieldNamingConventions (java-codestyle) now by default ignores
+the field serialPersistentFields. Since this is a field which needs to have this special name, no
+field naming conventions can be applied here. It is excluded the same way like serialVersionUID via the
+property exclusions.
+
+
+
The Java rule CommentRequired (java-documentation) has a new property
+serialPersistentFieldsCommentRequired with the default value “Ignored”. This means that from now
+on comments for the field serialPersistentFields are not required anymore. You can change the property
+to restore the old behavior.
+
+
+
The Java rule ProperLogger (java-errorprone) has two new properties
+to configure the logger class (e.g. “org.slf4j.Logger”) and the logger name of the special case,
+when the logger is not static. The name of the static logger variable was already configurable.
+The new property “loggerClass” allows to use this rule for different logging frameworks.
+This rule covers all the cases of the now deprecated rule LoggerIsNotStaticFinal.
+
+
+
The Java rule CommentDefaultAccessModifier (java-codestyle) now reports also
+missing comments for top-level classes and annotations, that are package-private.
#1793: [java] CommentDefaultAccessModifier not working for classes
+
+
+
+
+
API Changes
+
+
Deprecated APIs
+
+
For removal
+
+
+
The DumpFacades in all languages, that could be used to transform a AST into a textual representation,
+will be removed with PMD 7. The rule designer is a better way to inspect nodes.
+
Thanks to the contribution from Maikel Steneker, and built on top of the ongoing efforts to fully support Antlr-based languages,
+PMD now has CPD support for Dart.
This PMD release ships a new version of the pmd-designer.
+For the changes, see PMD Designer Changelog.
+
+
Modified Rules
+
+
+
+
The Java rule AssignmentToNonFinalStatic (java-errorprone) will now report on each
+assignment made within a constructor rather than on the field declaration. This makes it easier for developers to
+find the offending statements.
+
+
+
The Java rule NoPackage (java-codestyle) will now report additionally enums
+and annotations that do not have a package declaration.
+
+
+
+
Fixed Issues
+
+
+
all
+
+
#1515: [core] Module pmd-lang-test is missing javadoc artifact
+
#1788: [cpd] [core] Use better ClassLoader for ServiceLoader in LanguageFactory
+
#1794: [core] Ruleset Compatibility fails with excluding rules
+
+
+
go
+
+
#1751: [go] Parsing errors encountered with escaped backslash
This release of PMD brings support for Java 12. PMD can parse the new Switch Expressions
+and resolve the type of such an expression.
+
+
Note: The Switch Expressions are a preview language feature of OpenJDK 12 and are not enabled by default. In order to
+analyze a project with PMD that uses these language features, you’ll need to enable it via the new environment
+variable PMD_JAVA_OPTS:
PMD provides now a quickstart ruleset for Salesforce.com Apex, which you can use as a base ruleset to
+get your custom ruleset started. You can reference it with rulesets/apex/quickstart.xml.
+You are strongly encouraged to create your own ruleset
+though.
+
+
The quickstart ruleset has the intention, to be useful out-of-the-box for many projects. Therefore it
+references only rules, that are most likely to apply everywhere.
+
+
Any feedback would be greatly appreciated.
+
+
PMD Designer
+
+
The rule designer’s codebase has been moved out of the main repository and
+will be developed at pmd/pmd-designer
+from now on. The maven coordinates will stay the same for the time being.
+The designer will still be shipped with PMD’s binaries.
+
+
Improved Apex Support
+
+
+
Many AST nodes now expose more information which makes it easier to write XPath-based rules for Apex. Here are
+some examples:
+
AnnotationParameter[@Name='RestResource'][@Value='/myurl'] gives access to
+annotation parameters.
+
CatchBlockStatement[@ExceptionType='Exception'][@VariableName='e'] finds catch
+block for specific exception types.
+
Field[@Type='String'] find all String fields, Field[string-length(@Name) < 5]
+finds all fields with short names and Field[@Value='a'] find alls fields, that are
+initialized with a specific value.
+
LiteralExpression[@String = true()] finds all String literals. There are attributes
+for each type: @Boolean, @Integer, @Double, @Long, @Decimal, @Null.
+
Method[@Constructor = true()] selects all constructors. Method[@ReturnType = 'String']
+selects all methods that return a String.
+
The ModifierNode node has a couple of attributes to check for the existence of specific
+modifiers: @Test, @TestOrTestSetup, @WithSharing, @WithoutSharing, @InheritedSharing,
+@WebService, @Global, @Override.
+
Many nodes now expose their type. E.g. with Parameter[@Type='Integer'] you can find all
+method parameters of type Integer. The same attribute Type exists as well for:
+NewObjectExpression, Property, VariableDeclaration.
+
VariableExpression[@Image='i'] finds all variable usages of the variable “i”.
+
+
+
+
+
New Rules
+
+
+
+
The new Java rule AvoidUncheckedExceptionsInSignatures (java-design) finds methods or constructors
+that declare unchecked exceptions in their throws clause. This forces the caller to handle the exception,
+even though it is a runtime exception.
+
+
+
The new Java rule DetachedTestCase (java-errorprone) searches for public
+methods in test classes, which are not annotated with @Test. These methods might be test cases where
+the annotation has been forgotten. Because of that those test cases are never executed.
+
+
+
The new Java rule WhileLoopWithLiteralBoolean (java-bestpractices) finds
+Do-While-Loops and While-Loops that can be simplified since they use simply true or false as their
+loop condition.
+
+
+
The new Apex rule ApexAssertionsShouldIncludeMessage (apex-bestpractices)
+searches for assertions in unit tests and checks, whether they use a message argument.
#1735: [plsql] False-negatives for TO_DATE_TO_CHAR, TO_DATEWithoutDateFormat, TO_TIMESTAMPWithoutDateFormat
+
+
+
+
+
API Changes
+
+
Command Line Interface
+
+
The start scripts run.sh, pmd.bat and cpd.bat support the new environment variable PMD_JAVA_OPTS.
+This can be used to set arbitrary JVM options for running PMD, such as memory settings (e.g. PMD_JAVA_OPTS=-Xmx512m)
+or enable preview language features (e.g. PMD_JAVA_OPTS=--enable-preview).
+
+
The previously available variables such as OPTS or HEAPSIZE are deprecated and will be removed with PMD 7.0.0.
+
+
Deprecated API
+
+
+
+
CodeClimateRule is deprecated in 7.0.0 because it was unused for 2 years and
+created an unwanted dependency.
+Properties “cc_categories”, “cc_remediation_points_multiplier”, “cc_block_highlighting” will also be removed.
+See #1702 for more.
+
+
+
The Apex ruleset rulesets/apex/ruleset.xml has been deprecated and will be removed in 7.0.0. Please use the new
+quickstart ruleset rulesets/apex/quickstart.xml instead.
+
+
+
+
External Contributions
+
+
+
#1694: [apex] New rules for test method and assert statements - triandicAnt
PMD’s logo was great for a long time. But now we want to take the opportunity with the next major release to change
+our logo in order to use a more “politically correct” one.
ITBA students Matías Fraga,
+Tomi De Lucca and Lucas Soncini
+keep working on bringing full Antlr support to PMD. For this release, they have implemented
+token filtering in an equivalent way as we did for JavaCC languages, adding support for CPD
+suppressions through CPD-OFF and CPD-ON comments for all Antlr-based languages.
+
+
This means, you can now ignore arbitrary blocks of code on:
+
+
Go
+
Kotlin
+
Swift
+
+
+
Simply start the suppression with any comment (single or multiline) containing CPD-OFF,
+and resume again with a comment containing CPD-ON.
In this release, many more parser bugs in our PL/SQL support have been fixed. This adds more complete
+support for UPDATE statements and subqueries and hierarchical queries in SELECT statements.
+
Support for analytic functions such as LISTAGG has been added.
+
Conditions in WHERE clauses support now REGEX_LIKE and multiset conditions.
+
+
+
New Rules
+
+
+
The new Java rule UseTryWithResources (java-bestpractices) searches
+for try-blocks, that could be changed to a try-with-resources statement. This statement ensures that
+each resource is closed at the end of the statement and is available since Java 7.
+
+
+
Modified Rules
+
+
+
The Apex rule MethodNamingConventions (apex-codestyle) has a new
+property skipTestMethodUnderscores, which is by default disabled. The new property allows for ignoring
+all test methods, either using the testMethod modifier or simply annotating them @isTest.
+
+
+
Fixed Issues
+
+
+
all
+
+
#1462: [core] Failed build on Windows with source zip archive
+
#1559: [core] CPD: Lexical error in file (no file name provided)
+
#1671: [doc] Wrong escaping in suppressing warnings for nopmd-comment
+
#1693: [ui] Improved error reporting for the designer
+
+
+
java-bestpractices
+
+
#808: [java] AccessorMethodGeneration false positives with compile time constants
+
#1405: [java] New Rule: UseTryWithResources - Replace close and IOUtils.closeQuietly with try-with-resources
+
#1555: [java] UnusedImports false positive for method parameter type in @see Javadoc
+
+
+
java-codestyle
+
+
#1543: [java] LinguisticNaming should ignore overriden methods
+
#1547: [java] AtLeastOneConstructorRule: false-positive with lombok.AllArgsConstructor
+
#1624: [java] UseDiamondOperator false positive with var initializer
+
+
+
java-design
+
+
#1641: [java] False-positive with Lombok and inner classes
+
+
+
java-errorprone
+
+
#780: [java] BeanMembersShouldSerializeRule does not recognize lombok accessors
+
+
+
java-multithreading
+
+
#1633: [java] UnsynchronizedStaticFormatter reports commons lang FastDateFormat
+
+
+
java-performance
+
+
#1632: [java] ConsecutiveLiteralAppends false positive over catch
The Apex language support has been bumped to version 45 (Spring ‘19). All new language features are now properly
+parsed and processed.
+
Many nodes now expose more informations, such as the operator for BooleanExpressions. This makes these operators
+consumable by XPath rules, e.g. //BooleanExpression[@Operator='&&'].
+
+
+
PL/SQL Grammar improvements
+
+
+
In this release, many parser bugs in our PL/SQL support have been fixed. This adds e.g. support for
+table collection expressions (SELECT * FROM TABLE(expr)).
+
Support for parsing insert statements has been added.
+
More improvements are planned for the next release of PMD.
+
+
+
New Rules
+
+
+
+
The new Java rule UnsynchronizedStaticFormatter (java-multithreading) detects
+unsynchronized usages of static java.text.Format instances. This rule is a more generic replacement of the
+rule UnsynchronizedStaticDateFormatter which focused just on DateFormat.
+
+
+
The new Java rule ForLoopVariableCount (java-bestpractices) checks for
+the number of control variables in a for-loop. Having a lot of control variables makes it harder to understand
+what the loop does. The maximum allowed number of variables is by default 1 and can be configured by a
+property.
+
+
+
The new Java rule AvoidReassigningLoopVariables (java-bestpractices) searches
+for loop variables that are reassigned. Changing the loop variables additionally to the loop itself can lead to
+hard-to-find bugs.
+
+
+
The new Java rule UseDiamondOperator (java-codestyle) looks for constructor
+calls with explicit type parameters. Since Java 1.7, these type parameters are not necessary anymore, as they
+can be inferred now.
+
+
+
+
Modified Rules
+
+
+
The Java rule LocalVariableCouldBeFinal (java-codestyle) has a new
+property ignoreForEachDecl, which is by default disabled. The new property allows for ignoring
+non-final loop variables in a for-each statement.
Thanks to Maikel Steneker, CPD now supports Kotlin.
+This means, you can use CPD to find duplicated code in your Kotlin projects.
+
+
New Rules
+
+
+
The new Java rule UseUnderscoresInNumericLiterals (java-codestyle)
+verifies that numeric literals over a given length (4 chars by default, but configurable) are using
+underscores every 3 digits for readability. The rule only applies to Java 7+ codebases.
The property exceptionfile of the rule AvoidDuplicateLiterals (java-errorprone)
+has been deprecated and will be removed with 7.0.0. Please use exceptionList instead.
+
+
+
+
Fixed Issues
+
+
all
+
+
#1284: [doc] Keep record of every currently deprecated API
#1151: [java] ImmutableField false positive with multiple constructors
+
#1483: [java] Cyclo metric should count conditions of for statements correctly
+
+
+
java-errorprone
+
+
#1512: [java] InvalidSlf4jMessageFormatRule causes NPE in lambda and static blocks
+
+
+
plsql
+
+
#1454: [plsql] ParseException for IF/CASE statement with >=, <=, !=
+
+
+
+
+
API Changes
+
+
Properties framework
+
+
The properties framework is about to get a lifting, and for that reason, we need to deprecate a lot of APIs
+to remove them in 7.0.0. The proposed changes to the API are described on the wiki
+
+
Changes to how you define properties
+
+
+
+
Construction of property descriptors has been possible through builders since 6.0.0. The 7.0.0 API will only allow
+construction through builders. The builder hierarchy, currently found in the package net.sourceforge.pmd.properties.builders,
+is being replaced by the simpler PropertyBuilder. Their APIs enjoy a high degree of source compatibility.
+
+
+
Concrete property classes like IntegerProperty and StringMultiProperty will gradually
+all be deprecated until 7.0.0. Their usages should be replaced by direct usage of the PropertyDescriptor
+interface, e.g. PropertyDescriptor<Integer> or PropertyDescriptor<List<String>>.
+
+
+
Instead of spreading properties across countless classes, the utility class PropertyFactory will become
+from 7.0.0 on the only provider for property descriptor builders. Each current property type will be replaced
+by a corresponding method on PropertyFactory:
MethodProperty, FileProperty, TypeProperty and their multi-valued counterparts
+are discontinued for lack of a use-case, and have no planned replacement in 7.0.0 for now.
+
+
+
+
+
+
Here’s an example:
+
// Before 7.0.0, these are equivalent:
+IntegerPropertymyProperty=newIntegerProperty("score","Top score value",1,100,40,3.0f);
+IntegerPropertymyProperty=IntegerProperty.named("score").desc("Top score value").range(1,100).defaultValue(40).uiOrder(3.0f);
+
+// They both map to the following in 7.0.0
+PropertyDescriptor<Integer>myProperty=PropertyFactory.intProperty("score").desc("Top score value").require(inRange(1,100)).defaultValue(40);
+
+
+
You’re highly encouraged to migrate to using this new API as soon as possible, to ease your migration to 7.0.0.
preferredRowCount is deprecated with no intended replacement. It was never implemented, and does not belong
+in this interface. The methods uiOrder and compareTo(PropertyDescriptor) are deprecated for the
+same reason. These methods mix presentation logic with business logic and are not necessary for PropertyDescriptors to work.
+PropertyDescriptor will not extend Comparable<PropertyDescriptor> anymore come 7.0.0.
+
The method propertyErrorFor is deprecated and will be removed with no intended
+replacement. It’s really just a shortcut for prop.errorFor(rule.getProperty(prop)).
+
T valueFrom(String) and String asDelimitedString(T) are deprecated and will be removed. These were
+used to serialize and deserialize properties to/from a string, but 7.0.0 will introduce a more flexible
+XML syntax which will make them obsolete.
+
isMultiValue and type are deprecated and won’t be replaced. The new XML syntax will remove the need
+for a divide between multi- and single-value properties, and will allow arbitrary types to be represented.
+Since arbitrary types may be represented, type will become obsolete as it can’t represent generic types,
+which will nevertheless be representable with the XML syntax. It was only used for documentation, but a
+new way to document these properties exhaustively will be added with 7.0.0.
+
errorFor is deprecated as its return type will be changed to Optional<String> with the shift to Java 8.
+
+
+
Deprecated APIs
+
+
For internalization
+
+
+
+
The implementation of the adapters for the XPath engines Saxon and Jaxen (package net.sourceforge.pmd.lang.ast.xpath)
+are now deprecated. They’ll be moved to an internal package come 7.0.0. Only Attribute remains public API.
The method getVariableName on those two nodes will be removed, too.
+
+
+
+
All these are deprecated because those nodes may declare several variables at once, possibly
+with different types (and obviously with different names). They both implement Iterator<ASTVariableDeclaratorId>
+though, so you should iterate on each declared variable. See #910.
+
+
+
Visitor decorators are now deprecated and will be removed in PMD 7.0.0. They were originally a way to write
+composable visitors, used in the metrics framework, but they didn’t prove cost-effective.
The LanguageModules of several languages, that only support CPD execution, have been deprecated. These languages
+are not fully supported by PMD, so having a language module does not make sense. The functionality of CPD is
+not affected by this change. The following classes have been deprecated and will be removed with PMD 7.0.0:
Optional AST processing stages like symbol table, type resolution or data-flow analysis will be reified
+in 7.0.0 to factorise common logic and make them extensible. Further explanations about this change can be
+found on #1426. Consequently, the following APIs are deprecated for
+removal:
Thanks to the work of ITBA students Matías Fraga,
+Tomi De Lucca and Lucas Soncini,
+Golang is now backed by a proper Antlr Grammar. This means CPD is now better at detecting duplicates,
+as comments are recognized as such and ignored.
+
+
New Rules
+
+
+
The new PLSQL rule CodeFormat (plsql-codestyle) verifies that
+PLSQL code is properly formatted. It checks e.g. for correct indentation in select statements and verifies
+that each parameter is defined on a separate line.
+
+
+
Fixed Issues
+
+
+
all
+
+
#649: [core] Exclude specific files from command line
+
#1272: [core] Could not find or load main class when using symlinked run.sh
+
#1377: [core] LanguageRegistry uses default class loader when invoking ServiceLocator
#1412: [doc] Broken link to adding new cpd language documentation
+
+
+
apex
+
+
#1396: [apex] ClassCastException caused by Javadoc
+
+
+
java
+
+
#1330: [java] PMD crashes with java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/xml/ws/Service
+
+
+
java-bestpractices
+
+
#1202: [java] GuardLogStatement: “There is log block not surrounded by if” doesn’t sound right
+
#1209: [java] UnusedImports false positive for static import with package-private method usage
+
#1343: [java] Update CommentDefaultAccessModifierRule to extend AbstractIgnoredAnnotationRule
#1369: [java] Processing error (ClassCastException) if a TYPE_USE annotation is used on a base class in the “extends” clause
+
+
+
jsp
+
+
#1402: [jsp] JspTokenManager has a problem about jsp scriptlet
+
+
+
documentation
+
+
#1349: [doc] Provide some explanation for WHY duplicate code is bad, like mutations
+
+
+
+
+
API Changes
+
+
+
PMD has a new CLI option -ignorelist. With that, you can provide a file containing a comma-delimit list of files,
+that should be excluded during analysis. The ignorelist is applied after the files have been selected
+via -dir or -filelist, which means, if the file is in both lists, then it will be ignored.
+Note: there is no corresponding option for the Ant task, since the feature is already available via
+Ant’s FileSet include/exclude filters.
Until now, all released public members and types were implicitly considered part
+of PMD’s public API, including inheritance-specific members (protected members, abstract methods).
+We have maintained those APIs with the goal to preserve full binary compatibility between minor releases,
+only breaking those APIs infrequently, for major releases.
+
+
In order to allow PMD to move forward at a faster pace, this implicit contract will
+be invalidated with PMD 7.0.0. We now introduce more fine-grained distinctions between
+the type of compatibility support we guarantee for our libraries, and ways to make
+them explicit to clients of PMD.
+
+
.internal packages and @InternalApi annotation
+
+
Internal API is meant for use only by the main PMD codebase. Internal types and methods
+may be modified in any way, or even removed, at any time.
+
+
Any API in a package that contains an .internal segment is considered internal.
+The @InternalApi annotation will be used for APIs that have to live outside of
+these packages, e.g. methods of a public type that shouldn’t be used outside of PMD (again,
+these can be removed anytime).
+
+
@ReservedSubclassing
+
+
Types marked with the @ReservedSubclassing annotation are only meant to be subclassed
+by classes within PMD. As such, we may add new abstract methods, or remove protected methods,
+at any time. All published public members remain supported. The annotation is not inherited, which
+means a reserved interface doesn’t prevent its implementors to be subclassed.
+
+
@Experimental
+
+
APIs marked with the @Experimental annotation at the class or method level are subject to change.
+They can be modified in any way, or even removed, at any time. You should not use or rely
+ on them in any production code. They are purely to allow broad testing and feedback.
+
+
@Deprecated
+
+
APIs marked with the @Deprecated annotation at the class or method level will remain supported
+until the next major release but it is recommended to stop using them.
+
+
The transition
+
+
All currently supported APIs will remain so until 7.0.0. All APIs that are to be moved to
+.internal packages or hidden will be tagged @InternalApi before that major release, and
+the breaking API changes will be performed in 7.0.0.
+
+
Quickstart Ruleset
+
+
PMD 6.8.0 provides a first quickstart ruleset for Java, which you can use as a base ruleset to get your
+custom ruleset started. You can reference it with rulesets/java/quickstart.xml.
+You are strongly encouraged to create your own ruleset
+though.
+
+
The quickstart ruleset has the intention, to be useful out-of-the-box for many projects. Therefore it
+references only rules, that are most likely to apply everywhere.
+
+
Any feedback would be greatly appreciated.
+
+
New Rules
+
+
+
The new Apex rule ApexDoc (apex-documentation)
+enforces the inclusion of ApexDoc on classes, interfaces, properties and methods; as well as some
+sanity rules for such docs (no missing parameters, parameters’ order, and return value). By default,
+method overrides and test classes are allowed to not include ApexDoc.
+
+
+
Modified Rules
+
+
+
The rule MissingSerialVersionUID (java-errorprone) has been modified
+in order to recognize also missing serialVersionUID fields in abstract classes, if they are serializable.
+Each individual class in the inheritance chain needs an own serialVersionUID field. See also Should an abstract class have a serialVersionUID.
+This change might lead to additional violations in existing code bases.
+
+
+
PLSQL
+
+
The grammar for PLSQL has been revamped in order to fully parse SELECT INTO, UPDATE, and DELETE
+statements. Previously such statements have been simply skipped ahead, now PMD is parsing them, giving access
+to the individual parts of a SELECT-statement, such as the Where-Clause. This might produce new parsing errors
+where PMD previously could successfully parse PLSQL code. If this happens, please report a new issue to get this problem fixed.
+
+
Fixed Issues
+
+
+
apex-bestpractices
+
+
#1348: [apex] AvoidGlobalModifierRule gives warning even when its a webservice - false positive
+
+
+
java-codestyle
+
+
#1329: [java] FieldNamingConventions: false positive in serializable class with serialVersionUID
+
#1334: [java] LinguisticNaming should support AtomicBooleans
+
+
+
java-errorprone
+
+
#1350: [java] MissingSerialVersionUID false-positive on interfaces
+
#1352: [java] MissingSerialVersionUID false-negative with abstract classes
+
+
+
java-performance
+
+
#1325: [java] False positive in ConsecutiveLiteralAppends
A couple of methods and fields in net.sourceforge.pmd.properties.AbstractPropertySource have been
+deprecated, as they are replaced by already existing functionality or expose internal implementation
+details: propertyDescriptors, propertyValuesByDescriptor,
+copyPropertyDescriptors(), copyPropertyValues(), ignoredProperties(), usesDefaultValues(),
+useDefaultValueFor().
+
+
+
Some methods in net.sourceforge.pmd.properties.PropertySource have been deprecated as well:
+usesDefaultValues(), useDefaultValueFor(), ignoredProperties().
+
+
+
The class net.sourceforge.pmd.lang.rule.AbstractDelegateRule has been deprecated and will
+be removed with PMD 7.0.0. It is internally only in use by RuleReference.
+
+
+
The default constructor of net.sourceforge.pmd.lang.rule.RuleReference has been deprecated
+and will be removed with PMD 7.0.0. RuleReferences should only be created by providing a Rule and
+a RuleSetReference. Furthermore the following methods are deprecated: setRuleReference(),
+hasOverriddenProperty(), usesDefaultValues(), useDefaultValueFor().
+
+
+
+
External Contributions
+
+
+
#1309: [core] [CPD] Decouple Antlr Tokenizer implementation from any CPD language supported with Antlr - Matías Fraga
+
#1314: [apex] Add validation of ApexDoc comments - Jeff Hube
The Java rule OneDeclarationPerLine (java-bestpractices) has been revamped to
+consider not only local variable declarations, but field declarations too.
+
+
+
New Rules
+
+
+
+
The new Java rule LinguisticNaming (java-codestyle)
+detects cases, when a method name indicates it returns a boolean (such as isSmall()) but it doesn’t.
+Besides method names, the rule also checks field and variable names. It also checks, that getters return
+something but setters won’t. The rule has several properties with which it can be customized.
+
+
+
The new PL/SQL rule ForLoopNaming (plsql-codestyle)
+enforces a naming convention for “for loops”. Both “cursor for loops” and “index for loops” are covered.
+The rule can be customized via patterns. By default, short variable names are reported.
+
+
+
The new Java rule FieldNamingConventions (java-codestyle)
+detects field names that don’t comply to a given convention. It defaults to standard Java convention of using camelCase,
+but can be configured with ease for e.g. constants or static fields.
+
+
+
The new Apex rule OneDeclarationPerLine (apex-codestyle) enforces declaring a
+single field / variable per line; or per statement if the strictMode property is set.
+It’s an Apex equivalent of the already existing Java rule of the same name.
All classes in the package net.sourceforge.pmd.lang.dfa.report have been deprecated and will be removed
+with PMD 7.0.0. This includes the class net.sourceforge.pmd.lang.dfa.report.ReportTree. The reason is,
+that this class is very specific to Java and not suitable for other languages. It has only been used for
+YAHTMLRenderer, which has been rewritten to work without these classes.
+
+
+
The nodes RUNSIGNEDSHIFT and RSIGNEDSHIFT are deprecated and will be removed from the AST with PMD 7.0.0.
+These represented the operator of ShiftExpression in two cases out of three, but they’re not needed and
+make ShiftExpression inconsistent. The operator of a ShiftExpression is now accessible through
+ShiftExpression#getOperator.
+
+
+
+
External Contributions
+
+
+
#109: [java] Add two linguistics rules under naming - Arda Aslan
+
#1254: [ci] [GSoC] Integrating the danger and pmdtester to travis CI - BBG
+
#1258: [java] Use typeof in MissingSerialVersionUID - krichter722
+
#1264: [cpp] Fix NullPointerException in CPPTokenizer:99 - Rafael Cortês
+
#1277: [jsp] #1276 add support for jspf and tag extensions - Jordi Llach
+
#1275: [jsp] Issue #1274 - Support EL in tag attributes - Jordi Llach
+
#1278: [ci] [GSoC] Use pmdtester 1.0.0.pre.beta3 - BBG
+
#1289: [java] UselessParentheses: Fix false positive with assignments - cobratbq
+
#1290: [docs] [GSoC] Create the documentation about pmdtester - BBG
+
#1256: [java] #940 Avoid JUnit 4 false positives for JUnit 5 tests - Alex Shesterov
+
#1315: [apex] Add OneDeclarationPerStatement rule - Jeff Hube
The new Java rule LocalVariableNamingConventions
+(java-codestyle) detects local variable names that don’t comply to a given convention. It defaults to standard
+Java convention of using camelCase, but can be configured. Special cases can be configured for final variables
+and caught exceptions’ names.
+
+
+
The new Java rule FormalParameterNamingConventions
+(java-codestyle) detects formal parameter names that don’t comply to a given convention. It defaults to
+standard Java convention of using camelCase, but can be configured. Special cases can be configured for final
+parameters and lambda parameters (considering whether they are explicitly typed or not).
#1047: [plsql] ParseException when parsing EXECUTE IMMEDIATE
+
+
+
ui
+
+
#1233: [ui] XPath autocomplete arrows on first and last items
+
+
+
+
+
API Changes
+
+
+
The findDescendantsOfType methods in net.sourceforge.pmd.lang.ast.AbstractNode no longer search for
+exact type matches, but will match subclasses, too. That means, it’s now possible to look for abstract node
+types such as AbstractJavaTypeNode and not only for it’s concrete subtypes.
The new Apex rule AvoidNonExistentAnnotations (apex-errorprone)
+detects usages non-officially supported annotations. Apex supported non existent annotations for legacy reasons.
+In the future, use of such non-existent annotations could result in broken Apex code that will not compile.
+A full list of supported annotations can be found here
+
+
+
Modified Rules
+
+
+
The Java rule UnnecessaryModifier (java-codestyle)
+now detects enum constrcutors with explicit private modifier. The rule now produces better error messages
+letting you know exactly which modifiers are redundant at each declaration.
+
+
+
Fixed Issues
+
+
all
+
+
#1119: [doc] Make the landing page of the documentation website more useful
+
#1168: [core] xml renderer schema definitions (#538) break included xslt files
+
#1173: [core] Some characters in CPD are not shown correctly.
The utility class net.sourceforge.pmd.lang.java.ast.CommentUtil has been deprecated and will be removed
+with PMD 7.0.0. Its methods have been intended to parse javadoc tags. A more useful solution will be added
+around the AST node FormalComment, which contains as children JavadocElement nodes, which in
+turn provide access to the JavadocTag.
+
+
All comment AST nodes (FormalComment, MultiLineComment, SingleLineComment) have a new method
+getFilteredComment() which provide access to the comment text without the leading /* markers.
+
+
+
The method AbstractCommentRule.tagsIndicesIn() has been deprecated and will be removed with
+PMD 7.0.0. It is not very useful, since it doesn’t extract the information
+in a useful way. You would still need check, which tags have been found, and with which
+data they might be accompanied.
+
+
+
+
External Contributions
+
+
+
#836: [apex] Add a rule to prevent use of non-existent annotations - anand13s
+
#1159: [ui] Allow to setup the auxclasspath in the designer - Akshat Bahety
PMD is now able to understand local-variable type inference as introduced by Java 10.
+Simple type resolution features are available, e.g. the type of the variable s is inferred
+correctly as String:
+
+
var s = "Java 10";
+
+
+
XPath Type Resolution Functions
+
+
For some time now PMD has supported Type Resolution, and exposed this functionality to XPath rules for the Java language
+with the typeof function. This function however had a number of shortcomings:
+
+
+
It would take a first arg with the name to match if types couldn’t be resolved. In all cases this was @Image
+but was still required.
+
It required 2 separate arguments for the Fully Qualified Class Name and the simple name of the class against
+which to test.
+
If only the Fully Qualified Class Name was provided, no simple name check was performed (not documented,
+but abused on some rules to “fix” some false positives).
+
+
+
In this release we are deprecating typeof in favor of a simpler typeIs function, which behaves exactly as the
+old typeof when given all 3 arguments.
+
+
typeIs receives a single parameter, which is the fully qualified name of the class to test against.
With this change, we also allow to check against array types by just appending [] to the fully qualified class name.
+These can be repeated for arrays of arrays (e.g. byte[][] or java.lang.String[]).
+
+
Additionally, we introduce the companion function typeIsExactly, that receives the same parameters as typeIs,
+but checks for exact type matches, without considering the type hierarchy. That is, the test
+typeIsExactly('junit.framework.TestCase') will match only if the context node is an instance of TestCase, but
+not if it’s an instance of a subclass of TestCase. Be aware then, that using that method with abstract types will
+never match.
+
+
New Rules
+
+
+
+
The new Java rule HardCodedCryptoKey (java-security)
+detects hard coded keys used for encryption. It is recommended to store keys outside of the source code.
+
+
+
The new Java rule IdenticalCatchBranches (java-codestyle)
+finds catch blocks,
+that catch different exception but perform the same exception handling and thus can be collapsed into a
+multi-catch try statement.
+
+
+
+
Modified Rules
+
+
+
+
The Java rule JUnit4TestShouldUseTestAnnotation (java-bestpractices)
+has a new parameter “testClassPattern”. It is used to distinguish test classes from other classes and
+avoid false positives. By default, any class, that has “Test” in its name, is considered a test class.
+
+
+
The Java rule CommentDefaultAccessModifier (java-codestyle)
+allows now by default the comment “/* package */ in addition to “/* default */. This behavior can
+still be adjusted by setting the property regex.
+
+
+
+
Fixed Issues
+
+
+
all
+
+
#1018: [java] Performance degradation of 250% between 6.1.0 and 6.2.0
+
#1145: [core] JCommander’s help text for option -min is wrong
+
+
+
java
+
+
#672: [java] Support exact type matches for type resolution from XPath
#1131: [java] java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/faces/application/FacesMessage$Severity
+
+
+
java-bestpractices
+
+
#527: [java] False Alarm of JUnit4TestShouldUseTestAnnotation on Predicates
+
#1063: [java] MissingOverride is triggered in illegal places
+
+
+
java-codestyle
+
+
#720: [java] ShortVariable should whitelist lambdas
#1100: [vf] URLENCODE is ignored as valid escape method
+
+
+
+
+
API Changes
+
+
+
The following classes in package net.sourceforge.pmd.benchmark have been deprecated: Benchmark, Benchmarker,
+BenchmarkReport, BenchmarkResult, RuleDuration, StringBuilderCR and TextReport. Their API is not supported anymore
+and is disconnected from the internals of PMD. Use the newer API based around TimeTracker instead, which can be found
+in the same package.
+
The class net.sourceforge.pmd.lang.java.xpath.TypeOfFunction has been deprecated. Use the newer TypeIsFunction in the same package.
+
The typeof methdos in net.sourceforge.pmd.lang.java.xpath.JavaFunctions have been deprecated.
+Use the newer typeIs method in the same class instead..
+
The methods isA, isEither and isNeither of net.sourceforge.pmd.lang.java.typeresolution.TypeHelper.
+Use the new isExactlyAny and isExactlyNone methods in the same class instead.
+
+
+
External Contributions
+
+
+
#966: [java] Issue #955: add new rule to detect identical catch statement - Clément Fournier and BBG
+
#1046: [java] New security rule for finding hard-coded keys used for cryptographic operations - Sergey Gorbaty
+
#1101: [java] Fixes false positive for DoNotExtendJavaLangError - Akshat Bahety
As described in #904, when searching for child nodes of the AST methods
+such as hasDescendantOfType, getFirstDescendantOfType and findDescendantsOfType were found to behave inconsistently,
+not all of them honoring find boundaries; that is, nodes that define a self-contained entity which should be considered separately
+(think of lambdas, nested classes, anonymous classes, etc.). We have modified these methods to ensure all of them honor
+find boundaries.
+
+
This change implies several false positives / unexpected results
+(ie: ASTBlockStatement falsely returning true to isAllocation())
+have been fixed; and lots of searches are now restricted to smaller search areas, which improves performance
+(depending on the project, we have measured up to 10% improvements during Type Resolution, Symbol Table analysis,
+and some rules’ application).
+
+
Naming Rules Enhancements
+
+
+
+
ClassNamingConventions (java-codestyle)
+has been enhanced to allow granular configuration of naming
+conventions for different kinds of type declarations (eg enum or abstract
+class). Each kind of declaration can use its own naming convention
+using a regex property. See the rule’s documentation for more info about
+configuration and default conventions.
Back in PMD 5.6.0 we introduced the ability to suppress CPD warnings in Java using comments, by
+including CPD-OFF (to start ignoring code), or CPD-ON (to resume analysis) during CPD execution.
+This has proved to be much more flexible and versatile than the old annotation-based approach,
+and has since been the preferred way to suppress CPD warnings.
+
+
On this occasion, we are extending support for comment-based suppressions to many other languages:
Thanks to major contributions from kenji21 the Swift grammar has been updated to
+support Swift 4.1. This is a major update, since the old grammar was quite dated, and we are sure all iOS
+developers will enjoy it.
+
+
Unfortunately, this change is not compatible. The grammar elements that have been removed (ie: the keywords __FILE__,
+__LINE__, __COLUMN__ and __FUNCTION__) are no longer supported. We don’t usually introduce such
+drastic / breaking changes in minor releases, however, given that the whole Swift ecosystem pushes hard towards
+always using the latest versions, and that Swift needs all code and libraries to be currently compiling against
+the same Swift version, we felt strongly this change was both safe and necessary to be shipped as soon as possible.
+We had great feedback from the community during the process but if you have a legitimate use case for older Swift
+versions, please let us know on our Issue Tracker.
+
+
New Rules
+
+
+
The new Java rule InsecureCryptoIv (java-security)
+detects hard coded initialization vectors used in cryptographic operations. It is recommended to use
+a randomly generated IV.
+
+
+
Modified Rules
+
+
+
+
The Java rule UnnecessaryConstructor (java-codestyle)
+has been rewritten as a Java rule (previously it was a XPath-based rule). It supports a new property
+ignoredAnnotations and ignores by default empty constructors,
+that are annotated with javax.inject.Inject. Additionally, it detects now also unnecessary private constructors
+in enums.
+
+
+
The property checkNativeMethods of the Java rule MethodNamingConventions (java-codestyle)
+is now deprecated, as it is now superseded by nativePattern. Support for that property will be maintained until
+7.0.0.
+
+
+
The Java rule ControlStatementBraces (java-codestyle)
+supports a new boolean property checkSingleIfStmt. When unset, the rule won’t report if statements which lack
+braces, if the statement is not part of an if ... else if chain. This property defaults to true.
Some time ago, we added support for Incremental Analysis. On PMD 6.0.0, we
+started to add warns when not using it, as we strongly believe it’s a great improvement to our user’s experience as
+analysis time is greatly reduced; and in the future we plan to have it enabled by default. However, we realize some
+scenarios don’t benefit from it (ie: CI jobs), and having the warning logged can be noisy and cause confusion.
+
+
To this end, we have added a new flag to allow you to explicitly disable incremental analysis. On CLI, this is
+the new -no-cache flag. On Ant, there is a noCache attribute for the <pmd> task.
+
+
On both scenarios, disabling the cache takes precedence over setting a cache location.
+
+
New Rules
+
+
+
+
The new Java rule MissingOverride
+(category bestpractices) detects overridden and implemented methods, which are not marked with the
+@Override annotation. Annotating overridden methods with @Override ensures at compile time that
+the method really overrides one, which helps refactoring and clarifies intent.
+
+
+
The new Java rule UnnecessaryAnnotationValueElement
+(category codestyle) detects annotations with a single element (value) that explicitely names it.
+That is, doing @SuppressWarnings(value = "unchecked") would be flagged in favor of
+@SuppressWarnings("unchecked").
+
+
+
The new Java rule ControlStatementBraces
+(category codestyle) enforces the presence of braces on control statements where they are optional.
+Properties allow to customize which statements are required to have braces. This rule replaces the now
+deprecated rules WhileLoopMustUseBraces, ForLoopMustUseBraces, IfStmtMustUseBraces, and
+IfElseStmtMustUseBraces. More than covering the use cases of those rules, this rule also supports
+do ... while statements and case labels of switch statements (disabled by default).
+
+
+
+
Modified Rules
+
+
+
+
The Java rule CommentContentRule (java-documentation) previously had the property wordsAreRegex. But this
+property never had been implemented and is removed now.
+
+
+
The Java rule UnusedPrivateField (java-bestpractices) now has a new ignoredAnnotations property
+that allows to configure annotations that imply the field should be ignored. By default @java.lang.Deprecated
+and @javafx.fxml.FXML are ignored.
+
+
+
The Java rule UnusedPrivateMethod (java-bestpractices) now has a new ignoredAnnotations property
+that allows to configure annotations that imply the method should be ignored. By default @java.lang.Deprecated
+is ignored.
+
+
+
The Java rule ImmutableField (java-design) now has a new ignoredAnnotations property
+that allows to configure annotations that imply the method should be ignored. By default several lombok
+annotations are ignored
+
+
+
The Java rule SingularField (java-design) now has a new ignoredAnnotations property
+that allows to configure annotations that imply the method should be ignored. By default several lombok
+annotations are ignored
+
+
+
+
Deprecated Rules
+
+
+
The Java rules WhileLoopMustUseBraces, ForLoopMustUseBraces, IfStmtMustUseBraces, and IfElseStmtMustUseBraces
+are deprecated. They will be replaced by the new rule ControlStatementBraces, in the category codestyle.
#992: [core] Include info about rule doc generation in “Writing Documentation” md page
+
+
+
+
+
API Changes
+
+
+
+
A new CLI switch, -no-cache, disables incremental analysis and the related suggestion. This overrides the
+ -cache option. The corresponding Ant task parameter is noCache.
+
+
+
The static method PMDParameters.transformParametersIntoConfiguration(PMDParameters) is now deprecated,
+for removal in 7.0.0. The new instance method PMDParameters.toConfiguration() replaces it.
+
+
+
The method ASTConstructorDeclaration.getParameters() has been deprecated in favor of the new method
+getFormalParameters(). This method is available for both ASTConstructorDeclaration and
+ASTMethodDeclaration.
+
+
+
+
External Contributions
+
+
+
#941: [java] Use char notation to represent a character to improve performance - reudismam
+
#943: [java] UnusedPrivateField false-positive with @FXML - BBG
+
#951: [java] Add ignoredAnnotations property to unusedPrivateMethod rule - BBG
+
#952: [java] SignatureDeclareThrowsException’s IgnoreJUnitCompletely property not honored for constructors - BBG
+
#958: [java] Refactor how we ignore annotated elements in rules - BBG
+
#965: [java] Make Varargs trigger ArrayIsStoredDirectly - Stephen
+
#967: [doc] Issue 959: fixed broken link to XPath Rule Tutorial - Andrey Mochalov
+
#969: [java] Issue 968 Add logic to handle lombok private constructors with utility classes - Kirk Clemens
+
#970: [java] Fixed inefficient use of keySet iterator instead of entrySet iterator - Andrey Mochalov
+
#984: [java] issue983 Add new UnnecessaryAnnotationValueElement rule - Kirk Clemens
The Designer now supports configuring properties for XPath based rule development.
+The Designer is still under development and any feedback is welcome.
+
+
You can start the designer via run.sh designer or designer.bat.
+
+
Fixed Issues
+
+
+
all
+
+
#569: [core] XPath support requires specific toString implementations
#885: [java] CompareObjectsWithEqualsRule trigger by enum1 != enum2
+
+
+
java-performance
+
+
#541: [java] ConsecutiveLiteralAppends with types other than string
+
+
+
scala
+
+
#853: [scala] Upgrade scala version to support Java 9
+
+
+
xml
+
+
#739: [xml] IllegalAccessException when accessing attribute using Saxon on JRE 9
+
+
+
+
+
API Changes
+
+
Changes to the Node interface
+
+
The method getXPathNodeName is added to the Node interface, which removes the
+use of the toString of a node to get its XPath element name (see #569).
+A default implementation is provided in AbstractNode, to stay compatible
+with existing implementors.
+
+
The toString method of a Node is not changed for the time being, and still produces
+the name of the XPath node. That behaviour may however change in future major releases,
+e.g. to produce a more useful message for debugging.
+
+
Changes to CPD renderers
+
+
The interface net.sourceforge.pmd.cpd.Renderer has been deprecated. A new interface net.sourceforge.pmd.cpd.renderer.CPDRenderer
+has been introduced to replace it. The main difference is that the new interface is meant to render directly to a java.io.Writer
+rather than to a String. This allows to greatly reduce the memory footprint of CPD, as on large projects, with many duplications,
+it was causing OutOfMemoryErrors (see #795).
+
+
net.sourceforge.pmd.cpd.FileReporter has also been deprecated as part of this change, as it’s no longer needed.
Additional information about the new introduced rule categories
+
+
With the release of PMD 6.0.0, all rules have been sorted into one of the following eight categories:
+
+
+
Best Practices: These are rules which enforce generally accepted best practices.
+
Code Style: These rules enforce a specific coding style.
+
Design: Rules that help you discover design issues.
+
Documentation: These rules are related to code documentation.
+
Error Prone: Rules to detect constructs that are either broken, extremely confusing or prone to runtime errors.
+
Multithreading: These are rules that flag issues when dealing with multiple threads of execution.
+
Performance: Rules that flag suboptimal code.
+
Security: Rules that flag potential security flaws.
+
+
+
Please note, that not every category in every language may have a rule. There might be categories with no
+rules at all, such as category/java/security.xml, which has currently no rules.
+There are even languages, which only have rules of one category (e.g. category/xml/errorprone.xml).
+
+
You can find the information about available rules in the generated rule documentation, available
+at https://pmd.github.io/6.0.1/.
+
+
In order to help migrate to the new category scheme, the new name for the old, deprecated rule names will
+be logged as a warning. See PR #865. Please note, that the deprecated
+rule names will keep working throughout PMD 6. You can upgrade to PMD 6 without the immediate need
+to migrate your current ruleset. That backwards compatibility will be maintained until PMD 7.0.0 is released.
+
+
Fixed Issues
+
+
+
all
+
+
#842: [core] Use correct java bootclasspath for compiling
+
+
+
apex-errorprone
+
+
#792: [apex] AvoidDirectAccessTriggerMap incorrectly detects array access in classes
The constant net.sourceforge.pmd.PMD.VERSION has been deprecated and will be removed with PMD 7.0.0.
+Please use net.sourceforge.pmd.PMDVersion.VERSION instead.
+
+
+
External Contributions
+
+
+
#796: [apex] AvoidDirectAccessTriggerMap incorrectly detects array access in classes - Robert Sösemann
Thanks to Clément Fournier, we now have a new rule designer GUI, which
+is based on JavaFX. It replaces the old designer and can be started via
+
+
+
bin/run.sh designer (on Unix-like platform such as Linux and Mac OS X)
+
bin\designer.bat (on Windows)
+
+
+
Note: At least Java8 is required for the designer. The old designer is still available
+as designerold but will be removed with the next major release.
+
+
Java 9 support
+
+
The Java grammar has been updated to support analyzing Java 9 projects:
+
+
+
private methods in interfaces are possible
+
The underscore “_” is considered an invalid identifier
+
Diamond operator for anonymous classes
+
The module declarations in module-info.java can be parsed
+
Concise try-with-resources statements are supported
+
+
+
Java 9 support is enabled by default. You can switch back to an older java version
+via the command line, e.g. -language java -version 1.8.
+
+
Revamped Apex CPD
+
+
We are now using the Apex Jorje Lexer to tokenize Apex code for CPD. This change means:
+
+
+
All comments are now ignored for CPD. This is consistent with how other languages such as Java and Groovy work.
+
Tokenization honors the language specification, which improves accuracy.
+
+
+
CPD will therefore have less false positives and false negatives.
+
+
Java Type Resolution
+
+
As part of Google Summer of Code 2017, Bendegúz Nagy worked on type resolution
+for Java. For this release he has extended support for method calls for both instance and static methods.
+
+
Method shadowing and overloading are supported, as are varargs. However, the selection of the target method upon
+the presence of generics and type inference is still work in progress. Expect it in forecoming releases.
+
+
As for fields, the basic support was in place for release 5.8.0, but has now been expanded to support static fields.
+
+
Metrics Framework
+
+
As part of Google Summer of Code 2017, Clément Fournier is worked
+on the new metrics framework for object-oriented metrics.
+
+
There are already a couple of metrics (e.g. ATFD, WMC, Cyclo, LoC) implemented. More metrics are planned.
+Based on those metrics, rules like “GodClass” detection could be implemented more easily.
+The following rules benefit from the metrics framework: NcssCount (java), NPathComplexity (java),
+CyclomaticComplexity (both java and apex).
+
+
The Metrics framework has been abstracted and is available in pmd-core for other languages. With this
+PMD release, the metrics framework is supported for both Java and Apex.
+
+
Error Reporting
+
+
A number of improvements on error reporting have taken place, meaning changes to some of the report formats.
+
+
Also of note, the xml report now provides a XML Schema definition, allowing easier parsing and validation.
+
+
Processing Errors
+
+
Processing errors can now provide not only the message previously included on some reports, but also a full stacktrace.
+This will allow better error reports when providing feedback to the PMD team and help in debugging issues.
+
+
The report formats providing full stacktrace of errors are:
+
+
+
html
+
summaryhtml
+
textcolor
+
vbhtml
+
xml
+
+
+
Configuration Errors
+
+
For a long time reports have been notified of configuration errors on rules, but they have remained hidden.
+On a push to make these more evident to users, and help them get the best results out of PMD, we have started
+to include them on the reports.
+
+
So far, only reports that include processing errors are showing configuration errors. In other words, the report formats
+providing configuration error reporting are:
+
+
+
csv
+
html
+
summaryhtml
+
text
+
textcolor
+
vbhtml
+
xml
+
+
+
As we move forward we will be able to detect and report more configuration errors (ie: incomplete auxclasspath)
+and include them to such reports.
+
+
Apex Rule Suppression
+
+
Apex violations can now be suppressed very similarly to how it’s done in Java, by making use of a
+@SuppressWarnings annotation.
+
+
Supported syntax includes:
+
+
@SupressWarnings('PMD') // to supress all Apex rules
+@SupressWarnings('all') // to supress all Apex rules
+@SupressWarnings('PMD.ARuleName') // to supress only the rule named ARuleName
+@SupressWarnings('PMD.ARuleName, PMD.AnotherRuleName') // to supress only the rule named ARuleName or AnotherRuleName
+
+
+
Notice this last scenario is slightly different to the Java syntax. This is due to differences in the Apex grammar for annotations.
+
+
Rule Categories
+
+
All built-in rules have been sorted into one of eight categories:
+
+
+
Best Practices: These are rules which enforce generally accepted best practices.
+
Code Style: These rules enforce a specific coding style.
+
Design: Rules that help you discover design issues.
+
Documentation: These rules are related to code documentation.
+
Error Prone: Rules to detect constructs that are either broken, extremely confusing or prone to runtime errors.
+
Multithreading: These are rules that flag issues when dealing with multiple threads of execution.
+
Performance: Rules that flag suboptimal code.
+
Security: Rules that flag potential security flaws.
+
+
+
These categories help you to find rules and figure out the relevance and impact for your project.
+
+
All rules have been moved accordingly, e.g. the rule “JumbledIncrementer”, which was previously defined in the
+ruleset “java-basic” has now been moved to the “Error Prone” category. The new rule reference to be used is
+<rule ref="category/java/errorprone.xml/JumbledIncrementer"/>.
+
+
The old rulesets like “java-basic” are still kept for backwards-compatibility but will be removed eventually.
+The rule reference documentation has been updated to reflect these changes.
+
+
New Rules
+
+
+
+
The new Java rule NcssCount (category design) replaces the three rules “NcssConstructorCount”, “NcssMethodCount”,
+and “NcssTypeCount”. The new rule uses the metrics framework to achieve the same. It has two properties, to
+define the report level for method and class sizes separately. Constructors and methods are considered the same.
+
+
+
The new Java rule DoNotExtendJavaLangThrowable (category errorprone) is a companion for the
+java-strictexception.xml/DoNotExtendJavaLangError, detecting direct extensions of java.lang.Throwable.
+
+
+
The new Java rule ForLoopCanBeForeach (category errorprone) helps to identify those for-loops that can
+be safely refactored into for-each-loops available since java 1.5.
+
+
+
The new Java rule AvoidFileStream (category performance) helps to identify code relying on FileInputStream / FileOutputStream
+which, by using a finalizer, produces extra / unnecessary overhead to garbage collection, and should be replaced with
+Files.newInputStream / Files.newOutputStream available since java 1.7.
+
+
+
The new Java rule DataClass (category design) detects simple data-holders without behaviour. This might indicate
+that the behaviour is scattered elsewhere and the data class exposes the internal data structure,
+which breaks encapsulation.
+
+
+
The new Apex rule AvoidDirectAccessTriggerMap (category errorprone) helps to identify direct array access to triggers,
+which can produce bugs by either accessing non-existing indexes, or leaving them out. You should use for-each-loops
+instead.
+
+
+
The new Apex rule AvoidHardcodingId (category errorprone) detects hardcoded strings that look like identifiers
+and flags them. Record IDs change between environments, meaning hardcoded ids are bound to fail under a different
+setup.
+
+
+
The new Apex rule CyclomaticComplexity (category design) detects overly complex classes and methods. The
+report threshold can be configured separately for classes and methods.
+
+
A whole bunch of new rules has been added to Apex. They all fit into the category errorprone.
+The 5 rules are migrated for Apex from the equivalent Java rules and include:
+
+
EmptyCatchBlock to detect catch blocks completely ignoring exceptions.
+
EmptyIfStmt for if blocks with no content, that can be safely removed.
+
EmptyTryOrFinallyBlock for empty try / finally blocks that can be safely removed.
+
EmptyWhileStmt for empty while loops that can be safely removed.
+
EmptyStatementBlock for empty code blocks that can be safely removed.
+
+
+
The new Apex rule AvoidSoslInLoops (category performance) is the companion of the old
+AvoidSoqlInLoops rule, flagging SOSL (Salesforce Object Search Language) queries when within
+loops, to avoid governor issues, and hitting the database too often.
+
+
+
Modified Rules
+
+
+
+
The Java rule UnnecessaryFinalModifier (category codestyle, former ruleset java-unnecessarycode)
+has been merged into the rule UnnecessaryModifier. As part of this, the rule has been revamped to detect more cases.
+It will now flag anonymous class’ methods marked as final (can’t be overridden, so it’s pointless), along with
+final methods overridden / defined within enum instances. It will also flag final modifiers on try-with-resources.
+
+
+
The Java rule UnnecessaryParentheses (category codestyle, former ruleset java-controversial)
+has been merged into UselessParentheses (category codestyle, former ruleset java-unnecessary).
+The rule covers all scenarios previously covered by either rule.
+
+
+
The Java rule UncommentedEmptyConstructor (category documentation, former ruleset java-design)
+ will now ignore empty constructors annotated with javax.inject.Inject.
+
+
+
The Java rule AbstractClassWithoutAnyMethod (category bestpractices, former ruleset java-design)
+will now ignore classes annotated with com.google.auto.value.AutoValue.
+
+
+
The Java rule GodClass (category design', former ruleset java-design`) has been revamped to use
+the new metrics framework.
+
+
+
The Java rule LooseCoupling (category bestpractices, former ruleset java-coupling) has been
+replaced by the typeresolution-based implementation.
+
+
+
The Java rule CloneMethodMustImplementCloneable (category errorprone, former ruleset java-clone)
+has been replaced by the typeresolution-based
+implementation and is now able to detect cases if a class implements or extends a Cloneable class/interface.
+
+
+
The Java rule UnusedImports (category bestpractices, former ruleset java-imports) has been
+replaced by the typeresolution-based
+implementation and is now able to detect unused on-demand imports.
+
+
+
The Java rule SignatureDeclareThrowsException (category design, former ruleset ‘java-strictexception’)
+has been replaced by the
+typeresolution-based implementation. It has a new property IgnoreJUnitCompletely, which allows all
+methods in a JUnit testcase to throw exceptions.
+
+
+
The Java rule NPathComplexity (category design, former ruleset java-codesize) has been revamped
+to use the new metrics framework.
+Its report threshold can be configured via the property reportLevel, which replaces the now
+deprecated property minimum.
+
+
+
The Java rule CyclomaticComplexity (category design, former ruleset java-codesize) has been
+revamped to use the new metrics framework.
+Its report threshold can be configured via the properties classReportLevel and methodReportLevel separately.
+The old property reportLevel, which configured the level for both total class and method complexity,
+is deprecated.
+
+
The Java rule CommentRequired (category documentation, former ruleset java-comments)
+has been revamped to include 2 new properties:
+
+
accessorCommentRequirement to specify documentation requirements for getters and setters (default to ignored)
+
methodWithOverrideCommentRequirement to specify documentation requirements for methods annotated with @Override (default to ignored)
+
+
+
+
The Java rule EmptyCatchBlock (category errorprone, former ruleset java-empty) has been changed to ignore
+exceptions named ignore or expected by default. You can still override this behaviour by setting the allowExceptionNameRegex property.
+
+
The Java rule OptimizableToArrayCall (category performance, former ruleset design) has been
+modified to fit for the current JVM implementations: It basically detects now the opposite and suggests to
+use Collection.toArray(new E[0]) with a zero-sized array.
+See Arrays of Wisdom of the Ancients.
+
+
+
Deprecated Rules
+
+
+
+
The Java rules NcssConstructorCount, NcssMethodCount, and NcssTypeCount (ruleset java-codesize) have been
+deprecated. They will be replaced by the new rule NcssCount in the category design.
+
+
+
The Java rule LooseCoupling in ruleset java-typeresolution is deprecated. Use the rule with the same name
+from category bestpractices instead.
+
+
+
The Java rule CloneMethodMustImplementCloneable in ruleset java-typeresolution is deprecated. Use the rule with
+the same name from category errorprone instead.
+
+
+
The Java rule UnusedImports in ruleset java-typeresolution is deprecated. Use the rule with
+the same name from category bestpractices instead.
+
+
+
The Java rule SignatureDeclareThrowsException in ruleset java-typeresolution is deprecated. Use the rule
+with the same name from category design instead.
+
+
+
The Java rule EmptyStaticInitializer in ruleset java-empty is deprecated. Use the rule EmptyInitializer
+from the category errorprone, which covers both static and non-static empty initializers.`
+
+
+
The Java rules GuardDebugLogging (ruleset java-logging-jakarta-commons) and GuardLogStatementJavaUtil
+(ruleset java-logging-java) have been deprecated. Use the rule GuardLogStatement from the
+category bestpractices, which covers all cases regardless of the logging framework.
+
+
+
+
Removed Rules
+
+
+
The deprecated Java rule UseSingleton has been removed from the ruleset java-design. The rule has been renamed
+long time ago to UseUtilityClass (category design).
The Apex parser version was bumped, from 1.0-sfdc-187 to 210-SNAPSHOT. This update let us take full advantage
+of the latest improvements from Salesforce, but introduces some breaking changes:
+
+
+
BlockStatements are now created for all control structures, even if no brace is used. We have therefore added
+a hasCurlyBrace method to differentiate between both scenarios.
+
New AST node types are available. In particular CastExpression, ConstructorPreamble, IllegalStoreExpression,
+MethodBlockStatement, Modifier, MultiStatement, NestedExpression, NestedStoreExpression,
+NewKeyValueObjectExpression and StatementExecuted
+
Some nodes have been removed. Such is the case of TestNode, DottedExpression and NewNameValueObjectExpression
+(replaced by NewKeyValueObjectExpression)
+
+
+
All existing rules have been updated to reflect these changes. If you have custom rules, be sure to update them.
+
+
For more info about the included Apex parser, see the new pmd module “pmd-apex-jorje”, which packages and provides
+the parser as a binary.
+
+
Incremental Analysis
+
+
The incremental analysis feature first introduced in PMD 5.6.0 has been enhanced. A few minor issues have been fixed,
+and several improvements have been performed to make it more accurate.
+
+
The cache will now detect changes to the JARs referenced in the auxclasspath instead of simply looking at their paths
+and order. This means that if you are referencing a JAR you are overwriting in some way, the incremental analysis can
+now detect it and invalidate it’s cache to avoid false reports.
+
+
Similarly, any changes to the execution classpath of PMD will invalidate the cache. This means that if you have custom
+rules packaged in a jar, any changes to it will invalidate the cache automatically.
+
+
We have also improved logging on the analysis code, allowing better insight into how the cache is performing,
+under debug / verbose builds you can even see individual hits / misses to the cache (and the reason for any miss!)
+
+
Finally, as this feature keeps maturing, we are gently pushing this forward. If not using incremental analysis,
+a warning will now be produced suggesting users to adopt it for better performance.
+
+
Rule and Report Properties
+
+
The implementation around the properties support for rule properties and report properties has been revamped
+to be fully typesafe. Along with that change, the support classes have been moved into an own
+package net.sourceforge.pmd.properties. While there is no change necessary in the ruleset XML files,
+when using/setting values for rules, there are adjustments necessary when declaring properties in Java-implemented
+rules.
+
+
Rule properties can be declared both for Java based rules and XPath rules.
+This is now very well documented in Working with properties.
+
+
With PMD 6.0.0, multivalued properties are now also possible with XPath rules.
+
+
Fixed Issues
+
+
+
all
+
+
#394: [core] PMD exclude rules are failing with IllegalArgumentException with non-default minimumPriority
+
#532: [core] security concerns on URL-based rulesets
+
#538: [core] Provide an XML Schema for XML reports
+
#600: [core] Nullpointer while creating cache File
+
#604: [core] Incremental analysis should detect changes to jars in classpath
+
#608: [core] Add DEBUG log when applying incremental analysis
+
#618: [core] Incremental Analysis doesn’t close file correctly on Windows upon a cache hit
+
#643: [core] PMD Properties (dev-properties) breaks markup on CodeClimateRenderer
+
#680: [core] Isolate classloaders for runtime and auxclasspath
+
#762: [core] Remove method and file property from available property descriptors for XPath rules
+
#763: [core] Turn property descriptor util into an enum and enrich its interface
#676: [java] java-unnecessarycode/UnnecessaryFinalModifier on try-with-resources
+
+
+
+
+
API Changes
+
+
+
+
The class net.sourceforge.pmd.lang.dfa.NodeType has been converted to an enum.
+All node types are enum members now instead of int constants. The names for node types are retained.
+
+
+
The Properties API (rule and report properties) has been revamped to be fully typesafe. This is everything
+around net.sourceforge.pmd.properties.PropertyDescriptor.
+
+
Note: All classes related to properties have been moved into the package net.sourceforge.pmd.properties.
+
+
+
The rule classes net.sourceforge.pmd.lang.apex.rule.apexunit.ApexUnitTestClassShouldHaveAsserts
+and net.sourceforge.pmd.lang.apex.rule.apexunit.ApexUnitTestShouldNotUseSeeAllDataTrue have been
+renamed to ApexUnitTestClassShouldHaveAssertsRule and ApexUnitTestShouldNotUseSeeAllDataTrueRule,
+respectively. This is to comply with the naming convention, that each rule class should be suffixed with “Rule”.
+
+
This change has no impact on custom rulesets, since the rule names themselves didn’t change.
+
+
+
The never implemented method PMD.processFiles(PMDConfiguration, RuleSetFactory, Collection<File>, RuleContext, ProgressMonitor) along with the interface ProgressMonitor has been removed.
+
+
+
The method PMD.setupReport(RuleSets, RuleContext, String) is gone. It was used to report dysfunctional
+rules. But PMD does this now automatically before processing the files, so there is no need for this
+method anymore.
+
+
All APIs deprecated in older versions are now removed. This includes:
+
The class net.sourceforge.pmd.lang.java.typeresolution.typedefinition.JavaTypeDefinition is now abstract, and has been enhanced
+to provide several new methods.
+
+
+
The constructor of net.sourceforge.pmd.RuleSetFactory, which took a ClassLoader is deprecated.
+Please use the alternative constructor with the net.sourceforge.pmd.util.ResourceLoader instead.
+
+
The following GUI related classes have been deprecated and will be removed in PMD 7.0.0.
+The tool “bgastviewer”, that could be started via the script bgastviewer.bat or run.sh bgastviewer is
+deprecated, too, and will be removed in PMD 7.0.0.
+Both the “old designer” and “bgastviewer” are replaced by the New Rule Designer.
+
The following methods in net.sourceforge.pmd.Rule have been deprecated and will be removed in PMD 7.0.0.
+All methods are replaced by their bean-like counterparts
+
+
void setUsesDFA(). Use void setDfa(boolean) instead.
+
boolean usesDFA(). Use boolean isDfa() instead.
+
void setUsesTypeResolution(). Use void setTypeResolution(boolean) instead.
+
boolean usesTypeResolution(). Use boolean isTypeResolution() instead.
+
void setUsesMultifile(). Use void setMultifile(boolean) instead.
+
boolean usesMultifile(). Use boolean isMultifile() instead.
+
boolean usesRuleChain(). Use boolean isRuleChain() instead.
As part of Google Summer of Code 2017, Bendegúz Nagy has been working on completing type resolution for Java.
+His progress so far has allowed to properly resolve, in addition to previously supported statements:
+
+
+
References to this and super, even when qualified
+
References to fields, even when chained (ie: this.myObject.aField), and properly handling inheritance / shadowing
+
+
+
Lambda parameter types where these are infered rather than explicit are still not supported. Expect future releases to do so.
+
+
Metrics Framework
+
+
As part of Google Summer of Code 2017, Clément Fournier has been working on
+a new metrics framework for object-oriented metrics.
+
+
The basic groundwork has been done already and with this release, including a first rule based on the
+metrics framework as a proof-of-concept: The rule CyclomaticComplexity, currently in the temporary
+ruleset java-metrics, uses the Cyclomatic Complexity metric to find overly complex code.
+This rule will eventually replace the existing three CyclomaticComplexity rules that are currently
+defined in the java-codesize ruleset (see also issue #445).
+
+
Since this work is still in progress, the metrics API (package net.sourceforge.pmd.lang.java.oom)
+is not finalized yet and is expected to change.
+
+
Modified Rules
+
+
+
+
The Java rule UnnecessaryFinalModifier (ruleset java-unnecessary) now also reports on private methods marked as final.
+Being private, such methods can’t be overriden, and therefore, the final keyword is redundant.
+
+
+
The Java rule PreserveStackTrace (ruleset java-design) has been relaxed to support the builder pattern on thrown exception.
+This change may introduce some false positives if using the exception in non-orthodox ways for things other than setting the
+root cause of the exception. Contact us if you find any such scenarios.
+
+
+
The ruleset java-junit now properly detects JUnit5, and rules are being adapted to the changes on it’s API.
+This support is, however, still incomplete. Let us know of any uses we are still missing on the issue tracker
+
+
+
The Java rule EmptyTryBlock (ruleset java-empty) now allows empty blocks when using try-with-resources.
+
+
+
The Java rule EmptyCatchBlock (ruleset java-empty) now exposes a new property called allowExceptionNameRegex.
+This allow to setup a regular expression for names of exceptions you wish to ignore for this rule. For instance,
+setting it to ^(ignored|expected)$ would ignore all empty catch blocks where the catched exception is named
+either ignored or expected. The default ignores no exceptions, being backwards compatible.
+
+
+
+
Deprecated Rules
+
+
+
The three complexity rules CyclomaticComplexity, StdCyclomaticComplexity, ModifiedCyclomaticComplexity (ruleset java-codesize) have been deprecated. They will be eventually replaced
+by a new CyclomaticComplexity rule based on the metrics framework. See also issue #445.
#406: [java] False positive with lambda in java-design/ConstructorCallsOverridableMethod
+
#409: [java] Groundwork for the upcoming metrics framework
+
#416: [java] FIXED: Java 8 parsing problem with annotations for wildcards
+
#418: [java] Type resolution: super and this keywords
+
#423: [java] Add field access type resolution in non-generic cases
+
#425: [java] False positive with builder pattern in java-design/PreserveStackTrace
+
#426: [java] UnnecessaryFinalModifier final in private method
+
#436: [java] Metrics framework tests and various improvements
+
#440: [core] Created ruleset schema 3.0.0 (to use metrics)
+
#443: [java] Optimize typeresolution, by skipping package and import declarations in visit(ASTName)
+
#444: [java] [typeresolution]: add support for generic fields
+
#451: [java] Metrics framework: first metrics + first rule
+
+
+
20-Mai-2017 - 5.7.0
+
+
The PMD team is pleased to announce PMD 5.7.0.
+
+
This is a minor release.
+
+
New and noteworthy
+
+
Modified Rules
+
+
+
+
The rule “FieldDeclarationsShouldBeAtStartOfClass” of the java-design ruleset has a new property ignoreInterfaceDeclarations.
+Setting this property to true ignores interface declarations, that precede fields.
+Example usage:
+
+
+
+
+
+
+
+
+
+
Renderers
+
+
+
Added the ‘empty’ renderer which will write nothing. Does not affect other behaviors, for example the command line PMD exit status
+will still indicate whether violations were found.
+
+
+
Fixed Issues
+
+
+
General
+
+
#377: [core] Use maven wrapper and upgrade to maven 3.5.0
#1427: [java] Law of Demeter violations for the Builder pattern
+
+
+
java-design
+
+
#345: [java] FieldDeclarationsShouldBeAtStartOfClass: Add ability to ignore interfaces
+
#389: [java] RuleSetCompatibility - not taking rename of UnusedModifier into account
+
+
+
java-junit
+
+
#358: [java] Mockito verify method is not taken into account in JUnitTestsShouldIncludeAssert rule
+
+
+
java-strings
+
+
#334: [java] [doc] Add suggestion to use StringUtils#isBlank for InefficientEmptyStringCheck
+
+
+
jsp-basic
+
+
#369: [jsp] Wrong issue “JSP file should use UTF-8 encoding”
+
+
+
+
+
API Changes
+
+
+
The method net.sourceforge.pmd.util.StringUtil#htmlEncode(String) is deprecated.
+org.apache.commons.lang3.StringEscapeUtils#escapeHtml4(String) should be used instead.
+
+
+
External Contributions
+
+
+
#368: [vf] Adding proper AST support for negation expressions
#364: [core] Stream closed exception when running through maven
+
#373: [core] RuleSetFactory - add more helper methods
+
+
+
+
+
22-April-2017 - 5.6.0
+
+
The PMD team is pleased to announce PMD 5.6.0.
+
+
The most significant changes are on analysis performance, support for Salesforce’s Visualforce language
+a whole new Apex Security Rule Set and the new Braces Rule Set for Apex.
+
+
We have added initial support for incremental analysis. The experimental feature allows
+PMD to cache analysis results between executions to speed up the analysis for all
+languages. New CLI flags and Ant options are available to configure it. Currently
+the feature is disabled by default, but this may change as it matures.
+
+
Multithread performance has been enhanced by reducing thread-contention on a
+bunch of areas. This is still an area of work, as the speedup of running
+multithreaded analysis is still relatively small (4 threads produce less
+than a 50% speedup). Future releases will keep improving on this area.
+
+
Once again, Symbol Table has been an area of great performance improvements.
+This time we were able to further improve it’s performance by roughly 10% on all
+supported languages. In Java in particular, several more improvements were possible,
+improving Symbol Table performance by a whooping 80%, that’s over 15X faster
+than PMD 5.5.1, when we first started working on it.
+
+
Java developers will also appreciate the revamp of CloneMethodMustImplementCloneable,
+making it over 500X faster, and PreserveStackTrace which is now 7X faster.
+
+
New and noteworthy
+
+
Incremental Analysis
+
+
PMD now supports incremental analysis. Analysis results can be cached and reused between runs.
+This allows PMD to skip files without violations that have remained unchanged. In future releases,
+we plan to extend this behavior to unchanged files with violations too.
+
+
The cache is automatically invalidated if:
+
+
the used PMD version changes
+
the auxclasspath changed and any rules require type resolution
+
the configured rule set has changed
+
+
+
This feature is incubating and is disabled by default. It’s only enabled if you
+specifically configure a cache file.
+
+
To configure the cache file from CLI, a new -cache <path/to/file> flag has been added.
+
+
For Ant, a new cacheLocation attribute has been added. For instance:
Salesforce developers rejoice. To out growing Apex support we have added full Visualforce support.
+Both CPD and PD are available. So far only a security ruleset is available (vf-security).
+
+
Visualforce Security Rule Set
+
+
VfUnescapeEl
+
+
The rule looks for Expression Language occurances printing unescaped values from the backend. These
+could lead to XSS attacks.
+
+
VfCsrf
+
+
The rule looks for <apex:page> tags performing an action on page load, definish such action
+through Expression Language, as doing so is vulnerable to CSRF attacks.
+
+
Apex Security Rule Set
+
+
A new ruleset focused on security has been added, consisting of a wide range of rules
+to detect most common security problems.
+
+
ApexBadCrypto
+
+
The rule makes sure you are using randomly generated IVs and keys for Crypto calls.
+Hard-wiring these values greatly compromises the security of encrypted data.
+
+
For instance, it would report violations on code such as:
+
+
public class without sharing Foo {
+ Blob hardCodedIV = Blob.valueOf('Hardcoded IV 123');
+ Blob hardCodedKey = Blob.valueOf('0000000000000000');
+ Blob data = Blob.valueOf('Data to be encrypted');
+ Blob encrypted = Crypto.encrypt('AES128', hardCodedKey, hardCodedIV, data);
+}
+
+
+
+
ApexCRUDViolation
+
+
The rule validates you are checking for access permissions before a SOQL/SOSL/DML operation.
+Since Apex runs in system mode not having proper permissions checks results in escalation of
+privilege and may produce runtime errors. This check forces you to handle such scenarios.
+
+
For example, the following code is considered valid:
+
+
public class Foo {
+ public Contact foo(String status, String ID) {
+ Contact c = [SELECT Status__c FROM Contact WHERE Id=:ID];
+
+ // Make sure we can update the database before even trying
+ if (!Schema.sObjectType.Contact.fields.Name.isUpdateable()) {
+ return null;
+ }
+
+ c.Status__c = status;
+ update c;
+ return c;
+ }
+}
+
+
+
ApexCSRF
+
+
Check to avoid making DML operations in Apex class constructor/init method. This prevents
+modification of the database just by accessing a page.
+
+
For instance, the following code would be invalid:
+
+
public class Foo {
+ public init() {
+ insert data;
+ }
+
+ public Foo() {
+ insert data;
+ }
+}
+
+
+
ApexDangerousMethods
+
+
Checks against calling dangerous methods.
+
+
For the time being, it reports:
+
+
+
Against FinancialForce’s Configuration.disableTriggerCRUDSecurity(). Disabling CRUD security
+opens the door to several attacks and requires manual validation, which is unreliable.
+
Calling System.debug passing sensitive data as parameter, which could lead to exposure
+of private data.
+
+
+
ApexInsecureEndpoint
+
+
Checks against accessing endpoints under plain http. You should always use
+https for security.
+
+
ApexOpenRedirect
+
+
Checks against redirects to user-controlled locations. This prevents attackers from
+redirecting users to phishing sites.
+
+
For instance, the following code would be reported:
+
+
public class without sharing Foo {
+ String unsafeLocation = ApexPage.getCurrentPage().getParameters.get('url_param');
+ PageReference page() {
+ return new PageReference(unsafeLocation);
+ }
+}
+
+
+
ApexSharingViolations
+
+
Detect classes declared without explicit sharing mode if DML methods are used. This
+forces the developer to take access restrictions into account before modifying objects.
+
+
ApexSOQLInjection
+
+
Detects the usage of untrusted / unescaped variables in DML queries.
+
+
For instance, it would report on:
+
+
public class Foo {
+ public void test1(String t1) {
+ Database.query('SELECT Id FROM Account' + t1);
+ }
+}
+
+
+
ApexSuggestUsingNamedCred
+
+
Detects hardcoded credentials used in requests to an endpoint.
+
+
You should refrain from hardcoding credentials:
+
+
They are hard to mantain by being mixed in application code
+
Particularly hard to update them when used from different classes
+
Granting a developer access to the codebase means granting knowledge
+ of credentials, keeping a two-level access is not possible.
+
Using different credentials for different environments is troublesome
+ and error-prone.
+
+
+
Instead, you should use Named Credentials and a callout endpoint.
Reports on calls to addError with disabled escaping. The message passed to addError
+will be displayed directly to the user in the UI, making it prime ground for XSS
+attacks if unescaped.
+
+
ApexXSSFromURLParam
+
+
Makes sure that all values obtained from URL parameters are properly escaped / sanitized
+to avoid XSS attacks.
+
+
Apex Braces Rule Set
+
+
The Braces Rule Set has been added and serves the same purpose as the Braces Rule Set from Java:
+It checks the use and placement of braces around if-statements, for-loops and so on.
+
+
IfStmtsMustUseBraces
+
+
Avoid using if statements without using braces to surround the code block. If the code
+formatting or indentation is lost then it becomes difficult to separate the code being
+controlled from the rest.
+
+
For instance, the following code shows the different. PMD would report on the not recommended approach:
+
+
if (foo) // not recommended
+ x++;
+
+if (foo) { // preferred approach
+ x++;
+}
+
+
+
WhileLoopsMustUseBraces
+
+
Avoid using ‘while’ statements without using braces to surround the code block. If the code
+formatting or indentation is lost then it becomes difficult to separate the code being
+controlled from the rest.
+
+
For instance, the following code shows the different. PMD would report on the not recommended approach:
+
+
while (true) // not recommended
+ x++;
+
+while (true) { // preferred approach
+ x++;
+}
+
+
+
IfElseStmtsMustUseBraces
+
+
Avoid using if..else statements without using surrounding braces. If the code formatting
+or indentation is lost then it becomes difficult to separate the code being controlled
+from the rest.
+
+
For instance, the following code shows the different. PMD would report on the not recommended approach:
+
+
// this is not recommended
+if (foo)
+ x = x+1;
+ else
+ x = x-1;
+
+// preferred approach
+if (foo) {
+ x = x+1;
+} else {
+ x = x-1;
+}
+
+
+
ForLoopsMustUseBraces
+
+
Avoid using ‘for’ statements without using surrounding braces. If the code formatting or
+indentation is lost then it becomes difficult to separate the code being controlled
+from the rest.
+
+
For instance, the following code shows the different. PMD would report on the not recommended approach:
+
+
for (int i = 0; i < 42; i++) // not recommended
+ foo();
+
+for (int i = 0; i < 42; i++) { // preferred approach
+ foo();
+}
+
+
+
New Rules
+
+
AccessorMethodGeneration (java-design)
+
+
When accessing a private field / method from another class, the Java compiler will generate an accessor method
+with package-private visibility. This adds overhead, and to the dex method count on Android. This situation can
+be avoided by changing the visibility of the field / method from private to package-private.
+
+
For instance, it would report violations on code such as:
+
+
public class OuterClass {
+ private int counter;
+ /* package */ int id;
+
+ public class InnerClass {
+ InnerClass() {
+ OuterClass.this.counter++; // wrong, accessor method will be generated
+ }
+
+ public int getOuterClassId() {
+ return OuterClass.this.id; // id is package-private, no accessor method needed
+ }
+ }
+}
+
+
+
This new rule is part of the java-design ruleset.
+
+
Modified Rules
+
+
+
+
The Java rule UnnecessaryLocalBeforeReturn (ruleset java-design) now has a new property statementOrderMatters.
+It is enabled by default to stay backwards compatible. But if this property is set to false, this rule
+no longer requires the variable declaration
+and return statement to be on consecutive lines. Any variable that is used solely in a return statement will be
+reported.
+
+
+
The Java rule UseLocaleWithCaseConversions (ruleset java-design) has been modified, to detect calls
+to toLowerCase and to toUpperCase also within method call chains. This leads to more detected cases
+and potentially new false positives.
+See also bugfix #1556.
+
+
+
The Java rule AvoidConstantsInterface (ruleset java-design) has been removed. It is completely replaced by
+the rule ConstantsInInterface.
+
+
The Java rule UnusedModifier (ruleset java-unusedcode) has been moved to the ruleset java-unnecessary
+and has been renamed to UnnecessaryModifier.
+Additionally, it has been expanded to consider more redundant modifiers:
+
+
Annotations marked as abstract.
+
Nested annotations marked as static.
+
Nested annotations within another interface or annotation marked as public.
+
Classes, interfaces or annotations nested within an annotation marked as public or static.
+
Nested enums marked as static.
+
+
+
The Java rule JUnitTestsShouldIncludeAssert (ruleset java-junit) now accepts usage of @RuleExpectedException
+to set expectations on exceptions, and are considered as valid assertions.
+
+
+
CPD Suppression
+
+
It is now possible to allow CPD suppression through comments in Java. You tell CPD to ignore
+the following code with a comment containin CPD-OFF and with CPD-ON you tell CPD to resume
+analysis. The old approach via @SuppressWarnings annotation is still supported, but is considered
+deprecated, since it is limited to locations where the SuppressWarnings annotation is allowed.
+See PR #250.
CPD now supports the command line option --filelist. With that, you can specify a file, which
+contains the names and paths of the files, that should be analyzed. This is similar to PMD’s filelist option.
+You need to use this, if you have a large project with many files, and you hit the command line length limit.
+
+
Fixed Issues
+
+
+
General
+
+
#1511: [core] Inconsistent behavior of Rule.start/Rule.end
+
#234: [core] Zip file stream closes spuriously when loading rulesets
+
#256: [core] shortnames option is broken with relative paths
#1518: [xml] Error while processing xml file with “.webapp” in the file or directory name
+
+
+
psql
+
+
#1549: [plsql] Parse error for IS [NOT] NULL construct
+
+
+
javascript
+
+
#201: [javascript] template strings are not correctly parsed
+
+
+
+
+
API Changes
+
+
+
net.sourceforge.pmd.RuleSetFactory is now immutable and its behavior cannot be changed anymore.
+It provides constructors to create new adjusted instances. This allows to avoid synchronization in RuleSetFactory.
+See PR #131.
+
net.sourceforge.pmd.RuleSet is now immutable, too, and can only be created via RuleSetFactory.
+See PR #145.
+
net.sourceforge.pmd.cli.XPathCLI has been removed. It’s functionality is fully covered by the Designer.
+
net.sourceforge.pmd.Report now works with ThreadSafeReportListeners. Both ReportListener and
+SynchronizedReportListener are deprecated in favor of net.sourceforge.pmd.ThreadSafeReportListener.
+Therefore, the methods getSynchronizedListeners() and addSynchronizedListeners(...) have been
+replaced by getListeners() and addListeners(...). See PR #193.
+
+
+
External Contributions
+
+
+
#123: [apex] Changing method names to lowercase so casing doesn’t matter
+
#129: [plsql] Added correct parse of IS [NOT] NULL and multiline DML
When accessing a private field / method from another class, the Java compiler will generate a accessor methods
+with package-private visibility. This adds overhead, and to the dex method count on Android. This situation can
+be avoided by changing the visibility of the field / method from private to package-private.
+
+
For instance, it would report violations on code such as:
+
+
public class OuterClass {
+ private int counter;
+ /* package */ int id;
+
+ public class InnerClass {
+ InnerClass() {
+ OuterClass.this.counter++; // wrong, accessor method will be generated
+ }
+
+ public int getOuterClassId() {
+ return OuterClass.this.id; // id is package-private, no accessor method needed
+ }
+ }
+}
+
+
+
This new rule is part of the java-design ruleset.
+
+
Modified Rules
+
+
+
The Java rule UnusedModifier (ruleset java-unusedcode) has been expanded to consider more redundant modifiers.
+
+
Annotations marked as abstract.
+
Nested annotations marked as static.
+
Nested annotations within another interface or annotation marked as public.
+
Classes, interfaces or annotations nested within an annotation marked as public or static.
+
Nested enums marked as static.
+
+
+
The Java rule UnnecessaryLocalBeforeReturn (ruleset java-design) no longer requires the variable declaration
+and return statement to be on consecutive lines. Any variable that is used solely in a return statement will be
+reported.
+
+
+
Fixed Issues
+
+
+
General
+
+
#234: [core] Zip file stream closes spuriously when loading rulesets
+
#256: [core] shortnames option is broken with relative paths
+
+
+
apex-complexity
+
+
#251: [apex] NCSS Type length is incorrect when using method chaining
+
+
+
apex-security
+
+
#264: [apex] ApexXSSFromURLParamRule shouldn’t enforce ESAPI usage. String.escapeHtml4 is sufficient.
+
+
+
java-basic
+
+
#232: [java] SimplifiedTernary: Incorrect ternary operation can be simplified.
The most significant changes are on analysis performance and a whole new Apex Security Rule Set.
+
+
Multithread performance has been enhanced by reducing thread-contention on a
+bunch of areas. This is still an area of work, as the speedup of running
+multithreaded analysis is still relatively small (4 threads produce less
+than a 50% speedup). Future releases will keep improving on this area.
+
+
Once again, Symbol Table has been an area of great performance improvements.
+This time we were able to further improve it’s performance by roughly 10% on all
+supported languages. In Java in particular, several more improvements were possible,
+improving Symbol Table performance by a whooping 30%, that’s over 5X faster
+than PMD 5.5.1, when we first started working on it.
+
+
Java developers will also appreciate the revamp of CloneMethodMustImplementCloneable,
+making it over 500X faster, and PreserveStackTrace which is now 7X faster.
+
+
New and noteworthy
+
+
Apex Security Rule Set
+
+
A new ruleset focused on security has been added, consisting of a wide range of rules
+to detect most common security problems.
+
+
ApexBadCrypto
+
+
The rule makes sure you are using randomly generated IVs and keys for Crypto calls.
+Hard-wiring these values greatly compromises the security of encrypted data.
+
+
For instance, it would report violations on code such as:
+
+
public class without sharing Foo {
+ Blob hardCodedIV = Blob.valueOf('Hardcoded IV 123');
+ Blob hardCodedKey = Blob.valueOf('0000000000000000');
+ Blob data = Blob.valueOf('Data to be encrypted');
+ Blob encrypted = Crypto.encrypt('AES128', hardCodedKey, hardCodedIV, data);
+}
+
+
+
+
ApexCRUDViolation
+
+
The rule validates you are checking for access permissions before a SOQL/SOSL/DML operation.
+Since Apex runs in system mode not having proper permissions checks results in escalation of
+privilege and may produce runtime errors. This check forces you to handle such scenarios.
+
+
For example, the following code is considered valid:
+
+
public class Foo {
+ public Contact foo(String status, String ID) {
+ Contact c = [SELECT Status__c FROM Contact WHERE Id=:ID];
+
+ // Make sure we can update the database before even trying
+ if (!Schema.sObjectType.Contact.fields.Name.isUpdateable()) {
+ return null;
+ }
+
+ c.Status__c = status;
+ update c;
+ return c;
+ }
+}
+
+
+
ApexCSRF
+
+
Check to avoid making DML operations in Apex class constructor/init method. This prevents
+modification of the database just by accessing a page.
+
+
For instance, the following code would be invalid:
+
+
public class Foo {
+ public init() {
+ insert data;
+ }
+
+ public Foo() {
+ insert data;
+ }
+}
+
+
+
ApexDangerousMethods
+
+
Checks against calling dangerous methods.
+
+
For the time being, it reports:
+
+
+
Against FinancialForce’s Configuration.disableTriggerCRUDSecurity(). Disabling CRUD security
+opens the door to several attacks and requires manual validation, which is unreliable.
+
Calling System.debug passing sensitive data as parameter, which could lead to exposure
+of private data.
+
+
+
ApexInsecureEndpoint
+
+
Checks against accessing endpoints under plain http. You should always use
+https for security.
+
+
ApexOpenRedirect
+
+
Checks against redirects to user-controlled locations. This prevents attackers from
+redirecting users to phishing sites.
+
+
For instance, the following code would be reported:
+
+
public class without sharing Foo {
+ String unsafeLocation = ApexPage.getCurrentPage().getParameters.get('url_param');
+ PageReference page() {
+ return new PageReference(unsafeLocation);
+ }
+}
+
+
+
ApexSharingViolations
+
+
Detect classes declared without explicit sharing mode if DML methods are used. This
+forces the developer to take access restrictions into account before modifying objects.
+
+
ApexSOQLInjection
+
+
Detects the usage of untrusted / unescaped variables in DML queries.
+
+
For instance, it would report on:
+
+
public class Foo {
+ public void test1(String t1) {
+ Database.query('SELECT Id FROM Account' + t1);
+ }
+}
+
+
+
ApexSuggestUsingNamedCred
+
+
Detects hardcoded credentials used in requests to an endpoint.
+
+
You should refrain from hardcoding credentials:
+
+
They are hard to mantain by being mixed in application code
+
Particularly hard to update them when used from different classes
+
Granting a developer access to the codebase means granting knowledge
+ of credentials, keeping a two-level access is not possible.
+
Using different credentials for different environments is troublesome
+ and error-prone.
+
+
+
Instead, you should use Named Credentials and a callout endpoint.
Reports on calls to addError with disabled escaping. The message passed to addError
+will be displayed directly to the user in the UI, making it prime ground for XSS
+attacks if unescaped.
+
+
ApexXSSFromURLParam
+
+
Makes sure that all values obtained from URL parameters are properly escaped / sanitized
+to avoid XSS attacks.
+
+
Modified Rules
+
+
The Java rule “UseLocaleWithCaseConversions” (ruleset java-design) has been modified, to detect calls
+to toLowerCase and to toUpperCase also within method call chains. This leads to more detected cases
+and potentially new false positives.
+See also bugfix #1556.
+
+
Fixed Issues
+
+
+
General
+
+
#1511: [core] Inconsistent behavior of Rule.start/Rule.end
+
+
+
apex-apexunit
+
+
#1543: [apex] ApexUnitTestClassShouldHaveAsserts assumes APEX is case sensitive
+
+
+
apex-complexity
+
+
#183: [apex] NCSS Method length is incorrect when using method chaining
+
+
+
java
+
+
#185: [java] CPD runs into NPE when analyzing Lucene
+
#206: [java] Parse error on annotation fields with generics
+
#207: [java] Parse error on method reference with generics
+
#208: [java] Parse error with local class with 2 or more annotations
+
#213: [java] CPD: OutOfMemory when analyzing Lucene
+
#1542: [java] CPD throws an NPE when parsing enums with -ignore-identifiers
+
#1545: [java] Symbol Table fails to resolve inner classes
+
+
+
java-design
+
+
#1448: [java] ImmutableField: Private field in inner class gives false positive with lambdas
+
#1495: [java] UnnecessaryLocalBeforeReturn with assert
+
#1552: [java] MissingBreakInSwitch - False positive for continue
+
#1556: [java] UseLocaleWithCaseConversions does not works with ResultSet (false negative)
+
#177: [java] SingularField with lambdas as final fields
+
+
+
java-imports
+
+
#1546: [java] UnnecessaryFullyQualifiedNameRule doesn’t take into consideration conflict resolution
+
#1547: [java] UnusedImportRule - False Positive for only usage in Javadoc - {@link ClassName#CONSTANT}
+
#1555: [java] UnnecessaryFullyQualifiedName: Really necessary fully qualified name
+
+
+
java-logging-java
+
+
#1541: [java] InvalidSlf4jMessageFormat: False positive with placeholder and exception
+
#1551: [java] InvalidSlf4jMessageFormat: fails with NPE
+
+
+
java-unnecessary
+
+
#199: [java] UselessParentheses: Parentheses in return statement are incorrectly reported as useless
+
+
+
java-strings
+
+
#202: [java] [doc] ConsecutiveAppendsShouldReuse is not really an optimization
+
+
+
XML
+
+
#1518: [xml] Error while processing xml file with “.webapp” in the file or directory name
+
+
+
psql
+
+
#1549: [plsql] Parse error for IS [NOT] NULL construct
+
+
+
javascript
+
+
#201: [javascript] template strings are not correctly parsed
+
+
+
+
+
API Changes
+
+
+
net.sourceforge.pmd.RuleSetFactory is now immutable and its behavior cannot be changed anymore.
+It provides constructors to create new adjusted instances. This allows to avoid synchronization in RuleSetFactory.
+See PR #131.
+
+
+
External Contributions
+
+
+
#123: [apex] Changing method names to lowercase so casing doesn’t matter
+
#129: [plsql] Added correct parse of IS [NOT] NULL and multiline DML
java-logging-java/InvalidSlf4jMessageFormat: Check for invalid message format in slf4j loggers.
+See PR#73.
+
java-design/ConstantsInInterface: Avoid constants in interfaces.
+Interfaces should define types, constants are implementation details
+better placed in classes or enums. See Effective Java, item 19.
+See PR#93.
+
+
+
Modified rules in Java:
+
+
java-comments/CommentRequired: New property serialVersionUIDCommentRequired which controls the comment requirements
+for serialVersionUID fields. By default, no comment is required for this field.
+
java-design/UseVargs: public static void main method is ignored now and so are methods, that are annotated
+with Override. See PR#79.
New Rule: ecmascript-unnecessary/NoElseReturn: The else block in a if-else-construct is
+unnecessary if the if block contains a return. Then the content of the else block can be
+put outside. See #1486.
+
+
+
+
+
Improvements and CLI changes:
+
+
+
A JSON-renderer for PMD which is compatible with CodeClimate. See PR#83.
+
#1360: [core] [java] Provide backwards compatibility for PMD configuration file
+
CPD: If a complete filename is specified, the language dependent filename filter is not applied. This allows
+to scan files, that are not using the standard file extension. If a directory is specified, the filename filter
+is still applied and only those files with the correct file extension of the language are scanned.
+
CPD: If no problems found, an empty report will be output instead of nothing. See also #1481
+
CPD: New command line parameter --ignore-usings: Ignore using directives in C# when comparing text.
+
PMD: New command line parameter: -norulesetcompatibility - this disables the ruleset factory
+compatibility filter and fails, if e.g. an old rule name is used in the ruleset.
+See also #1360.
+This option is also available for the ant task: <noRuleSetCompatibility>true</noRuleSetCompatibility>.
+
PMD: New command line parameter: -filelist- this provides an alternative way to define, which
+files should be process by PMD. With this option, you can provide the path to a single file containing a comma
+delimited list of files to analyze. If this is given, then you don’t need to provide -dir.
+See PR#98.
+
+
+
Pull Requests:
+
+
+
#25: [cs] Added option to exclude C# using directives from CPD analysis
+
#27: [cpp] Added support for Raw String Literals (C++11).
+
[#29)(https://github.com/adangel/pmd/pull/29): [jsp] Added support for files with UTF-8 BOM to JSP tokenizer.
+
#30: [core] CPD: Removed file filter for files that are explicitly specified on the CPD command line using the ‘–files’ command line option.
+
#31: [core] CPD: Added file encoding detection to CPD.
+
#32: [objectivec] Extended Objective-C grammar to accept UTF-8 escapes (\uXXXX) in string literals.
#266: [java] corrected invalid reporting of LoD violation
+
+
+
28-January-2017 - 5.4.4
+
+
The PMD team is pleased to announce PMD 5.4.4
+
+
This is a bug fixing release. The most significant changes are on analysis performance.
+
+
Multithread performance has been enhanced by reducing thread-contention on a
+bunch of areas. This is still an area of work, as the speedup of running
+multithreaded analysis is still relatively small (4 threads produce less
+than a 50% speedup). Future releases will keep improving on this area.
+
+
Once again, Symbol Table has been an area of great performance improvements.
+This time we were able to further improve it’s performance by roughly 10% on all
+supported languages. In Java in particular, several more improvements were possible,
+improving Symbol Table performance by a whooping 30%, that’s over 5X faster
+than PMD 5.4.2, when we first started working on it.
+
+
Java developers will also appreciate the revamp of CloneMethodMustImplementCloneable,
+making it over 500X faster, and PreserveStackTrace which is now 7X faster.
+
+
New and noteworthy
+
+
This is a bug fixing release, no major changes were introduced.
+
+
Modified Rules
+
+
The Java rule “UseLocaleWithCaseConversions” (ruleset java-design) has been modified, to detect calls
+to toLowerCase and to toUpperCase also within method call chains. This leads to more detected cases
+and potentially new false positives.
+See also bugfix #1556.
+
+
Fixed Issues
+
+
+
java
+
+
#206: [java] Parse error on annotation fields with generics
+
#207: [java] Parse error on method reference with generics
+
#208: [java] Parse error with local class with 2 or more annotations
+
#213: [java] CPD: OutOfMemory when analyzing Lucene
+
+
+
java-design
+
+
#1448: [java] ImmutableField: Private field in inner class gives false positive with lambdas
+
#1495: [java] UnnecessaryLocalBeforeReturn with assert
+
#1552: [java] MissingBreakInSwitch - False positive for continue
+
#1556: [java] UseLocaleWithCaseConversions does not works with ResultSet (false negative)
+
#177: [java] SingularField with lambdas as final fields
+
+
+
java-imports
+
+
#1546: [java] UnnecessaryFullyQualifiedNameRule doesn’t take into consideration conflict resolution
+
#1547: [java] UnusedImportRule - False Positive for only usage in Javadoc - {@link ClassName#CONSTANT}
+
#1555: [java] UnnecessaryFullyQualifiedName: Really necessary fully qualified name
+
+
+
java-unnecessary
+
+
#199: [java] UselessParentheses: Parentheses in return statement are incorrectly reported as useless
+
+
+
java-strings
+
+
#202: [java] [doc] ConsecutiveAppendsShouldReuse is not really an optimization
+
+
+
XML
+
+
#1518: [xml] Error while processing xml file with “.webapp” in the file or directory name
+
+
+
psql
+
+
#1549: [plsql] Parse error for IS [NOT] NULL construct
+
+
+
javascript
+
+
#201: [javascript] template strings are not correctly parsed
+
+
+
General
+
+
#1511: [core] Inconsistent behavior of Rule.start/Rule.end
+
+
+
+
+
External Contributions
+
+
+
#129: [plsql] Added correct parse of IS [NOT] NULL and multiline DML
+
#152: [java] fixes #1552 continue does not require break
+
#154: [java] Fix #1547: UnusedImports: Adjust regex to support underscores
+
#170: [core] Ant Task Formatter encoding issue with XMLRenderer
#1481: no problems found results in blank file instead of empty xml
+
+
+
+
+
CLI Changes:
+
+
+
CPD: If a complete filename is specified, the language dependent filename filter is not applied. This allows
+to scan files, that are not using the standard file extension. If a directory is specified, the filename filter
+is still applied and only those files with the correct file extension of the language are scanned.
+
CPD: If no problems found, an empty report will be output instead of nothing. See also #1481
+
New command line parameter for PMD: -norulesetcompatibility - this disables the ruleset factory
+compatibility filter and fails, if e.g. an old rule name is used in the ruleset.
+See also #1360.
+This option is also available for the ant task: <noRuleSetCompatibility>true</noRuleSetCompatibility>.
+
+
+
04-December-2015 - 5.4.1
+
+
Feature Request and Improvements:
+
+
+
CPD: New command line parameter --ignore-usings: Ignore using directives in C# when comparing text.
+
+
+
Modified Rules:
+
+
+
java-comments/CommentRequired: New property serialVersionUIDCommentRequired which controls the comment requirements
+for serialVersionUID fields. By default, no comment is required for this field.
+
+
+
Pull Requests:
+
+
+
#25: Added option to exclude C# using directives from CPD analysis
+
#72: Added capability in Java and JSP parser for tracking tokens.
+
#74: Fix rendering CommentDefaultAccessModifier description as code
#1361: ShortVariable and ShortMethodName configuration
+
#1414: Command line parameter to disable “failOnViolation” behavior
+PMD and CPD Command Line Interfaces have a new optional parameter: failOnViolation. Executing PMD with the option
+-failOnViolation false will perform the PMD checks but won’t fail the build and still exit with status 0.
+This is useful if you only want to generate the report with violations but don’t want to fail your build.
+
#1420: UnusedPrivateField: Ignore fields if using lombok
+
+
+
New Rules:
+
+
+
+
Java:
+
+
+
+
Basic: SimplifiedTernary (rulesets/java/basic.xml/SimplifiedTernary)
+Ternary operator with a boolean literal can be simplified with a boolean
+expression.
+
+
+
Clone: CloneMethodMustBePublic (rulesets/java/clone.xml/CloneMethodMustBePublic)
+The java manual says “By convention,
+classes that implement the Cloneable interface should override Object.clone (which is protected)
+with a public method.”
+
+
+
Clone: CloneMethodReturnTypeMustMatchClassName (rulesets/java/clone.xml/CloneMethodReturnTypeMustMatchClassName)
+If a class implements Cloneable
+the return type of the method clone() must be the class name.
+
+
+
Comments: CommentDefaultAccessModifier (rulesets/java/comments.xml/CommentDefaultAccessModifier)
+In order to avoid mistakes with
+forgotten access modifiers for methods, this rule ensures, that you explicitly mark the usage of the
+default access modifier by placing a comment.
+
+
+
Design: SingletonClassReturningNewInstance (rulesets/java/design.xml/SingletonClassReturningNewInstance)
+Verifies that the method called getInstance returns a cached instance and not always a fresh, new instance.
+
+
+
Design: SingleMethodRule (rulesets/java/design.xml/SingleMethodSingletonRule)
+Verifies that there is only one method called
+getInstance. If there are more methods that return the singleton, then it can easily happen, that these
+are not the same instances - and thus no singleton.
+
+
+
Unnecessary: UselessQualifiedThis (rulesets/java/unnecessary.xml/UselessQualifiedThis)
+Flags unnecessary qualified usages
+of this, when this alone would be unique. E.g. use just this instead of Foo.this.
+
+
+
+
+
Maven POM: (The rules can be found in the pmd-xml module)
+
+
+
+
Basic: ProjectVersionAsDependencyVersion (rulesets/pom/basic.xml/ProjectVersionAsDependencyVersion)
+Checks the usage of ${project.version} in Maven POM files.
+
+
+
Basic: InvalidDependencyTypes (rulesets/pom/basic.xml/InvalidDependencyTypes)
+Verifies that only the default types (jar, war, …) for dependencies are used.
Basic: CheckResultSet (rulesets/java/basic.xml/CheckResultSet)
+Do not require to check the result of a navigation method, if it is returned.
+
+
+
JUnit: UseAssertTrueInsteadOfAssertEquals (rulesets/java/junit.xml/UseAssertTrueInsteadOfAssertEquals)
+This rule also flags assertEquals, that use Boolean.TRUE/FALSE constants.
+
+
+
Naming: AbstractNaming (rulesets/java/naming.xml/AbstractNaming)
+By default, this rule flags now classes,
+that are named “Abstract” but are not abstract. This behavior can be disabled by setting
+the new property strict to false.
+
+
+
Naming: ShortMethodName (rulesets/java/naming.xml/ShortMethodName)
+Additional property minimum to configure the minimum required length of a method name.
+
+
+
Naming: ShortVariable (rulesets/java/naming.xml/ShortVariable)
+Additional property minimum to configure the minimum required length of a variable name.
+
+
+
UnusedCode: UnusedPrivateField (rulesets/java/unusedcode.xml/UnusedPrivateField)
+This rule won’t trigger anymore if Lombok is in use.
+See #1420.
+
+
+
+
+
+
Renamed Rules:
+
+
+
Java
+
+
Design: UseSingleton - UseUtilityClass (rulesets/java/design.xml/UseUtilityClass)
+The rule “UseSingleton” has been renamed to “UseUtilityClass”.
+See also bugs #1059 and #1339.
+
+
+
+
+
Removed Rules:
+
+
+
Java
+
+
+
Basic: The following rules of ruleset “Basic” were marked as deprecated and are removed with this release now:
+
+EmptyCatchBlock, EmptyIfStatement, EmptyWhileStmt, EmptyTryBlock, EmptyFinallyBlock, EmptySwitchStatements, EmptySynchronizedBlock, EmptyStatementNotInLoop, EmptyInitializer, EmptyStatementBlock, EmptyStaticInitializer
+
+These rules are still available in the rulesets “Empty” (rulesets/java/empty.xml) and
+“Unnecessary” (rulesets/java/unnecessary.xml) respectively.
+
+
+
Design: The rule “UncommentedEmptyMethod” has been renamed last release to “UncommentedEmptyMethodBody”. The
+old rule name reference has been removed with this release now.
+
+
+
Controversial: The rule “BooleanInversion” has been deprecated last release
+and has been removed with this release completely.
+
+
+
+
+
+
Pull Requests:
+
+
+
#21: Added PMD Rules for Singleton pattern violations.
+
#23: Extended Objective-C grammar to accept Unicode characters in identifiers
The method addNameOccurrence returns now a Set of
+NameDeclarations to which the given occurrence has been added. This is useful in case there are ambiguous declarations
+of methods.
The method findVariableHere returns now
+a Set of NameDeclarations which match the given occurrence. This is useful in case there are ambiguous declarations
+of methods.
+
+
+
+
04-November-2016 - 5.3.8
+
+
Summary
+
+
+
1 feature requests
+
6 pull requests
+
17 bug fixes
+
+
+
Feature Requests and Improvements:
+
+
+
#1360: [core] [java] Provide backwards compatibility for PMD configuration file
+
+
+
Pull Requests:
+
+
+
#35: [javascript] Javascript tokenizer now ignores comment tokens.
+
#103: [java] Fix for 1501: CyclomaticComplexity rule causes OOM when class reporting is disabled
+
#111: [java] Fix BooleanInstantiationRule for Java 8
+
#112: [java] Fix ClassCastException on CloneMethodMustImplementCloneable
+
#113: [java] Fix ClassCastException on SignatureDeclareThrowsException
+
#119: [plsql] Fix PMD issue 1531- endless loop followed by OOM while parsing (PL)SQL
+
+
+
Bugfixes:
+
+
+
java
+
+
#1501: [java] [apex] CyclomaticComplexity rule causes OOM when class reporting is disabled
+
+
+
java-basic/BooleanInstantiation
+
+
#1533: [java] BooleanInstantiation: ClassCastException with Annotation
New command line parameter for PMD: -norulesetcompatibility - this disables the ruleset factory
+compatibility filter and fails, if e.g. an old rule name is used in the ruleset.
+See also #1360.
+This option is also available for the ant task: <noRuleSetCompatibility>true</noRuleSetCompatibility>.
+
CPD: If no problems found, an empty report will be output instead of nothing. See also #1481
CPD: If a complete filename is specified, the language dependent filename filter is not applied. This allows
+to scan files, that are not using the standard file extension. If a directory is specified, the filename filter
+is still applied and only those files with the correct file extension of the language are scanned.
+
+
+
04-December-2015 - 5.3.6
+
+
Feature Request and Improvements:
+
+
+
CPD: New command line parameter --ignore-usings: Ignore using directives in C# when comparing text.
+
+
+
Modified Rules:
+
+
+
java-comments/CommentRequired: New property serialVersionUIDCommentRequired which controls the comment requirements
+for serialVersionUID fields. By default, no comment is required for this field.
+
+
+
Pull Requests:
+
+
+
#25: Added option to exclude C# using directives from CPD analysis
+
#1441: PMD: Update documentation how to compile after modularization
+
+
+
+
+
04-October-2015 - 5.3.5
+
+
Modified Rules:
+
+
+
java-design/CloseResource: New Property closeAsDefaultTarget which is true by default to stay
+backwards compatible. If this property is true, the rule will make sure, that close itself is
+always considered as a closeTarget - no matter whether it is configured with the closeTargets property
+or not.
+
+
+
Pull Requests:
+
+
+
#71: #1410 Improve description of DefaultPackage rule
+
+
+
Bugfixes:
+
+
+
java-controversial/DefaultPackage:
+
+
#1410: DefaultPackage triggers on field annotated with @VisibleForTesting
+
+
+
java-design/CloseResource:
+
+
#1387: CloseResource has false positive for ResultSet
+
+
+
java-optimizations/RedundantFieldInitializer
+
+
#1418: RedundantFieldInitializer false positive with large long value
PMD exits with status 4 if any violations have been found. This behavior has been introduced to ease PMD
+integration into scripts or hooks, such as SVN hooks.
+
+
+
New/Modified/Deprecated Rules:
+
+
The following rules have been
+enhanced
+:
+
+
+
Language Java, ruleset design.xml: The rule “SimplifyBooleanReturns” now also marks methods where the else case is omitted and just a return.
+See also feature #1320.
+
+
+
The following rules are marked as
+deprecated
+and will be removed with the next release of PMD.
+
+
+
+
Language Java, ruleset basic.xml: The following rules have been moved into the empty.xml ruleset. You’ll need
+to enable the “empty” ruleset explicitly from now on, if you want to have these rules executed:
Language Java, ruleset basic.xml: The following rules have been moved into the unnecessary.xml ruleset. You’ll need
+to enable the “unnecessary” ruleset explicitly from now on, if you want to have these rules executed:
Language Java, ruleset design.xml: The rule “UncommentedEmptyMethod” has been renamed to “UncommentedEmptyMethodBody”.
+See also bug #1283.
+
+
+
Language Java, ruleset controversial.xml: The rule “BooleanInversion” is deprecated and will be removed with
+the next release. See #1277 for more details.
#1322: MethodReturnsInternalArray on private methods
+
#1323: False positive case of UseAssertTrueInsteadOfAssertEquals
+
#1324: MethodReturnsInternalArray false positive with clone()
+
#1325: Inner class declared within a method fails to parse (ClassCastException)
+
#1326: PMD 5.3.0-SNAPSHOT doesn’t compile under Windows
+
+
+
API Changes:
+
+
+
+
net.sourceforge.pmd.cpd.Match.iterator() now returns an iterator of the new type net.sourceforge.pmd.cpd.Mark instead
+of TokenEntry. A Mark contains all the informations about each single duplication, including the TokenEntry via Mark.getToken().
+This Mark is useful for reporting the correct line count for each duplication. Previously only one line count was available.
+As for some languages CPD can be instructed to ignore comments, the line count could be different in the different files
+for the same duplication.
+
+
+
pmd-test: The utility class StreamUtil is deprecated. Just use Apache Commons IO Utils instead.
+
+
+
+
December 21, 2014 - 5.2.3:
+
+
Feature Requests and Improvements:
+
+
+
#1288: MethodNamingConventions for native should be deactivated
+
#1293: Disable VariableNamingConventions for native methods
+
+
+
Modified Rules:
+
+
+
Java / Design / UseVarargs: if byte[] is used as the last argument, it is ignored and no violation will be reported.
#1275: False positive: UnusedModifier rule for static inner class in enum
+
+
+
October 17, 2014 - 5.2.0:
+
+
Modularization of the source code:
+
+
The source code of pmd was undergoing a major restructuring. Each language is separated
+out into its own module. This reduces the size of the artifacts significantly, if only
+one language is needed. It also makes it easier, to add new languages as extensions.
+
+
Therefore, the maven coordinates needed to change. In order to just use pmd with java support, you’ll need
+the following two dependencies:
#1244: FieldDeclarationsShouldBeAtStartOfClass and anonymous classes
+
+
+
New/Modified Rules:
+
+
+
FieldDeclarationsShouldBeAtStartOfClass (ruleset java-design) has a new property called ignoreAnonymousClassDeclarations:
+Ignore Field Declarations, that are initialized with anonymous class declarations. This property is enabled by default.
+See feature #1244.
+
ShortClassName (ruleset java-naming) has a new property called minimum: Number of characters that are required
+as a minimum for a class name. By default, 5 characters are required - if the class name is shorter, a violation
+will be reported. See feature #1232.
+
+
+
July 20, 2014 - 5.1.2:
+
+
Bugfixes:
+
+
+
Fixed bug #1181: unused import false positive if used as parameter in javadoc only.
+
Fixed bug #1192: Ecmascript fails to parse this operator “ ^= “
+
Fixed bug #1198: ConfusingTernary does not ignore else if blocks even when property is set
Fixed bug 1175: false positive for StringBuilder.append called 2 consecutive times
+
Fixed bug 1176: ShortVariable false positive with for-each loops
+
Fixed bug 1177: Incorrect StringBuffer warning when that class is not used
+
Fixed bug 1178: LexicalError while parsing Java code aborts CPD run
+
Fixed bug 1180: False Positive for ConsecutiveAppendsShouldReuse on different variable names
+
Fixed bug 1185: UnusedModifier throws NPE when parsing enum with a nested static interface
+
Fixed bug 1188: False positive in UnusedPrivateField
+
Fixed bug 1191: Ecmascript fails to parse “void(0)”
+
Document that PMD requires Java 1.6, see discussion.
+
+
+
+
+
+
CPD Changes:
+
+
+
Command Line
+
+
Added option “–skip-lexical-errors” to skip files, which can’t be tokenized
+due to invalid characters instead of aborting CPD. See also bug 1178.
+
+
+
Ant
+
+
New optional parameter “skipDuplicateFiles”: Ignore multiple copies of files of the same name and length in
+comparison; defaults to “false”.
+This was already a command line option, but now also available in in CPD’s ant task.
+
New optional parameter “skipLexicalErros”: Skip files which can’t be tokenized due to invalid characters
+instead of aborting CPD; defaults to “false”.
+
+
+
+
+
February 11, 2014 - 5.1.0:
+
+
New/Updated Languages:
+
+
+
Java 1.8 support added.
+
PLSQL support added; thanks to Stuart Turton. See also http://pldoc.sourceforge.net/
+
Apache Velocity support added; thanks to Andrey Utis. See also http://velocity.apache.org
rule similar to PositionLiteralsFirstInComparisons, but for case insensitive comparisons (equalsIgnoreCase).
+Thanks to Larry Diamond
+
+
+
ConfusingTernary
+
+
new property “ignoreElseIf” to suppress this rule in case of if-else-if-else usage.
+See feature 1161: Confusing Ternary should skip else if statements (or have a property to do so)
+
+
+
FieldDeclarationsShouldBeAtStartOfClass
+
+
new property “ignoreEnumDeclarations” which is enabled by default. This relaxes the rule, so
+that enums can be declared before fields and the rule is not triggered.
Fixed bug 1150: “EmptyExpression” for valid statements!
+
Fixed bug 1154: Call super onPause when there is no super
+
Fixed bug 1155: maven pmd plugin does not like empty rule sets
+
Fixed bug 1159: false positive UnusedFormalParameter readObject(ObjectInputStream) if not used
+
Fixed bug 1164: Violations are not suppressed with @java.lang.SuppressWarnings(“all”)
+
+
+
CPD Changes:
+
+
Command Line
+
+
Added non-recursive option “–non-recursive” to not scan sub-directories
+
Added option “–exclude” to exclude specific files from being scanned (thanks to Delmas for patch #272)
+
+
+
CPD is now thread-safe, so that multiple instances of CPD can run concurrently without stepping
+ on each other (eg: multi-module Maven projects.). Thanks to David Golpira.
+
+
+
Miscellaneous:
+
+
+
Upgrade to javacc 5.0 (see patch #1109 Patch to build with Javacc 5.0)
+
DBURI as DataSource possible - directly scan plsql code stored within the database
+
+
+
API Changes
+
+
+
Deprecated APIs:
+
+
net.sourceforge.pmd.lang.ecmascript.ast.ASTFunctionNode: getBody(int index) deprecated, use getBody() instead
+
net.sourceforge.pmd.lang.ecmascript.ast.ASTTryStatement: isCatch() and isFinally() deprecated, use hasCatch() and hasBody() instead
Fixed bug 991: AvoidSynchronizedAtMethodLevel for static methods
+Fixed bug 1084: NPE at UselessStringValueOfRule.java:36
+Fixed bug 1091: file extension for fortran seems to be wrong in cpdgui tools
+Fixed bug 1092: Wrong Attribute "excludemarker" in Ant Task Documentation
+Fixed bug 1095: AvoidFinalLocalVariable false positive
+Fixed bug 1099: UseArraysAsList false positives
+Fixed bug 1102: False positive: shift operator parenthesis
+Fixed bug 1104: IdempotentOperation false positive
+Fixed bug 1107: PMD 5.0.4 couldn't parse call of parent outer java class method from inner class
+Fixed bug 1069: Eclipse plugin does not accept project-local config
+Fixed bug 1111: False positive: Useless parentheses
+Fixed bug 1114: CPD - Tokenizer not initialized with requested properties
+Fixed bug 1118: ClassCastException in pmd.lang.ecmascript.ast.ASTElementGet
+
+
+
May 1, 2013 - 5.0.4:
+
+
Fixed bug 254: False+ : UnusedImport with Javadoc @throws
+Fixed bug 794: False positive on PreserveStackTrace with anonymous inner
+Fixed bug 1063: False+: ArrayIsStoredDirectly
+Fixed bug 1080: net.sourceforge.pmd.cpd.CPDTest test failing
+Fixed bug 1081: Regression: CPD skipping all files when using relative paths
+Fixed bug 1082: CPD performance issue on larger projects
+Fixed bug 1085: NullPointerException by at net.sourceforge.pmd.lang.java.rule.design.GodClassRule.visit(GodClassRule.java:313)
+Fixed bug 1086: Unsupported Element and Attribute in Ant Task Example
+Fixed bug 1087: PreserveStackTrace (still) ignores initCause()
+Fixed bug 1089: When changing priority in a custom ruleset, violations reported twice
+
+
+
April 5, 2013 - 5.0.3:
+
+
Fixed bug 938: False positive on LooseCoupling for overriding methods
+Fixed bug 940: False positive on UnsynchronizedStaticDateFormatter
+Fixed bug 942: CheckResultSet False Positive and Negative
+Fixed bug 943: PreserveStackTrace false positive if a StringBuffer exists
+Fixed bug 945: PMD generates RuleSets it cannot read.
+Fixed bug 958: Intermittent NullPointerException while loading XPath node attributes
+Fixed bug 968: Issues with JUnit4 @Test annotation with expected exception (Thanks to Yiannis Paschalidis)
+Fixed bug 975: false positive in ClassCastExceptionWithToArray
+Fixed bug 976: UselessStringValueOf wrong when appending character arrays
+Fixed bug 977: MisplacedNullCheck makes false positives
+Fixed bug 984: Cyclomatic complexity should treat constructors like methods
+Fixed bug 985: Suppressed methods shouldn't affect avg CyclomaticComplexity
+Fixed bug 992: Class java.beans.Statement triggered in CloseResource rule
+Fixed bug 997: Rule NonThreadSafeSingleton gives analysis problem
+Fixed bug 999: Law of Demeter: False positives and negatives
+Fixed bug 1002: False +: FinalFieldCouldBeStatic on inner class
+Fixed bug 1005: False + for ConstructorCallsOverridableMethod - overloaded methods
+Fixed bug 1027: PMD Ant: java.lang.ClassCastException
+Fixed bug 1032: ImmutableField Rule: Private field in inner class gives false positive
+Fixed bug 1064: Exception running PrematureDeclaration
+Fixed bug 1068: CPD fails on broken symbolic links
+Fixed bug 1073: Hard coded violation messages CommentSize
+Fixed bug 1074: rule priority doesn't work on group definitions
+Fixed bug 1076: Report.treeIterator() does not return all violations
+Fixed bug 1077: Missing JavaDocs for Xref-Test Files
+Fixed bug 1078: Package statement introduces false positive UnnecessaryFullyQualifiedName violation
+Merged pull request #14: fix Nullpointer Exception when using -l jsp
+
+
+
February 3, 2013 - 5.0.2:
+
+
Fixed bug 878: False positive: UnusedFormalParameter for abstract methods
+Fixed bug 913: SignatureDeclareThrowsException is raised twice
+Fixed bug 947: CloseResource rule fails if field is marked with annotation
+Fixed bug 1004: targetjdk isn't attribute of PMD task
+Fixed bug 1007: Parse Exception with annotation
+Fixed bug 1011: CloseResource Rule ignores Constructors
+Fixed bug 1012: False positive: Useless parentheses.
+Fixed bug 1020: Parsing Error
+Fixed bug 1026: PMD doesn't handle 'value =' in SuppressWarnings annotation
+Fixed bug 1028: False-positive: Compare objects with equals for Enums
+Fixed bug 1030: CPD Java.lang.IndexOutOfBoundsException: Index:
+Fixed bug 1037: Facing a showstopper issue in PMD Report Class (report listeners)
+Fixed bug 1039: pmd-nicerhtml.xsl is packaged in wrong location
+Fixed bug 1043: node.getEndLine() always returns 0 (ECMAscript)
+Fixed bug 1044: Unknown option: -excludemarker
+Fixed bug 1046: ant task CPDTask doesn't accept ecmascript
+Fixed bug 1047: False Positive in 'for' loops for LocalVariableCouldBeFinal in 5.0.1
+Fixed bug 1048: CommentContent Rule, String Index out of range Exception
+Fixed bug 1049: Errors in "How to write a rule"
+Fixed bug 1055: Please add a colon in the ant output after line,column for Oracle JDeveloper IDE usage
+Fixed bug 1056: "Error while processing" while running on xml file with DOCTYPE reference
+Fixed bug 1060: GodClassRule >>> wrong method
+
+
+
November 28, 2012 - 5.0.1:
+
+
Fixed bug 820: False+ AvoidReassigningParameters
+Fixed bug 1008: pmd-5.0.0: ImmutableField false positive on self-inc/dec
+Fixed bug 1009: pmd-5.0.0: False + UselessParentheses
+Fixed bug 1003: newline characters stripped from CPD data in PMD 5.0.0
+Fixed bug 1001: InsufficientStringBufferDeclaration fails to parse hex
+Fixed bug 522: InefficientStringBuffering bug false +
+Fixed bug 953: String.InefficientStringBuffering false +
+Fixed bug 981: Unable to parse
+Fixed bug 1010: pmd: parsing of generic method call with super fails
+Fixed bug 996: pmd-4.2.6: MissingBreakInSwitch fails to report violation
+Fixed bug 993: Invalid NPath calculation in return statement. Thanks to Prabhjot Singh for the patch.
+Fixed bug 1023: c/c++ \ as a continuation character not supported
+Fixed bug 1033: False+ : SingularField
+Fixed bug 1025: Regression of Crash in PMDTask due to multithreading (Eclipse and Java 1.5)
+Fixed bug 1017: Type resolution very slow for big project. Thanks to Roman for the patch.
+Fixed bug 1036: Documentation: default threshold values removed from v5.0
+Fixed bug 1035: UseObjectForClearerAPI has misspelled message
+Fixed bug 1031: false DontImportJavaLang
+Fixed bug 1034: UseConcurrentHashMap flags calls to methods that return Map
+Fixed bug 1006: Problem with implementation of getPackageNameImage method
+Fixed bug 1014: AvoidLiteralsInIfCondition must NOT consider null
+Fixed bug 1013: jnlp link for CPD is wrong
+
+PMD Command Line Changes:
+ Improved command line interface (CLI) parsing using JCommander.
+ Note: this breaks compatibility, but should be easy to fix.
+ With "-d" you specify nowtThe source files / source directory to be scanned.
+ With "-f" you select the report format (like text, html, ...)
+ With "-R" you select the rulesets to be used.
+ Example: pmd -d c:\data\pmd\pmd\test-data\Unused1.java -f xml -R rulesets/java/unusedcode.xml
+
+Improved JSP parser to be less strict with not valid XML documents (like HTML). Thanks to Victor Bucutea.
+Fixed bgastviewer not working. Thanks to Victor Bucutea.
+Improved CPD: Support in CPD for IgnoreAnnotations and SuppressWarnings("CPD-START"). Thanks to Matthew Short.
+Fixed C# support for CPD - thanks to TIOBE Software.
+
+New Ecmascript rules:
+
+ Basic ruleset: AvoidTrailingComma
+
+
+
May, 1, 2012 - 5.0.0:
+
+
Fixed bug 3515487: Inconsistent reference to ruleset file in documentation
+Fixed bug 3470274: Using Label for lines in XMLRenderer
+Fixed bug 3175710: NPE in InsufficientStringBufferDeclaration
+
+CPD:
+- Exit with status code 4 when CPD detects code duplication (Patch ID: 3497021)
+
+
+
January 31, 2012 - 5.0-alpha:
+
+
This version of PMD breaks API compatibility with prior versions of PMD, as well
+as RuleSet XML compatibility. Also the maven coordinates (groupId) have been changed.
+The decision to break compatibility, allows PMD
+internals and code organization to be improved to better handle additional
+languages. This opportunity was used to remove depreciated APIs, and beat up
+any code which has thumbed its nose at the developers over the years. ;)
+
+The following is relatively complete list of the major changes (this may not be
+100% accurate, see actual source code when in doubt):
+
+Fixed bug (no number) - Fixed UseStringBufferLengthRule only worked once per class
+All StringBuffer-related rules now also catch StringBuilder-related issues in the same way
+
+ API Change - Unification of treatment of languages within PMD core:
+ Added - net.sourceforge.pmd.lang.Language (now an 'enum')
+ Added - net.sourceforge.pmd.lang.LanguageVersion
+ Added - net.sourceforge.pmd.lang.LanguageVersionDiscoverer
+ Added - net.sourceforge.pmd.lang.LanguageVersionHandler
+ Added - net.sourceforge.pmd.lang.XPathHandler
+ Added - net.sourceforge.pmd.lang.ast.xpath.AbstractASTXPathHandler
+ Added - net.sourceforge.pmd.lang.xpath.Initializer
+ Added - net.sourceforge.pmd.lang.ast.AbstractTokenManager
+ Added - net.sourceforge.pmd.lang.ast.CharStream
+ Added - net.sourceforge.pmd.lang.ast.JavaCharStream
+ Added - net.sourceforge.pmd.lang.ast.SimpleCharStream
+ Added - net.sourceforge.pmd.lang.ast.TokenMgrError
+ Added - net.sourceforge.pmd.lang.rule.stat.StatisticalRule
+ Added - net.sourceforge.pmd.lang.rule.stat.StatisticalRuleHelper
+ Added - net.sourceforge.pmd.lang.java.rule.AbstractStatisticalJavaRule
+ Added - net.sourceforge.pmd.lang.rule.AbstractRuleViolationFactory
+ Added - net.sourceforge.pmd.lang.rule.RuleViolationFactory
+ Added - net.sourceforge.pmd.lang.java.rule.JavaRuleViolationFactory
+ Added - net.sourceforge.pmd.lang.jsp.rule.JspRuleViolationFactory
+ Renamed - net.sourceforge.pmd.AbstractRule to net.sourceforge.pmd.lang.rule.AbstractRule
+ Renamed - net.sourceforge.pmd.AbstractJavaRule to net.sourceforge.pmd.lang.java.rule.AbstractJavaRule
+ Renamed - net.sourceforge.pmd.AbstractRuleChainVisitor to net.sourceforge.pmd.lang.rule.AbstractRuleChainVisitor
+ Renamed - net.sourceforge.pmd.RuleChainVisitor to net.sourceforge.pmd.lang.rule.RuleChainVisitor
+ Renamed - net.sourceforge.pmd.SourceFileSelector to net.sourceforge.pmd.lang.rule.LanguageFilenameFilter
+ Renamed - net.sourceforge.pmd.rule.XPathRule to net.sourceforge.pmd.lang.rule.XPathRule
+ Renamed - net.sourceforge.pmd.jsp.rule.AbstractJspRule to net.sourceforge.pmd.lang.jsp.rule.AbstractJspRule
+ Renamed - net.sourceforge.pmd.ast.CompilationUnit to net.sourceforge.pmd.lang.ast.RootNode
+ Renamed - net.sourceforge.pmd.ast.JavaRuleChainVisitor to net.sourceforge.pmd.lang.java.rule.JavaRuleChainVisitor
+ Renamed - net.sourceforge.pmd.jsp.ast.JspRuleChainVisitor to net.sourceforge.pmd.lang.jsp.rule.JspRuleChainVisitor
+ Renamed - net.sourceforge.pmd.parser.Parser to net.sourceforge.pmd.lang.Parser
+ Renamed - net.sourceforge.pmd.parser.TokenManager to net.sourceforge.pmd.lang.TokenManager
+ Renamed - net.sourceforge.pmd.parser.* into net.sourceforge.pmd.lang.{Language}
+ Renamed - net.sourceforge.pmd.sourcetypehandlers.SourceTypeHandler to net.sourceforge.pmd.lang.LanguageVersionHandler
+ Renamed - net.sourceforge.pmd.sourcetypehandlers.VisitorStarter to net.sourceforge.pmd.lang.VisitorStarter
+ Renamed - net.sourceforge.pmd.sourcetypehandlers.* into net.sourceforge.pmd.lang.{Language}
+ Renamed - net.sourceforge.pmd.stat.StatisticalRule to net.sourceforge.pmd.lang.rule.StatisticalRuleHelper
+ Renamed - net.sourceforge.pmd.jaxen.TypeOfFunction to net.sourceforge.pmd.lang.java.xpath.TypeOfFunction
+ Renamed - net.sourceforge.pmd.jaxen.MatchesFunction to net.sourceforge.pmd.lang.xpath.MatchesFunction
+ Renamed - net.sourceforge.pmd.jaxen.Attribute to net.sourceforge.pmd.lang.ast.xpath.Attribute
+ Renamed - net.sourceforge.pmd.jaxen.AttributeAxisIterator to net.sourceforge.pmd.lang.ast.xpath.AttributeAxisIterator
+ Renamed - net.sourceforge.pmd.jaxen.DocumentNavigator to net.sourceforge.pmd.lang.ast.xpath.DocumentNavigator
+ Renamed - net.sourceforge.pmd.jaxen.NodeIterator to net.sourceforge.pmd.lang.ast.xpath.NodeIterator
+ Renamed - net.sourceforge.pmd.ast.* into net.sourceforge.pmd.lang.java.ast.*
+ Renamed - net.sourceforge.pmd.rules.* into net.sourceforge.pmd.lang.java.rule.* and updated to follow conventions
+ Renamed - net.sourceforge.pmd.jsp.ast.* into net.sourceforge.pmd.lang.jsp.ast.*
+ Renamed - net.sourceforge.pmd.jsp.rules.* into net.sourceforge.pmd.lang.jsp.ast.rule.* and updated to follow conventions
+ Deleted - net.sourceforge.pmd.cpd.cppast.* into net.sourceforge.pmd.lang.cpp.ast.*
+ Deleted - net.sourceforge.pmd.CommonAbstractRule
+ Deleted - net.sourceforge.pmd.SourceFileConstants
+ Deleted - net.sourceforge.pmd.SourceType
+ Deleted - net.sourceforge.pmd.SourceTypeDiscoverer
+ Deleted - net.sourceforge.pmd.SourceTypeToRuleLanguageMapper
+ Deleted - net.sourceforge.pmd.TargetJDK1_3
+ Deleted - net.sourceforge.pmd.TargetJDK1_4
+ Deleted - net.sourceforge.pmd.TargetJDK1_5
+ Deleted - net.sourceforge.pmd.TargetJDK1_6
+ Deleted - net.sourceforge.pmd.TargetJDK1_7
+ Deleted - net.sourceforge.pmd.TargetJDKVersion
+ Deleted - net.sourceforge.pmd.cpd.SourceFileOrDirectoryFilter
+ Deleted - net.sourceforge.pmd.sourcetypehandlers.SourceTypeHandlerBroker
+ Deleted - net.sourceforge.pmd.ast.JavaCharStream
+ Deleted - net.sourceforge.pmd.ast.CharStream
+ Deleted - net.sourceforge.pmd.ast.TokenMgrError
+ Deleted - net.sourceforge.pmd.jsp.ast.JspCharStream
+ Deleted - net.sourceforge.pmd.jsp.ast.TokenMgrError
+
+ API Change - Generalize RuleViolation treatment
+ Renamed - net.sourceforge.pmd.IRuleViolation to net.sourceforge.pmd.RuleViolation
+ Renamed - net.sourceforge.pmd.RuleViolation to net.sourceforge.pmd.lang.rule.AbstractRuleViolation
+ Added - net.sourceforge.pmd.RuleViolationComparator
+ Added - net.sourceforge.pmd.lang.java.rule.JavaRuleViolation
+ Added - net.sourceforge.pmd.lang.jsp.rule.JspRuleViolation
+
+ API Change - Generalize DFA treatment
+ Renamed - net.sourceforge.pmd.dfa.IDataFlowNode to net.sourceforge.pmd.lang.dfa.DataFlowNode
+ Renamed - net.sourceforge.pmd.dfa.DataFlowNode to net.sourceforge.pmd.lang.dfa.AbstractDataFlowNode
+ Renamed - net.sourceforge.pmd.dfa.Linker to net.sourceforge.pmd.lang.dfa.Linker
+ Renamed - net.sourceforge.pmd.dfa.LinkerException to net.sourceforge.pmd.lang.dfa.LinkerException
+ Renamed - net.sourceforge.pmd.dfa.NodeType to net.sourceforge.pmd.lang.dfa.NodeType
+ Renamed - net.sourceforge.pmd.dfa.StackObject to net.sourceforge.pmd.lang.dfa.StackObject
+ Renamed - net.sourceforge.pmd.dfa.SequenceChecker to net.sourceforge.pmd.lang.dfa.SequenceChecker
+ Renamed - net.sourceforge.pmd.dfa.SequenceException to net.sourceforge.pmd.lang.dfa.SequenceException
+ Renamed - net.sourceforge.pmd.dfa.StartOrEndDataFlowNode to net.sourceforge.pmd.lang.dfa.StartOrEndDataFlowNode
+ Renamed - net.sourceforge.pmd.dfa.Structure to net.sourceforge.pmd.lang.dfa.Structure
+ Renamed - net.sourceforge.pmd.dfa.variableaccess.VariableAccess to net.sourceforge.pmd.lang.dfa.VariableAccess
+ Renamed - net.sourceforge.pmd.dfa.variableaccess.VariableAccessException to net.sourceforge.pmd.lang.dfa.VariableAccessException
+ Renamed - net.sourceforge.pmd.dfa.pathfinder.* to net.sourceforge.pmd.lang.dfa.pathfinder.*
+ Renamed - net.sourceforge.pmd.dfa.report.* to net.sourceforge.pmd.lang.dfa.report.*
+ Renamed - net.sourceforge.pmd.dfa.DaaRuleViolation to net.sourceforge.pmd.lang.java.dfa.DaaRuleViolation
+ Renamed - net.sourceforge.pmd.dfa.DataFlowFacade to net.sourceforge.pmd.lang.java.dfa.DataFlowFacade
+ Renamed - net.sourceforge.pmd.dfa.StatementAndBraceFinder to net.sourceforge.pmd.lang.java.dfa.StatementAndBraceFinder
+ Renamed - net.sourceforge.pmd.dfa.variableaccess.VariableAccessVisitor to net.sourceforge.pmd.lang.java.dfa.VariableAccessVisitor
+ Added - net.sourceforge.pmd.lang.java.dfa.JavaDataFlowNode
+ Added - net.sourceforge.pmd.lang.DataFlowHandler
+
+ API Change - Generalize Symbol Table treatement
+ Deleted - net.sourceforge.pmd.symboltable.JspSymbolFacade
+ Deleted - net.sourceforge.pmd.symboltable.JspScopeAndDeclarationFinder
+ Renamed - net.sourceforge.pmd.symboltable.* to net.sourceforge.pmd.lang.java.symboltable.*
+
+ API Change - Generalize Type Resolution treatment
+ Renamed - net.sourceforge.pmd.typeresolution.* to net.sourceforge.pmd.lang.java.typeresolution.*
+
+ API Change - Generalize Property Descriptor treatment
+ Renamed - net.sourceforge.pmd.properties.* to net.sourceforge.pmd.lang.rule.properties.*
+ Renamed - net.sourceforge.pmd.properties.AbstractPMDProperty to net.sourceforge.pmd.lang.rule.properties.AbstractProperty
+ Changed - net.sourceforge.pmd.properties.PropertyDescriptor to use Generics, and other changes
+ Added - net.sourceforge.pmd.lang.rule.properties.* new types and other API changes
+
+ API Change - Generalize AST treatment
+ Added - net.sourceforge.pmd.lang.ast.Node (interface extracted from old Node/SimpleNode)
+ Added - net.sourceforge.pmd.lang.ast.AbstractNode
+ Added - net.sourceforge.pmd.ast.DummyJavaNode
+ Added - net.sourceforge.pmd.jsp.ast.AbstractJspNode
+ Added - net.sourceforge.pmd.jsp.ast.JspNode
+ Renamed - net.sourceforge.pmd.ast.SimpleJavaNode to net.sourceforge.pmd.ast.AbstractJavaNode
+ Renamed - net.sourceforge.pmd.ast.SimpleJavaTypeNode to net.sourceforge.pmd.ast.AbstractJavaTypeNode
+ Renamed - net.sourceforge.pmd.ast.SimpleJavaAccessNode to net.sourceforge.pmd.ast.AbstractJavaAccessNode
+ Renamed - net.sourceforge.pmd.ast.SimpleJavaAccessTypeNode to net.sourceforge.pmd.ast.AbstractJavaAccessTypeNode
+ Deleted - net.sourceforge.pmd.ast.Node
+ Deleted - net.sourceforge.pmd.ast.SimpleNode
+ Deleted - net.sourceforge.pmd.ast.AccessNodeInterface
+ Deleted - net.sourceforge.pmd.jsp.ast.Node
+ Deleted - net.sourceforge.pmd.jsp.ast.SimpleNode
+
+ API Change - General code reorganization/cleanup
+ Renamed - net.sourceforge.pmd.AbstractDelegateRule to net.sourceforge.pmd.lang.rule.AbstractDelegateRule
+ Renamed - net.sourceforge.pmd.MockRule to net.sourceforge.pmd.lang.rule.MockRule
+ Renamed - net.sourceforge.pmd.RuleReference to net.sourceforge.pmd.lang.rule.RuleReference
+ Renamed - net.sourceforge.pmd.ScopedLogHandlersManager to net.sourceforge.pmd.util.log.ScopedLogHandlersManager
+ Renamed - net.sourceforge.pmd.util.AntLogHandler to net.sourceforge.pmd.util.log.AntLogHandler
+ Renamed - net.sourceforge.pmd.util.ConsoleLogHandler to net.sourceforge.pmd.util.log.ConsoleLogHandler
+ Renamed - net.sourceforge.pmd.util.PmdLogFormatter to net.sourceforge.pmd.util.log.PmdLogFormatter
+
+ API Change - Changes to Rule/RuleSet/RuleSets
+ Removed - boolean Rule.include()
+ Removed - void Rule.setInclude(boolean)
+ Removed - String Rule.getRulePriorityName()
+ Removed - String Rule.getExample()
+ Removed - Rule.LOWEST_PRIORITY
+ Removed - Rule.PRIORITIES
+ Removed - Properties Rule.getProperties()
+ Removed - Rule.addProperties(Properties)
+ Removed - boolean Rule.hasProperty(String)
+ Removed - RuleSet.applies(Language,Language)
+ Removed - RuleSet.getLanguage()
+ Removed - RuleSet.setLanguage(Language)
+ Removed - RuleSets.applies(Language,Language)
+ Changed - void Rule.setPriority(int) to void Rule.setPriority(RulePriority)
+ Changed - int Rule.getPriority() to void RulePriority Rule.getPriority()
+ Changed - XXX Rule.getXXXProperty(String) to <T> Rule.getProperty(PropertyDescriptor<T>)
+ Changed - XXX Rule.getXXXProperty(PropertyDescriptor) to <T> Rule.getProperty(PropertyDescriptor<T>)
+ Changed - Rule.addProperty(String, String) to Rule.setProperty(PropertyDescriptor<T>, T)
+ Changed - Rule.setProperty(PropertyDescriptor, Object) to Rule.setProperty(PropertyDescriptor<T>, T)
+ Changed - Rule.setProperty(PropertyDescriptor, Object[]) to Rule.setProperty(PropertyDescriptor<T>, T)
+ Changed - Rule.propertyValuesByDescriptor() to Rule.getPropertiesByPropertyDescriptor()
+ Changed - PropertyDescriptor Rule.propertyDescriptorFor(String) to PropertyDescriptor Rule.getPropertyDescriptor(String)
+ Changed - boolean RuleSet.usesDFA() to boolean RuleSet.usesDFA(Language)
+ Changed - boolean RuleSet.usesTypeResolution() to boolean RuleSet.usesTypeResolution(Language)
+ Added - Rule.setLanguage(Language)
+ Added - Language Rule.getLanguage()
+ Added - Rule.setMinimumLanguageVersion(LanguageVersion)
+ Added - LanguageVersion Rule.getMinimumLanguageVersion()
+ Added - Rule.setMaximumLanguageVersion(LanguageVersion)
+ Added - LanguageVersion Rule.getMaximumLanguageVersion()
+ Added - Rule.setDeprecated(boolean)
+ Added - boolean Rule.isDeprecated()
+ Added - String Rule.dysfunctionReason();
+ Added - Rule.definePropertyDescriptor(PropertyDescriptor)
+ Added - List<PropertyDescriptor> Rule.getPropertyDescriptors()
+ Added - RuleSet.applies(Rule,LanguageVersion)
+
+ API Change - Changes to PMD class
+ Renamed - PMD.EXCLUDE_MARKER to PMD.SUPPRESS_MARKER
+ Removed - PMD.processFile(InputStream, RuleSet, RuleContext)
+ Removed - PMD.processFile(InputStream, String, RuleSet, RuleContext)
+ Removed - PMD.processFile(Reader, RuleSet, RuleContext)
+ Removed - PMD.processFile(Reader, RuleSets, RuleContext, LanguageVersion)
+ Moved - PMD.getExcludeMarker() to Configuration.getSuppressMarker()
+ Moved - PMD.setExcludeMarker(String) to Configuration.getSuppressMarker(String)
+ Moved - PMD.getClassLoader() to Configuration.getClassLoader()
+ Moved - PMD.setClassLoader(ClassLoader) to Configuration.getClassLoader(ClassLoader)
+ Moved - PMD.setDefaultLanguageVersion(LanguageVersion) to Configuration.setDefaultLanguageVersion(LanguageVersion)
+ Moved - PMD.setDefaultLanguageVersions(List<LanguageVersion>) to Configuration.setDefaultLanguageVersions(List<LanguageVersion>)
+ Moved - PMD.createClasspathClassLoader(String) to Configuration.createClasspathClassLoader(String)
+
+ API Change - Changes to Node interface
+ Renamed - Node.findChildrenOfType(Class) as Node.findDescendantsOfType(Class)
+ Renamed - Node.getFirstChildOfType(Class) as Node.getFirstDescendantOfType(Class)
+ Renamed - Node.containsChildOfType(Class) as Node.hasDescendantOfType(Class)
+ Renamed - Node.getAsXml() as Node.getAsDocument()
+ Added - Node.findChildrenOfType(Class), non recursive version
+ Added - Node.getFirstChildOfType(Class), non recursive version
+
+ API Change - Remove deprecated APIs
+ Removed - AccessNode.setXXX() methods, use AccessNode.setXXX(boolean) instead.
+ Removed - PMDException.getReason()
+ Removed - RuleSetFactory.createRuleSet(String,ClassLoader), use RuleSetFactory.setClassLoader(ClassLoader) and RuleSetFactory.createRuleSets(String) instead.
+ Removed - net.sourceforge.pmd.cpd.FileFinder use net.sourceforge.pmd.util.FileFinder instead.
+
+ API Change - RuleSetFactory
+ Added - RuleSetFactory.setClassLoader(ClassLoader)
+ Added - RuleSetFactory.createRuleSets(List<RuleSetReferenceId>)
+ Added - RuleSetFactory.createRuleSet(RuleSetReferenceId)
+ Added - RuleSetFactory.setClassLoader(ClassLoader)
+ Added - RuleSetReferenceId class to handle parsing of RuleSet strings, see RuleSetReferenceId.parse(String)
+ Renamed - RuleSetFactory.createSingleRuleSet(String) to RuleSetFactory.createRuleSet(String);
+ Removed - RuleSetFactory.createRuleSets(String, ClassLoader), use RuleSetFactory.createRuleSets(String) instead.
+ Removed - RuleSetFactory.createSingleRuleSet(String, ClassLoader), use RuleSetFactory.createSingleRuleSet(String) instead.
+ Removed - RuleSetFactory.createRuleSet(InputStream, ClassLoader), use RuleSetFactory.createRuleSet(RuleSetReferenceId) instead.
+ Removed - ExternalRuleID, use RuleSetReferenceId instead
+ Removed - SimpleRuleSetNameMapper, use RuleSetReferenceId instead
+
+ API Change - Changes to Renderer class, and Renderer implementations
+ Added - Renderer.getName()
+ Added - Renderer.setName(String)
+ Added - Renderer.getDescription()
+ Added - Renderer.setDescription(String)
+ Added - Renderer.getPropertyDefinitions()
+ Added - Renderer.isShowSuppressedViolations()
+ Added - AbstractAccumulatingRenderer
+ Removed - Renderer.render(Report)
+ Removed - Renderer.render(Report, Writer)
+ Renamed - Renderer.showSuppressedViolations(boolean) to Renderer.setShowSuppressedViolations(boolean)
+ Renamed - PapariTextRenderer to TextColorRenderer
+ Renamed - OntheFlyRenderer to AbstractIncrementingRenderer
+
+PMD command line changes:
+
+ Removed -lineprefix use -property linePrefix {value} instead
+ Removed -linkprefix use -property linkPrefix {value} instead
+ Removed -xslt use -property xsltFilename {value} instead
+ Removed -nojsp now obsolete
+ Removed -targetjdk use -version {name} {version} instead
+ Added -version {name} {version} to set language version to use for a given language
+ Added -property {name} {value} as generic way to pass properties to Renderers
+ Added -showsuppressed as a means to show suppressed rule violations (consistent with Ant task behavior)
+ Renamed 'nicehtml' report to 'xslt'
+ Renamed 'papari' report to 'textcolor'
+ Renamed -excludemarker option to -suppressmarker
+ Renamed -cpus option to -threads
+
+Ant changes:
+
+ Removed - <formatter> 'linkPrefix' attribute, use <param name="linkPrefix"> instead
+ Removed - <formatter> 'linePrefix' attribute, use <param name="linePrefix"> instead
+ Changed - <formatter> is optional - if not specified, falls back to "text" and console output.
+ Removed - <pmd> 'targetJDK' attribute to <version>lang version</version> instead
+ Added - <param name="name" value="value"/> as generic way to pass properties to Renderers on <formatter>
+ Renamed - <pmd> 'excludeMarker' attribute to 'suppressMarker'
+ Renamed - <pmd> 'cpus' attribute to 'threads'
+
+Maven changes:
+ The new maven coordinates are: net.sourceforge.pmd:pmd, e.g.
+ <dependency>
+ <groupId>net.sourceforge.pmd</groupId>
+ <artifactId>pmd</artifactId>
+ <version>5.0</version>
+ </dependency>
+
+New features:
+
+New Language 'ecmascript' added, for writing XPathRule and Java Rules against ECMAScript/JavaScript documents (must be standalone, not embedded in HTML). Many thanks to Rhino!
+New Language 'xml' added, for writing XPathRules against XML documents
+New Language 'xsl' added, as a derivative from XML.
+Rules can now define a 'violationSuppressRegex' property to universally suppress violations with messages matching the given regular expression
+Rules can now define a 'violationSuppressXPath' property to universally suppress violations on nodes which match the given relative XPath expression
+Rules are now directly associated with a corresponding Language, and a can also be associated with a specific Language Version range if desired.
+Rules can now be flagged with deprecated='true' in the RuleSet XML to allow the PMD Project to indicate a Rule (1) is scheduled for removal, (2) has been removed, or (3) has been renamed/moved.
+XPathRules can now query using XPath 2.0 with 'version=2.0"', or XPath 2.0 in XPath 1.0 compatibility mode using 'version="1.0 compatibility"'. Many thanks to Saxon!
+Rules can now use property values in messages, for example ${propertyName} will expand to the value of the 'propertyName' property on the Rule.
+Rules can now use violation specific values in messages, specifically ${variableName}, ${methodName}, ${className}, ${packageName}.
+New XPath function 'getCommentOn' can be used to search for strings in comments - Thanks to Andy Throgmorton
+
+CPD:
+Add .hxx and .hpp as valid file extension for CPD - Thanks to Ryan Pavlik
+Add options to to the CPD command line task - Thanks to Cd-Man
+Add C# support for CPD - thanks to Florian Bauer
+Fix small bug in Rule Designer UI
+Performance enhacement when parsing Javadoc (Patch ID: 3217201), thanks to Cd-Man
+Rework the XMLRenderer to use proper XML API and strictly uses the system value for encoding (Fix bug: 1435751)
+
+Other changes:
+Rule property API upgrades:
+ All numeric property descriptors can specify upper & lower limits
+ Newly functional Method & Type descriptors allow rule developers to incorporate/watch for individual methods or types
+ Better initialization error detection
+ Deprecated old string-keyed property API, will leave some methods behind for XPath rules however
+'41' and '42' shortcuts for rulesets added
+The default Java version processed by PMD is now uniformly Java 1.5.
+RuleViolations in Reports now uses List internally, and RuleViolationComparator is no longer broken
+TokenManager errors now include a file name whenever possible for every AST in PMD
+Added file encoding option to CPD GUI, which already existed for the command line and Ant
+AssignmentInOperand enhanced to catch assignment in 'for' condition, as well as use of increment/decrement operators. Customization properties added to allow assignment in if/while/for, or use of increment/decrement.
+Fix false positive on CastExpressions for UselessParentheses
+Fix false positive where StringBuffer.setLength(0) was using default constructor size of 16, instead of actual constructor size.
+Fix false negative for non-primitive types for VariableNamingConventions, also expanded scope to local and method/constructors, and enhanced customization options to choose between members/locals/parameters (all checked by default)
+Fix false negative for UseArraysAsList when the array was passed as method parameter - thanks to Andy Throgmorton
+Improve TooManyMethods rule - thanks to a patch from Riku Nykanen
+Improve DoNotCallSystemExit - thanks to a patch from Steven Christou
+Correct -benchmark reporting of Rule visits via the RuleChain
+Creating an Empty Code Ruleset and moved the following rules from Basic ruleset:
+ * Empty Code Rules
+ * EmptyCatchBlock
+ * EmptyIfStmt
+ * EmptyWhileStmt
+ * EmptyTryBlock
+ * EmptyFinallyBlock
+ * EmptySwitchStatements
+ * EmptySynchronizedBlock
+ * EmptyStatementNotInLoop
+ * EmptyInitializer
+ * EmptyStatementBlock
+ * EmptyStaticInitializer
+ Basic rulesets still includes a reference to those rules.
+Creating a unnecessary Code Ruleset and moved the following rules from Basic ruleset:
+ * UnnecessaryConversionTemporary
+ * UnnecessaryReturn
+ * UnnecessaryFinalModifier
+ * UselessOverridingMethod
+ * UselessOperationOnImmutable
+ * UnusedNullCheckInEquals
+ * UselessParentheses
+ Basic rulesets still includes a reference to those rules.
+
+Fixed bug 2920057 - Fixed False + on CloseResource
+Fixed bug 1808110 - Fixed performance issues on PreserveStackTrace
+Fixed bug 2832322 - cpd.xml file tag path attribute should be entity-encoded
+Fixed bug 2826119 - False +: DoubleCheckedLocking warning with volatile field
+Fixed bug 2835074 - False -: DoubleCheckedLocking with reversed null check
+Fixed bug 1932242 - EmptyMethodInAbstractClassShouldBeAbstract false +
+Fixed bug 1928009 - Error using migration ruleset in PMD 4.2
+Fixed bug 1808110 - PreserveStackTrace
+Fixed bug 1988829 - Violation reported without source file name (actually a fix to ConsecutiveLiteralAppends)
+Fixed bug 1989814 - false +: ConsecutiveLiteralAppends
+Fixed bug 1977230 - false positive: UselessOverridingMethod
+Fixed bug 1998185 - BeanMembersShouldSerialize vs @SuppressWarnings("serial")
+Fixed bug 2002722 - false + in UseStringBufferForStringAppends
+Fixed bug 2056318 - False positive for AvoidInstantiatingObjectsInLoops
+Fixed bug 1977438 - False positive for UselessStringValueOf
+Fixed bug 2050064 - False + SuspiciousOctalEscape with backslash literal
+Fixed bug 1556594 - Wonky detection of NullAssignment
+Fixed bug 1481051 - false + UnusedNullCheckInEquals (and other false positives too)
+Fixed bug 1943204 - Ant task: <ruleset> path should be relative to Ant basedir
+Fixed patch 2075906 - Add toString() to the rule UnnecessaryWrapperObjectCreation
+Fixed bug 2315623 - @SuppressWarnings("PMD.UseSingleton") has no effect
+Fixed bug 2230809 - False +: ClassWithOnlyPrivateConstructorsShouldBeFinal
+Fixed bug 2338341 - ArrayIndexOutOfBoundsException in CPD (on Ruby)
+Fixed bug 2315599 - False +: UseSingleton with class containing constructor
+Fixed bug 1955852 - false positives for UnusedPrivateMethod & UnusedLocalVariable
+Fixed bug 2404700 - UseSingleton should not act on enums
+Fixed bug - JUnitTestsShouldIncludeAssert now detects Junit 4 Assert.assert... constructs
+Fixed bug 1609038 - Xslt report generators break if path contains "java"
+Fixed bug 2142986 - UselessOverridingMethod doesn't consider annotations
+Fixed bug 2027626 - False + : AvoidFinalLocalVariable
+Fixed bug 2606609 - False "UnusedImports" positive in package-info.java
+Fixed bug 2645268 - ClassCastException in UselessOperationOnImmutable.getDeclaration
+Fixed bug 2724653 - AvoidThreadGroup reports false positives
+Fixed bug 2904832 - Type resolution not working for ASTType when using an inner class
+Fixed bug 1435751 - XML format does not support UTF-8
+Fixed bug 3303811 - Deadlink on "Similar projects" page
+Fixed bug 3017616 - Updated documentation regarding Netbeans plugin - thanks to Jesse Glick
+Fixed bug 3427563 - Deprecated class (android.util.config) - thanks to Lukas Reschke for the patch
+
+ruleset.dtd and ruleset_xml_schema.xsd added to jar file in rulesets directory
+bin and java14/bin scripts:
+ retroweaver version was not correct in java14/bin scripts
+ support for extra languages in cpd.sh
+ standard unix scripts can be used with cygwin
+Upgrading UselessOperationOnImmutable to detect more use cases, especially on String and fix false positives
+AvoidDuplicateLiteralRule now has 'skipAnnotations' boolean property
+Fixed false positive in UnusedImports: javadoc comments are parsed to check @see and other tags
+Fixed parsing bug: constant fields in annotation classes
+Bug fix: NPE in MoreThanOneLogger
+UnnecessaryParentheses now checks all expressions, not just return statements
+UnusedFormalParameter now reports violations on the parameter node, not the method/constructor node
+Updates to RuleChain to honor RuleSet exclude-pattern
+Optimizations and false positive fixes in PreserveStackTrace
+@SuppressWarnings("all") disables all warnings
+SingularField now checks for multiple fields in the same declaration
+Java grammar enhanced to include AnnotationMethodDeclaration as parent node of method related children of AnnotationTypeMemberDeclaration
+JavaCC generated artifacts updated to JavaCC 4.1.
+Dependencies updates: asm updated to 3.2
+Ant requirement is now 1.7.0 or higher for compilation
+ JUnit testing jar is packaged on 1.7.0+ only in ant binary distributions
+ Note that the ant task still works with 1.6.0 and higher
+All comment types are now stored in ASTCompilationUnit, not just formal ones
+Fixed false negative in UselessOverridingMethod
+Fixed handling of escape characters in UseIndexOfChar and AppendCharacterWithChar
+Fixed ClassCastException on generic method in BeanMembersShouldSerialize
+Fixed ClassCastException in symbol table code
+Support for Java 1.4 runtime dropped, PMD now requires Java 5 or higher. PMD can still process Java 1.4 source files.
+Support for Java 1.7
+Text renderer is now silent if there's no violation instead of displaying "No problems found!"
+RuleSet short names now require a language prefix, 'basic' is now 'java-basic', and 'rulesets/basic.xml' is now 'rulesets/java/basic.xml'
+The JSP RuleSets are now in the 'jsp' language, and are 'jsp-basic', 'jsp-basic-jsf', 'rulesets/jsp/basic.xml' and 'rulesets/jsp/basic-jsp.xml'
+Enhanced logging in the ClassTypeResolver to provide more detailed messaging.
+AvoidUsingHardCodedIP modified to not use InetAddress.getByName(String), instead does better pattern analysis.
+The JSP/JSF parser can now parse Unicode input.
+The JSP/JSP parser can now handle <script>...</script> tags. The AST HtmlScript node contains the content.
+Added Ecmascript as a supported language for CPD.
+The RuleSet XML Schema namespace is now: http://pmd.sourceforge.net/ruleset/2.0.0
+The RuleSet XML Schema is located in the source at: etc/ruleset_2_0_0.xsd
+The RuleSet DTD is located in the source at: etc/ruleset_2_0_0.dtd
+Improved include/exclude pattern matching performance for ends-with type patterns.
+Modify (and hopefully fixed) CPD algorithm thanks to a patch from Juan Jesús García de Soria.
+Fixed character reference in xml report - thanks to Seko
+Enhanced SuspiciousEqualsMethodName rule - thanks to Andy Throgmorton
+Add a script to launch CPDGUI on Unix system - thanks to Tom Wheeler
+
+New Java rules:
+
+ Basic ruleset: ExtendsObject,CheckSkipResult,AvoidBranchingStatementAsLastInLoop,DontCallThreadRun,DontUseFloatTypeForLoopIndices
+ Controversial ruleset: AvoidLiteralsInIfCondition, AvoidPrefixingMethodParameters, OneDeclarationPerLine, UseConcurrentHashMap
+ Coupling ruleset: LoosePackageCoupling,LawofDemeter
+ Design ruleset: LogicInversion,UseVarargs,FieldDeclarationsShouldBeAtStartOfClass,GodClass
+ Empty ruleset: EmptyInitializer,EmptyStatementBlock
+ Import ruleset: UnnecessaryFullyQualifiedName
+ Optimization ruleset: RedundantFieldInitializer
+ Naming ruleset: ShortClassName, GenericsNaming
+ StrictException ruleset: AvoidThrowingNewInstanceOfSameException, AvoidCatchingGenericException, AvoidLosingExceptionInformation
+ Unnecessary ruleset: UselessParentheses
+ JUnit ruleset: JUnitTestContainsTooManyAsserts, UseAssertTrueInsteadOfAssertEquals
+ Logging with Jakarta Commons ruleset: GuardDebugLogging
+
+New Java ruleset:
+ android.xml: new rules specific to the Android platform
+
+New JSP rules:
+ Basic ruleset: NoInlineScript
+
+New ECMAScript rules:
+ Basic ruleset: AssignmentInOperand,ConsistentReturn,InnaccurateNumericLiteral,ScopeForInVariable,UnreachableCode,EqualComparison,GlobalVariable
+ Braces ruleset: ForLoopsMustUseBraces,IfStmtsMustUseBraces,IfElseStmtsMustUseBraces,WhileLoopsMustUseBraces
+ Unnecessary ruleset: UnnecessaryParentheses,UnnecessaryBlock
+
+New XML rules:
+ Basic ruleset: MistypedCDATASection
+
+
+
November 4, 2011 - 4.3:
+
+
Add support for Java 7 grammer - thanks to Dinesh Bolkensteyn and SonarSource
+Add options --ignore-literals and --ignore-identifiers to the CPD command line task, thanks to Cd-Man
+Fixed character reference in xml report - thanks to Seko
+Add C# support for CPD - thanks to Florian Bauer
+Fix small bug in Rule Designer UI
+Improve TooManyMethods rule - thanks to a patch from Riku Nykanen
+Improve DoNotCallSystemExit - thanks to a patch from Steven Christou
+Fix false negative for UseArraysAsList when the array was passed as method parameter - thanks to Andy Throgmorton
+Enhanced SuspiciousEqualsMethodName rule - thanks to Andy Throgmorton
+Add a script to launch CPDGUI on Unix system - thanks to Tom Wheeler
+
+New Rule:
+ Basic ruleset: DontCallThreadRun - thanks to Andy Throgmorton
+ Logging with Jakarta Commons ruleset: GuardDebugLogging
+
+
+
September 14, 2011 - 4.2.6:
+
+
Fixed bug 2920057 - False + : CloseRessource whith an external getter
+Fixed bug 1808110 - Fixed performance issue on PreserveStackTrace
+Fixed bug 2832322 - cpd.xml file tag path attribute should be entity-encoded
+Fixed bug 2590258 - NPE with nicerhtml output
+Fixed bug 2317099 - False + in SimplifyCondition
+Fixed bug 2606609 - False "UnusedImports" positive in package-info.java
+Fixed bug 2645268 - ClassCastException in UselessOperationOnImmutable.getDeclaration
+Fixed bug 2724653 - AvoidThreadGroup reports false positives
+Fixed bug 2835074 - False -: DoubleCheckedLocking with reversed null check
+Fixed bug 2826119 - False +: DoubleCheckedLocking warning with volatile field
+Fixed bug 2904832 - Type resolution not working for ASTType when using an inner class
+
+Modify (and hopefully fixed) CPD algorithm thanks to a patch from Juan Jesús García de Soria.
+Correct -benchmark reporting of Rule visits via the RuleChain
+Fix issue with Type Resolution incorrectly handling of Classes with same name as a java.lang Class.
+The JSP/JSF parser can now parse Unicode input.
+The JSP/JSP parser can now handle <script>...</script> tags. The AST HtmlScript node contains the content.
+Added Ecmascript as a supported language for CPD.
+Improved include/exclude pattern matching performance for ends-with type patterns.
+
+Dependencies updates: asm updated to 3.2
+
+Android ruleset: CallSuperLast rule now also checks for finish() redefinitions
+
+New rule:
+ Android: DoNotHardCodeSDCard
+ Controversial : AvoidLiteralsInIfCondition (patch 2591627), UseConcurrentHashMap
+ StrictExceptions : AvoidCatchingGenericException, AvoidLosingExceptionInformation
+ Naming : GenericsNaming
+ JSP: NoInlineScript
+
+
+
February 08, 2009 - 4.2.5:
+
+
Enhanced logging in the ClassTypeResolver to provide more detailed messaging.
+Fixed bug 2315623 - @SuppressWarnings("PMD.UseSingleton") has no effect
+Fixed bug 2230809 - False +: ClassWithOnlyPrivateConstructorsShouldBeFinal
+Fixed bug 2338341 - ArrayIndexOutOfBoundsException in CPD (on Ruby)
+Fixed bug 2315599 - False +: UseSingleton with class containing constructor
+Fixed bug 1955852 - false positives for UnusedPrivateMethod & UnusedLocalVariable
+Fixed bug 2404700 - UseSingleton should not act on enums
+Fixed bug 2225474 - VariableNamingConventions does not work with nonprimitives
+Fixed bug 1609038 - Xslt report generators break if path contains "java"
+Fixed bug - JUnitTestsShouldIncludeAssert now detects Junit 4 Assert.assert... constructs
+Fixed bug 2142986 - UselessOverridingMethod doesn't consider annotations
+Fixed bug 2027626 - False + : AvoidFinalLocalVariable
+
+New rule:
+ StrictExceptions : AvoidThrowingNewInstanceOfSameException
+New ruleset:
+ android.xml: new rules specific to the Android platform
+
+
+
October 12, 2008 - 4.2.4:
+
+
Fixed bug 1481051 - false + UnusedNullCheckInEquals (and other false positives too)
+Fixed bug 1943204 - Ant task: <ruleset> path should be relative to Ant basedir
+Fixed bug 2139720 - Exception in PMD Rule Designer for inline comments in source
+Fixed patch 2075906 - Add toString() to the rule UnnecessaryWrapperObjectCreation
+Fixed ClassCastException on generic method in BeanMembersShouldSerialize
+Fixed ClassCastException in symbol table code
+
+
+
August 31, 2008 - 4.2.3:
+
+
JavaCC generated artifacts updated to JavaCC 4.1d1.
+Java grammar enhanced to include AnnotationMethodDeclaration as parent node of method related children of AnnotationTypeMemberDeclaration
+Fixes for exclude-pattern
+Updates to RuleChain to honor RuleSet exclude-pattern
+Upgrading UselessOperationOnImmutable to detect more use cases, especially on String and fix false positives
+Fixed bug 1988829 - Violation reported without source file name (actually a fix to ConsecutiveLiteralAppends)
+Fixed bug 1989814 - false +: ConsecutiveLiteralAppends
+Fixed bug 1977230 - false positive: UselessOverridingMethod
+Fixed bug 1998185 - BeanMembersShouldSerialize vs @SuppressWarnings("serial")
+Fixed bug 2002722 - false + in UseStringBufferForStringAppends
+Fixed bug 2056318 - False positive for AvoidInstantiatingObjectsInLoops
+Fixed bug 1977438 - False positive for UselessStringValueOf
+Fixed bug 2050064 - False + SuspiciousOctalEscape with backslash literal
+Fixed bug 1556594 - Wonky detection of NullAssignment
+Optimizations and false positive fixes in PreserveStackTrace
+@SuppressWarnings("all") disables all warnings
+All comment types are now stored in ASTCompilationUnit, not just formal ones
+Fixed false negative in UselessOverridingMethod
+Fixed handling of escape characters in UseIndexOfChar and AppendCharacterWithChar
+
+New rule:
+ Basic ruleset: EmptyInitializer
+
+
+
May 20, 2008 - 4.2.2:
+
+
Fixed false positive in UnusedImports: javadoc comments are parsed to check @see and other tags
+Fixed parsing bug: constant fields in annotation classes
+Bug fix: NPE in MoreThanOneLogger
+UnnecessaryParentheses now checks all expressions, not just return statements
+
+
+
April 11, 2008 - 4.2.1:
+
+
'41' and '42' shortcuts for rulesets added
+Fixed bug 1928009 - Error using migration ruleset in PMD 4.2
+Fixed bug 1932242 - EmptyMethodInAbstractClassShouldBeAbstract false +
+Fixed bug 1808110 - PreserveStackTrace
+
+AvoidDuplicateLiteralRule now has 'skipAnnotations' boolean property
+ruleset.dtd and ruleset_xml_schema.xsd added to jar file in rulesets directory
+Update RuleSetWriter to handle non-Apache TRAX implementations, add an option to not use XML Namespaces
+Added file encoding option to CPD GUI, which already existed for the command line and Ant
+bin and java14/bin scripts:
+ retroweaver version was not correct in java14/bin scripts
+ support for extra languages in cpd.sh
+ standard unix scripts can be used with cygwin
+
+
+
March 25, 2008 - 4.2:
+
+
Fixed bug 1920155 - CheckResultSet: Does not pass for loop conditionals
+
+
+
March 21, 2008 - 4.2rc2:
+
+
Fixed bug 1912831 - False + UnusedPrivateMethod with varargs
+Fixed bug 1913536 - Rule Designer does not recognize JSP(XML)
+Add -auxclasspath option for specifying Type Resolution classpath from command line and auxclasspath nested element for ant task.
+Fixed formatting problems in loggers.
+
+Ant task upgrade:
+ Added a new attribute 'maxRuleCount' to indicate whether or not to fail the build if PMD finds that much violations.
+
+
+
March 07, 2008 - 4.2rc1:
+
+
Fixed bug 1866198 - PMD should not register global Logger
+Fixed bug 1843273 - False - on SimplifyBooleanReturns
+Fixed bug 1848888 - Fixed false positive in UseEqualsToCompareStrings
+Fixed bug 1874313 - Documentation bugs
+Fixed bug 1855409 - False + in EmptyMethodInAbstractClassShouldBeAbstract
+Fixed bug 1888967 - Updated xpath query to detect more "empty" methods.
+Fixed bug 1891399 - Check for JUnit4 test method fails
+Fixed bug 1894821 - False - for Test Class without Test Cases
+Fixed bug 1882457 - PositionLiteralsFirstInComparisons rule not working OK
+Fixed bug 1842505 - XML output incorrect for inner classes
+Fixed bug 1808158 - Constructor args could also be final
+Fixed bug 1902351 - AvoidReassigningParameters not identify parent field
+Fixed other false positives in EmptyMethodInAbstractClassShouldBeAbstract
+Fixed other issues in SimplifyBooleanReturns
+Modified AvoidReassigningParameter to also check constructor arguments for reassignement
+
+New rules:
+ Basic ruleset: AvoidMultipleUnaryOperators
+ Controversial ruleset: DoNotCallGarbageCollectionExplicitly,UseObjectForClearerAPI
+ Design ruleset : ReturnEmptyArrayRatherThanNull,TooFewBranchesForASwitchStatement,AbstractClassWithoutAnyMethod
+ Codesize : TooManyMethods
+ StrictExceptions : DoNotThrowExceptionInFinally
+ Strings : AvoidStringBufferField
+
+Rule upgrade:
+ CyclomaticComplexity now can be configured to display only class average complexity or method complexity, or both.
+
+Designer upgrade:
+ A new panel for symbols and a tooltips on AST node that displays line, column and access node attributes (private,
+ static, abstract,...)
+
+1.7 added as a valid option for targetjdk.
+New elements under <ruleset>: <exclude-pattern> to match files exclude from processing, with <include-pattern> to override.
+Rules can now be written which produce violations based upon aggregate file processing (i.e. cross/multiple file violations).
+PMD Rule Designer can now shows Symbol Table contents for the selected AST node.
+PMD Rule Designer shows position info in tooltip for AST nodes and highlights matching code for selected AST node in code window.
+CPD Ant task will report to System.out when 'outputFile' not given.
+RuleSetWriter class can be used to Serialize a RuleSet to XML in a standard fashion. Recommend PMD IDE plugins standardize their behavior.
+retroweaver updated to version 2.0.5.
+
+
+
November 17, 2007 - 4.1:
+
+
Fixed annotation bug: ClassCastException when a formal parameter had multiple annotations
+Added a Visual Studio renderer for CPD; just use "--format vs".
+Dependencies updates: asm to 3.1, retroweaver to 2.0.2, junit to 4.4
+new ant target ("regress") to test regression bugs only
+
+
+
November 01, 2007 - 4.1rc1:
+
+
New rules:
+ Basic ruleset: AvoidUsingHardCodedIP,CheckResultSet
+ Controversial ruleset: AvoidFinalLocalVariable,AvoidUsingShortType,AvoidUsingVolatile,AvoidUsingNativeCode,AvoidAccessibilityAlteration
+ Design ruleset: ClassWithOnlyPrivateConstructorsShouldBeFinal,EmptyMethodInAbstractClassShouldBeAbstract
+ Imports ruleset: TooManyStaticImports
+ J2ee ruleset: DoNotCallSystemExit, StaticEJBFieldShouldBeFinal,DoNotUseThreads
+ Strings ruleset: UseEqualsToCompareStrings
+
+Fixed bug 674394 - fixed false positive in DuplicateImports for disambiguation import
+Fixed bug 631681 - fixed false positive in UnusedPrivateField when field is accessed by outer class
+Fixed bug 985989 - fixed false negative in ConstructorCallsOverridableMethod for inner static classes
+Fixed bug 1409944 - fixed false positive in SingularField for lock objects
+Fixed bug 1472195 - fixed false positives in PositionLiteralsFirstInComparisons when the string is used as a parameter
+Fixed bug 1522517 - fixed false positive in UselessOverridingMethod for clone method
+Fixed bug 1744065 - fixed false positive in BooleanInstantiation when a custom Boolean is used
+Fixed bug 1765613 - fixed NullPointerException in CloneMethodMustImplementCloneable when checking enum
+Fixed bug 1740480 - fixed false positive in ImmutableField when the assignment is inside an 'if'
+Fixed bug 1702782 - fixed false positive in UselessOperationOnImmutable when an Immutable on which an operation is performed is compareTo'd
+Fixed bugs 1764288/1744069/1744071 - When using Type Resolution all junit test cases will notice if you're using an extended TestCase
+Fixed bug 1793215 - pmd-nicerhtml.xsl does not display line numbers
+Fixes bug 1796928 - fixed false positive in AvoidThrowingRawExceptionTypes, when a Type name is the same as a RawException.
+Fixed bug 1811506 - False - : UnusedFormalParameter (property "checkall" needs to be set)
+Fixed false negative in UnnecessaryCaseChange
+
+The Java 1.5 source code parser is now the default for testcode used in PMD's unit tests.
+Added TypeResolution to the XPath rule. Use typeof function to determine if a node is of a particular type
+Adding a GenericLiteralChecker, a generic rule that require a regex as property. It will log a violation if a Literal is matched by the regex. See the new rule AvoidUsingHardCodedIP for an example.
+Adding support for multiple line span String in CPD's AbstractTokenizer, this may change, for the better, CPD's Ruby parsing.
+This release adds 'nicehtml', with the plan for the next major release to make nicehtml->html, and html->oldhtml. This feature uses an XSLT transformation, default stylesheet maybe override with '-xslt filename'.
+New CPD command line feature : Using more than one directory for sources. You can now have several '--files' on the command line.
+SingularField greatly improved to generate very few false positives (none?). Moved from controversial to design. Two options added to restore old behaviour (mostly).
+Jaxen updated to 1.1.1, now Literal[@Image='""'] works in XPath expressions.
+
+
+
July 20, 2007 - 4.0
+
+
Fixed bug 1697397 - fixed false positives in ClassCastExceptionWithToArray
+Fixed bug 1728789 - removed redundant rule AvoidNonConstructorMethodsWithClassName; MethodWithSameNameAsEnclosingClass is faster and does the same thing.
+
+
+
July 12, 2007 - 4.0rc2:
+
+
New rules:
+ Typeresolution ruleset: SignatureDeclareThrowsException - re-implementation using the new Type Resolution facility (old rule is still available)
+Fixed bug 1698550 - CloneMethodMustImplementCloneable now accepts a clone method that throws CloneNotSupportedException in a final class
+Fixed bug 1680568 - The new typeresolution SignatureDeclareThrowsException rule now ignores setUp and tearDown in JUnit 4 tests and tests that do not directly extend TestCase
+The new typeresolution SignatureDeclareThrowsException rule can now ignore JUnit classes completely by setting the IgnoreJUnitCompletely property
+Fixed false positive in UselessOperationOnImmutable
+PMD now defaults to using a Java 1.5 source code parser.
+
+
+
June 22, 2007 - 4.0rc1:
+
+
New rules:
+ Strict exception ruleset: DoNotExtendJavaLangError
+ Basic JSP ruleset: JspEncoding
+ J2EE ruleset: MDBAndSessionBeanNamingConvention, RemoteSessionInterfaceNamingConvention, LocalInterfaceSessionNamingConvention, LocalHomeNamingConvention, RemoteInterfaceNamingConvention
+ Optimizations ruleset: AddEmptyString
+ Naming: BooleanGetMethodName
+New rulesets:
+ Migrating To JUnit4: Rules that help move from JUnit 3 to JUnit 4
+Fixed bug 1670717 - 'Copy xml to clipboard' menu command now works again in the Designer
+Fixed bug 1618858 - PMD no longer raises an exception on XPath like '//ConditionalExpression//ConditionalExpression'
+Fixed bug 1626232 - Commons logging rules (ProperLogger and UseCorrectExceptionLogging) now catch more cases
+Fixed bugs 1626201 & 1633683 - BrokenNullCheck now catches more cases
+Fixed bug 1626715 - UseAssertSameInsteadOfAssertTrue now correctly checks classes which contain the null constant
+Fixed bug 1531216 - ImmutableField. NameOccurrence.isSelfAssignment now recognizes this.x++ as a self assignment
+Fixed bug 1634078 - StringToString now recognizes toString on a String Array, rather than an element.
+Fixed bug 1631646 - UselessOperationOnImmutable doesn't throw on variable.method().variable.
+Fixed bug 1627830 - UseLocaleWithCaseConversions now works with compound string operations
+Fixed bug 1613807 - DontImportJavaLang rule allows import to Thread inner classes
+Fixed bug 1637573 - The PMD Ant task no longer closes System.out if toConsole is set
+Fixed bug 1451251 - A new UnusedImports rule, using typeresolution, finds unused import on demand rules
+Fixed bug 1613793 - MissingSerialVersionUID rule now doesn't fire on abstract classes
+Fixed bug 1666646 - ImmutableField rule doesn't report against volatile variables
+Fixed bug 1693924 - Type resolution now works for implicit imports
+Fixed bug 1705716 - Annotation declarations now trigger a new scope level in the symbol table.
+Fixed bug 1743938 - False +: InsufficientStringBufferDeclaration with multiply
+Fixed bug 1657957 - UseStringBufferForStringAppends now catches self-assignments
+Applied patch 1612455 - RFE 1411022 CompareObjectsWithEquals now catches the case where comparison is against new Object
+Implemented RFE 1562230 - Added migration rule to check for instantiation of Short/Byte/Long
+Implemented RFE 1627581 - SuppressWarnings("unused") now suppresses all warnings in unusedcode.xml
+XPath rules are now chained together for an extra speedup in processing
+PMD now requires JDK 1.5 to be compiled. Java 1.4 support is provided using Retroweaver
+- PMD will still analyze code from earlier JDKs
+- to run pmd with 1.4, use the files from the java14 directory (weaved pmd jar and support files)
+TypeResolution now looks at some ASTName nodes.
+Memory footprint reduced: most renderers now use less memory by generating reports on the fly.
+Ant task now takes advantage of multithreading code and on the fly renderers
+Ant task now logs more debug info when using -verbose
+PMD command line now has -benchmark: output a benchmark report upon completion; default to System.err
+
+
+
December 19, 2006 - 3.9:
+
+
New rules:
+ Basic ruleset: BigIntegerInstantiation, AvoidUsingOctalValues
+ Codesize ruleset: NPathComplexity, NcssTypeCount, NcssMethodCount, NcssConstructorCount
+ Design ruleset: UseCollectionIsEmpty
+ Strings ruleset: StringBufferInstantiationWithChar
+ Typeresolution ruleset: Loose Coupling - This is a re-implementation using the new Type Resolution facility
+Fixed bug 1610730 - MisplacedNullCheck now catches more cases
+Fixed bug 1570915 - AvoidRethrowingException no longer reports a false positive for certain nested exceptions.
+Fixed bug 1571324 - UselessStringValueOf no longer reports a false positive for additive expressions.
+Fixed bug 1573795 - PreserveStackTrace doesn't throw CastClassException on exception with 0 args
+Fixed bug 1573591 - NonThreadSafeSingleton doesn't throw NPE when using this keyword
+Fixed bug 1371753 - UnnecessaryLocalBeforeReturn is now less aggressive in its reporting.
+Fixed bug 1566547 - Annotations with an empty MemberValueArrayInitializer are now parsed properly.
+Fixed bugs 1060761 / 1433119 & RFE 1196954 - CloseResource now takes an optional parameter to identify closure methods
+Fixed bug 1579615 - OverrideBothEqualsAndHashcode no longer throws an Exception on equals methods that don't have Object as a parameter type.
+Fixed bug 1580859 - AvoidDecimalLiteralsInBigDecimalConstructor now catches more cases.
+Fixed bug 1581123 - False +: UnnecessaryWrapperObjectCreation.
+Fixed bug 1592710 - VariableNamingConventions no longer reports false positives on certain enum declarations.
+Fixed bug 1593292 - The CPD GUI now works with the 'by extension' option selected.
+Fixed bug 1560944 - CPD now skips symlinks.
+Fixed bug 1570824 - HTML reports generated on Windows no longer contain double backslashes. This caused problems when viewing those reports with Apache.
+Fixed bug 1031966 - Re-Implemented CloneMethodMustImplementCloneable as a typeresolution rule. This rule can now detect super classes/interfaces which are cloneable
+Fixed bug 1571309 - Optional command line options may be used either before or after the mandatory arguments
+Applied patch 1551189 - SingularField false + for initialization blocks
+Applied patch 1573981 - false + in CloneMethodMustImplementCloneable
+Applied patch 1574988 - false + in OverrideBothEqualsAndHashcode
+Applied patch 1583167 - Better test code management. Internal JUnits can now be written in XML's
+Applied patch 1613674 - Support classpaths with spaces in pmd.bat
+Applied patch 1615519 - controversial/DefaultPackage XPath rule is wrong
+Applied patch 1615546 - Added option to command line to write directly to a file
+Implemented RFE 1566313 - Command Line now takes minimumpriority attribute to filter out rulesets
+PMD now requires JDK 1.4 to run
+- PMD will still analyze code from earlier JDKs
+- PMD now uses the built-in JDK 1.4 regex utils vs Jakarta ORO
+- PMD now uses the JDK javax.xml APIs rather than being hardcoded to use Xerces and Xalan
+SummaryHTML Report changes from Brent Fisher - now contains linePrefix to support source output from javadoc using "linksource"
+Fixed CSVRenderer - had flipped line and priority columns
+Fixed bug in Ant task - CSV reports were being output as text.
+Fixed false negatives in UseArraysAsList.
+Fixed several JDK 1.5 parsing bugs.
+Fixed several rules (exceptions on jdk 1.5 and jdk 1.6 source code).
+Fixed array handling in AvoidReassigningParameters and UnusedFormalParameter.
+Fixed bug in UselessOverridingMethod: false + when adding synchronization.
+Fixed false positives in LocalVariableCouldBeFinal.
+Fixed false positives in MethodArgumentCouldBeFinal.
+Modified annotation suppression to use @SuppressWarning("PMD") to suppress all warnings and @SuppressWarning("PMD.UnusedLocalVariable") to suppress a particular rule's warnings.
+Rules can now call RuleContext.getSourceType() if they need to make different checks on JDK 1.4 and 1.5 code.
+CloseResource rule now checks code without java.sql import.
+ArrayIsStoredDirectly rule now checks Constructors
+undo/redo added to text areas in Designer.
+Better 'create rule XML' panel in Designer.
+use of entrySet to iterate over Maps.
+1.6 added as a valid option for targetjdk.
+PMD now allows rules to use Type Resolution. This was referenced in patch 1257259.
+Renderers use less memory when generating reports.
+New DynamicXPathRule class to speed up XPath based rules by providing a base type for the XPath expression.
+Multithreaded processing on multi core or multi cpu systems.
+Performance Refactoring, XPath rules re-written as Java:
+ AssignmentInOperand
+ AvoidDollarSigns
+ DontImportJavaLang
+ DontImportSun
+ MoreThanOneLogger
+ SuspiciousHashcodeMethodName
+ UselessStringValueOf
+
+
+
October 4, 2006 - 3.8:
+
+
New rules:
+ Basic ruleset: BrokenNullCheck
+ Strict exceptions ruleset: AvoidRethrowingException
+ Optimizations ruleset: UnnecessaryWrapperObjectCreation
+ Strings ruleset: UselessStringValueOf
+Fixed bug 1498910 - AssignmentInOperand no longer has a typo in the message.
+Fixed bug 1498960 - DontImportJavaLang no longer reports static imports of java.lang members.
+Fixed bug 1417106 - MissingBreakInSwitch no longer flags stmts where every case has either a return or a throw.
+Fixed bug 1412529 - UncommentedEmptyConstructor no longer flags private constructors.
+Fixed bug 1462189 - InsufficientStringBufferDeclaration now resets when it reaches setLength the same way it does at a Constructor
+Fixed bug 1497815 - InsufficientStringBufferDeclaration rule now takes the length of the constructor into account, and adds the length of the initial string to its initial length
+Fixed bug 1504842 - ExceptionSignatureDeclaration no longer flags methods starting with 'test'.
+Fixed bug 1516728 - UselessOverridingMethod no longer raises an NPE on methods that use generics.
+Fixed bug 1522054 - BooleanInstantiation now detects instantiations inside method calls.
+Fixed bug 1522056 - UseStringBufferForStringAppends now flags appends which occur in static initializers and constructors
+Fixed bug 1526530 - SingularField now finds fields which are hidden at the method or static level
+Fixed bug 1529805 - UnusedModifier no longer throws NPEs on JDK 1.5 enums.
+Fixed bug 1531593 - UnnecessaryConversionTemporary no longer reports false positives when toString() is invoked inside the call to 'new Long/Integer/etc()'.
+Fixed bug 1512871 - Improved C++ tokenizer error messages - now they include the filename.
+Fixed bug 1531152 - CloneThrowsCloneNotSupportedException now reports the proper line number.
+Fixed bug 1531236 - IdempotentOperations reports fewer false positives.
+Fixed bug 1544564 - LooseCoupling rule now checks for ArrayLists
+Fixed bug 1544565 - NonThreadSafeSingleton now finds if's with compound statements
+Fixed bug 1561784 - AbstractOptimizationRule no longer throws ClassCastExceptions on certain postfix expressions.
+Fixed a bug in AvoidProtectedFieldInFinalClass - it no longer reports false positives for protected fields in inner classes.
+Fixed a bug in the C++ grammar - the tokenizer now properly recognizes macro definitions which are followed by a multiline comment.
+Modified C++ tokenizer to use the JavaCC STATIC option; this results in about a 30% speedup in tokenizing.
+Implemented RFE 1501850 - UnusedFormalParameter now catches cases where a parameter is assigned to but not used.
+Applied patch 1481024 (implementing RFE 1490181)- NOPMD messages can now be reported with a user specified msg, e.g., //NOPMD - this is expected
+Added JSP support to the copy/paste detector.
+Placed JSF/JSP ruleset names in rulesets/jsprulesets.properties
+Added the image to the ASTEnumConstant nodes.
+Added new XSLT stylesheet for CPD XML->HTML from Max Tardiveau.
+Refactored UseIndexOfChar to extract common functionality into AbstractPoorMethodCall.
+Improved CPD GUI and Designer look/functionality; thanks to Brian Remedios for the changes!
+Rewrote the NOPMD mechanism to collect NOPMD markers as the source file is tokenized. This eliminates an entire scan of each source file.
+Applied patch from Jason Bennett to enhance CyclomaticComplexity rule to account for conditional or/and nodes, do stmts, and catch blocks.
+Applied patch from Xavier Le Vourch to reduce false postives from CloneMethodMustImplementCloneable.
+Updated Jaxen library to beta 10.
+Performance Refactoring, XPath rules re-written as Java:
+ BooleanInstantiation
+ UselessOperationOnImmutable
+ OverrideBothEqualsAndHashcode
+ UnnecessaryReturn
+ UseStringBufferForStringAppends
+ SingularField
+ NonThreadSafeSingleton
+
+
+
June 1, 2006 - 3.7:
+
+
New rules:
+ Basic-JSP ruleset: DuplicateJspImport
+ Design ruleset: PreserveStackTrace
+ J2EE ruleset: UseProperClassLoader
+Implemented RFE 1462019 - Add JSPs to Ant Task
+Implemented RFE 1462020 - Add JSPs to Designer
+Fixed bug 1461426 InsufficientStringBufferDeclaration does not consider paths
+Fixed bug 1462184 False +: InsufficientStringBufferDeclaration - wrong size
+Fixed bug 1465574 - UnusedPrivateMethod no longer reports false positives when a private method is called from a method with a parameter of the same name.
+Fixed bug 1114003 - UnusedPrivateMethod no longer reports false positives when two methods have the same name and number of arguments but different types. The fix causes PMD to miss a few valid cases, but, c'est la vie.
+Fixed bug 1472843 - UnusedPrivateMethod no longer reports false positives when a private method is only called from a method that contains a variable with the same name as that method.
+Fixed bug 1461442 - UseAssertSameInsteadOfAssertTrue now ignores comparisons to null; UseAssertNullInsteadOfAssertTrue will report those.
+Fixed bug 1474778 - UnnecessaryCaseChange no longer flags usages of toUpperCase(Locale).
+Fixed bug 1423429 - ImmutableField no longer reports false positives on variables which can be set via an anonymous inner class that is created in the constructor.
+Fixed major bug in CPD; it was not picking up files other than .java or .jsp.
+Fixed a bug in CallSuperInConstructor; it now checks inner classes/enums more carefully.
+Fixed a bug in VariableNamingConventions; it was not setting the warning message properly.
+Fixed bug in C/C++ parser; a '$' is now allowed in an identifier. This is useful in VMS.
+Fixed a symbol table bug; PMD no longer crashes on enumeration declarations in the same scope containing the same field name
+Fixed a bug in ASTVariableDeclaratorId that triggered a ClassCastException if a annotation was used on a parameter.
+Added RuleViolation.getBeginColumn()/getEndColumn()
+Added an optional 'showSuppressed' item to the Ant task; this is false by default and toggles whether or not suppressed items are shown in the report.
+Added an IRuleViolation interface and modified various code classes (include Renderer implementations and Report) to use it.
+Modified JJTree grammar to use conditional node descriptors for various expression nodes and to use node suppression for ASTModifier nodes; this replaces a bunch of DiscardableNodeCleaner hackery. It also fixed bug 1445026.
+Modified C/CPP grammar to only build the lexical analyzer; we're not using the parser for CPD, just the token manager. This reduces the PMD jar file size by about 50 KB.
+
+
+
March 29, 2006 - 3.6:
+
+
New rules:
+ Basic ruleset: AvoidThreadGroup
+ Design ruleset: UnsynchronizedStaticDateFormatter
+ Strings ruleset: InefficientEmptyStringCheck, InsufficientStringBufferDeclaration
+ JUnit ruleset: SimplifyBooleanAssertion
+ Basic-JSF ruleset: DontNestJsfInJstlIteration
+ Basic-JSP ruleset: NoLongScripts, NoScriptlets, NoInlineStyleInformation, NoClassAttribute, NoJspForward, IframeMissingSrcAttribute, NoHtmlComments
+Fixed bug 1414985 - ConsecutiveLiteralAppends now checks for intervening references between appends.
+Fixed bug 1418424 - ConsecutiveLiteralAppends no longer flags appends in separate methods.
+Fixed bug 1416167 - AppendCharacterWithChar now catches cases involving escaped characters.
+Fixed bug 1421409 - Ant task now has setter to allow minimumPriority attribute to be used.
+Fixed bug 1416164 - InefficientStringBuffering no longer reports false positives on the three argument version of StringBuffer.append().
+Fixed bug 1415326 - JUnitTestsShouldContainAsserts no longer errors out on JDK 1.5 generics.
+Fixed bug 1415333 - CyclomaticComplexity no longer errors out on JDK 1.5 enums.
+Fixed bug 1415663 - PMD no longer fails to parse abstract classes declared in a method.
+Fixed bug 1433439 - UseIndexOfChar no longer reports false positives on case like indexOf('a' + getFoo()).
+Fixed bug 1435218 - LoggerIsNotStaticFinal no longer reports false positives for local variables.
+Fixed bug 1413745 - ArrayIsStoredDirectly no longer reports false positives for array deferences.
+Fixed bug 1435751 - Added encoding type of UTF-8 to the CPD XML file.
+Fixed bug 1441539 - ConsecutiveLiteralAppends no longer flags appends() involving method calls.
+Fixed bug 1339470 - PMD no longer fails to parse certain non-static initializers.
+Fixed bug 1425772 - PMD no longer fails with errors in ASTFieldDeclaration when parsing some JDK 1.5 code.
+Fixed bugs 1448123 and 1449175 - AvoidFieldNameMatchingTypeName, SingularField, TooManyFields, and AvoidFieldNameMatchingMethodName no longer error out on enumerations.
+Fixed bug 1444654 - migrating_to_14 and migrating_to_15 no longer refer to rule tests.
+Fixed bug 1445231 - TestClassWithoutTestCases: no longer flags abstract classes.
+Fixed bug 1445765 - PMD no longer uses huge amounts of memory. However, you need to use RuleViolation.getBeginLine(); RuleViolation.getNode() is no more.
+Fixed bug 1447295 - UseNotifyAllInsteadOfNotify no longer flags notify() methods that have a parameter.
+Fixed bug 1455965 - MethodReturnsInternalArray no longer flags variations on 'return new Object[] {}'.
+Implemented RFE 1415487 - Added a rulesets/releases/35.xml ruleset (and similar rulesets for previous releases) contains rules new to PMD v3.5
+Wouter Zelle fixed a false positive in NonThreadSafeSingleton.
+Wouter Zelle fixed a false positive in InefficientStringBuffering.
+The CPD Ant task now supports an optional 'language' attribute.
+Removed some ill-advised casts from the parsers.
+Fixed bug in CallSuperInConstructor; it no longer flag classes without extends clauses.
+Fixed release packaging; now entire xslt/ directory contents are included.
+Added more XSLT from Dave Corley - you can use them to filter PMD reports by priority level.
+You can now access the name of a MemberValuePair node using getImage().
+PositionLiteralsFirstInComparisons was rewritten in XPath.
+Added a getVersionString method to the TargetJDKVersion interface.
+Added an option '--targetjdk' argument to the Benchmark utility.
+Applied a patch from Wouter Zelle to clean up the Ant Formatter class, fix a TextRenderer bug, and make toConsole cleaner.
+Rewrote AvoidCallingFinalize in Java; fixed bug and runs much faster, too.
+Uploaded ruleset schema to http://pmd.sf.net/ruleset_xml_schema.xsd
+UseIndexOfChar now catches cases involving lastIndexOf.
+Rules are now run in the order in which they're listed in a ruleset file. Internally, they're now stored in a List vs a Set, and RuleSet.getRules() now returns a Collection.
+Upgraded to JUnit version 3.8.2.
+
+
+
Jan 25, 2006 - 3.5:
+
+
New rules:
+ Basic ruleset: UselessOperationOnImmutable, MisplacedNullCheck, UnusedNullCheckInEquals
+ Migration ruleset: IntegerInstantiation
+ JUnit ruleset: UseAssertNullInsteadOfAssertTrue
+ Strings ruleset: AppendCharacterWithChar, ConsecutiveLiteralAppends, UseIndexOfChar
+ Design ruleset: AvoidConstantsInterface
+ Optimizations ruleset: UseArraysAsList, AvoidArrayLoops
+ Controversial ruleset: BooleanInversion
+Fixed bug 1371980 - InefficientStringBuffering no longer flags StringBuffer methods other than append().
+Fixed bug 1277373 - InefficientStringBuffering now catches more cases.
+Fixed bug 1376760 - InefficientStringBuffering no longer throws a NullPointerException when processing certain expressions.
+Fixed bug 1371757 - Misleading example in AvoidSynchronizedAtMethodLevel
+Fixed bug 1373510 - UseAssertSameInsteadOfAssertTrue no longer has a typo in its message, and its message is more clear.
+Fixed bug 1375290 - @SuppressWarnings annotations are now implemented correctly; they accept one blank argument to suppress all warnings.
+Fixed bug 1376756 - UselessOverridingMethod no longer throws an exception on overloaded methods.
+Fixed bug 1378358 - StringInstantiation no longer throws ClassCastExceptions on certain allocation patterns.
+Fixed bug 1371741 - UncommentedEmptyConstructor no longer flags constructors that consist of a this() or a super() invocation.
+Fixed bug 1277373 - InefficientStringBuffering no longer flags concatenations that involve a static final String.
+Fixed bug 1379701 - CompareObjectsWithEquals no longer flags comparisons of array elements.
+Fixed bug 1380969 - UnusedPrivateMethod no longer flags private static methods that are only invoked in a static context from a field declaration.
+Fixed bug 1384594 - Added a 'prefix' property for BeanMembersShouldSerializeRule
+Fixed bug 1394808 - Fewer missed hits for AppendCharacterWithChar and InefficientStringBuffering, thanks to Allan Caplan for catching these
+Fixed bug 1400754 - A NPE is no longer thrown on certain JDK 1.5 enum usages.
+Partially fixed bug 1371753 - UnnecessaryLocalBeforeReturn message now reflects the fact that that rule flags all types
+Fixed a bug in UseStringBufferLength; it no longers fails with an exception on expressions like StringBuffer.toString.equals(x)
+Fixed a bug in CPD's C/C++ parser so that it no longer fails on multi-line literals; thx to Tom Judge for the nice patch.
+CPD now recognizes '--language c' and '--language cpp' as both mapping to the C/C++ parser.
+Modified renderers to support disabling printing of suppressed warnings. Introduced a new AbstractRenderer class that all Renderers can extends to get the current behavior - that is, suppressed violations are printed.
+Implemented RFE 1375435 - you can now embed regular expressions inside XPath rules, i.e., //ClassOrInterfaceDeclaration[matches(@Image, 'F?o')].
+Added current CLASSPATH to pmd.bat.
+UnusedFormalParameter now catches unused constructor parameters, and its warning message now reflects whether it caught a method or a constructor param.
+Rebuilt JavaCC parser with JavaCC 4.0.
+Added jakarta-oro-2.0.8.jar as a new dependency to support regular expression in XPath rules.
+Ant task now supports a 'minimumPriority' attribute; only rules with this priority or higher will be run.
+Renamed Ant task 'printToConsole' attribute to 'toConsole' and it can only be used inside a formatter element.
+Added David Corley's Javascript report, more details are here: http://tomcopeland.blogs.com/juniordeveloper/2005/12/demo_of_some_ni.html
+
+
+
November 30, 2005 - 3.4:
+
+
New rules:
+ Basic ruleset: ClassCastExceptionWithToArray, AvoidDecimalLiteralsInBigDecimalConstructor
+ Design ruleset: NonThreadSafeSingleton, UncommentedEmptyMethod, UncommentedEmptyConstructor
+ Controversial ruleset: DefaultPackage
+ Naming ruleset: MisleadingVariableName
+ Migration ruleset: ReplaceVectorWithList, ReplaceHashtableWithMap, ReplaceEnumerationWithIterator, AvoidEnumAsIdentifier, AvoidAssertAsIdentifier
+ Strings ruleset: UseStringBufferLength
+Fixed bug 1292745 - Removed unused source file ExceptionTypeChecking.java
+Fixed bug 1292609 - The JDK 1.3 parser now correctly handles certain 'assert' usages. Also added a 'JDK 1.3' menu item to the Designer.
+Fixed bug 1292689 - Corrected description for UnnecessaryLocalBeforeReturn
+Fixed bug 1293157 - UnusedPrivateMethod no longer reports false positives for private methods which are only invoked from static initializers.
+Fixed bug 1293277 - Messages that used 'pluginname' had duplicated messages.
+Fixed bug 1291353 - ASTMethodDeclaration isPublic/isAbstract methods always return true. The syntactical modifier - i.e., whether or not 'public' was used in the source code in the method declaration - is available via 'isSyntacticallyPublic' and 'isSyntacticallyAbstract'
+Fixed bug 1296544 - TooManyFields no longer checks the wrong property value.
+Fixed bug 1304739 - StringInstantiation no longer crashes on certain String constructor usages.
+Fixed bug 1306180 - AvoidConcatenatingNonLiteralsInStringBuffer no longer reports false positives on certain StringBuffer usages.
+Fixed bug 1309235 - TooManyFields no longer includes static finals towards its count.
+Fixed bug 1312720 - DefaultPackage no longer flags interface fields.
+Fixed bug 1312754 - pmd.bat now handles command line arguments better in WinXP.
+Fixed bug 1312723 - Added isSyntacticallyPublic() behavior to ASTFieldDeclaration nodes.
+Fixed bug 1313216 - Designer was not displaying 'final' attribute for ASTLocalVariableDeclaration nodes.
+Fixed bug 1314086 - Added logging-jakarta-commons as a short name for rulesets/logging-jakarta-commons.xml to SimpleRuleSetNameMapper.
+Fixed bug 1351498 - Improved UnnecessaryCaseChange warning message.
+Fixed bug 1351706 - CompareObjectsWithEquals now catches more cases.
+Fixed bug 1277373 (and 1347286) - InefficientStringBuffering now flags fewer false positives.
+Fixed bug 1363447 - MissingBreakInSwitch no longer reports false positives for switch statements where each switch label has a return statement.
+Fixed bug 1363458 - MissingStaticMethodInNonInstantiatableClass no longer reports cases where there are public static fields.
+Fixed bug 1364816 - ImmutableField no longer reports false positives for fields assigned in an anonymous inner class in a constructor.
+Implemented RFE 1311309 (and 1119854) - Suppressed RuleViolation counts are now included in the reports.
+Implemented RFE 1220371 - Rule violation suppression via annotations. Per the JLS, @SuppressWarnings can be placed before the following nodes: TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE.
+Implemented RFE 1275547 - OverrideBothEqualsAndHashcode now skips Comparator implementations.
+Applied patch 1306999 - Renamed CloseConnection to CloseResource and added support for checking Statement and ResultSet objects.
+Applied patch 1344754 - EmptyCatchBlock now skips catch blocks that contain comments. This is also requested in RFE 1347884.
+Renamed AvoidConcatenatingNonLiteralsInStringBuffer to InefficientStringBuffering; new name is a bit more concise.
+Modified LongVariable; now it has a property which can be used to override the minimum reporting value.
+Improved CPD XML report.
+CPD no longer skips header files when checking C/C++ code.
+Reworked CPD command line arguments; old-style arguments will still work for one more version, though.
+Lots of documentation improvements.
+
+
+
September 15, 2005 - 3.3:
+
+
New rules:
+ Design: PositionLiteralsFirstInComparisons, UnnecessaryLocalBeforeReturn
+ Logging-jakarta-commons: ProperLogger
+ Basic: UselessOverridingMethod
+ Naming: PackageCase, NoPackage
+ Strings: UnnecessaryCaseChange
+Implemented RFE 1220171 - rule definitions can now contain a link to an external URL for more information on that rule - for example, a link to the rule's web page. Thanks to Wouter Zelle for designing and implementing this!
+Implemented RFE 1230685 - The text report now includes parsing errors even if no rule violations are reported
+Implemented RFE 787860 - UseSingleton now accounts for JUnit test suite declarations.
+Implemented RFE 1097090 - The Report object now contains the elapsed time for running PMD. This shows up in the XML report as an elapsedTime attribute in the pmd element in the format '2m 5s' or '1h 5h 35s' or '25s' .
+Implemented RFE 1246338 - CPD now handles SCCS directories and NTFS junction points.
+Fixed bug 1226858 - JUnitAssertionsShouldIncludeMessage now checks calls to assertFalse.
+Fixed bug 1227001 - AvoidCallingFinalize no longer flags calls to finalize() within finalizers.
+Fixed bug 1229755 - Fixed typo in ArrayIsStoredDirectly description.
+Fixed bug 1229749 - Improved error message when an external rule is not found.
+Fixed bug 1224849 - JUnitTestsShouldContainAsserts no longer skips method declarations which include explicit throws clauses.
+Fixed bug 1225492 - ConstructorCallsOverridableMethod now reports the correct method name. dvholten's examples in RFE 1235562 also helped with this a great deal.
+Fixed bug 1228589 - DoubleCheckedLocking and ExceptionSignatureDeclaration no longer throw ClassCastExceptions on method declarations that declare generic return types.
+Fixed bug 1235299 - NullAssignment no longer flags null equality comparisons in ternary expressions.
+Fixed bug 1235300 - NullAssignment no longer flags assignments to final fields.
+Fixed bug 1240201 - The UnnecessaryParentheses message is no longer restricted to return statements.
+Fixed bug 1242290 - The JDK 1.5 parser no longer chokes on nested enumerations with a constructor.
+Fixed bug 1242544 - SimplifyConditional no longer flags null checks that precede an instanceof involving an array dereference.
+Fixed bug 1242946 - ArrayIsStoredDirectly no longer reports false positives for equality expression comparisons. As a bonus, its message now includes the variable name :-)
+Fixed bug 1232648 - MethodReturnsInternalArray no longer reports false positives on return statement expressions that involve method invocations on an internal array.
+Fixed bug 1244428 - MissingStaticMethodInNonInstantiatableClass no longer reports warnings for nested classes. Some inner class cases will be missed, but false positives will be eliminated as well.
+Fixed bug 1244443 - EqualsNull now catches more cases.
+Fixed bug 1250949 - The JDK 1.5 parser no longer chokes on annotated parameters and annotated local variables.
+Fixed bug 1245139 - TooManyFields no longer throws a ClassCastException when processing anonymous classes.
+Fixed bug 1251256 - ImmutableField no longer skips assignments in try blocks on methods (which led to false positives).
+Fixed bug 1250949 - The JDK 1.5 parser no longer chokes on AnnotationTypeMemberDeclaration with a default value.
+Fixed bug 1245367 - ImmutableField no longer triggers on assignments in loops in constructors.
+Fixed bug 1251269 - AvoidConcatenatingNonLiteralsInStringBuffer no longer triggers on StringBuffer constructors like 'new StringBuffer(1 + getFoo());'
+Fixed bug 1244570 - AvoidConcatenatingNonLiteralsInStringBuffer no longer triggers on certain AST patterns involving local variable declarations inside Statement nodes.
+Fixed bug 695344 - StringInstantiation no longer triggers on the String(byte[]) constructor.
+Fixed bug 1114754 - UnusedPrivateMethod reports fewer false positives.
+Fixed bug 1290718 - Command line parameter documentation is now correct for targetjdk options.
+Applied patch 1228834 - XPath rules can now use properties to customize rules. Thanks to Wouter Zelle for another great piece of work!
+Fixed a bug in RuleSetFactory that missed some override cases; thx to Wouter Zelle for the report and a fix.
+Fixed a bug in the grammar that didn't allow constructors to have type parameters, which couldn't parse some JDK 1.5 constructs.
+Fixed a bug in ImportFromSamePackage; now it catches the case where a class has an on-demand import for the same package it is in.
+Fixed a bug in CompareObjectsWithEquals; now it catches some local variable cases.
+Fixed a bug in CouplingBetweenObjects; it no longer triggers an exception (which is a bug in the symbol table layer) by calling getEnclosingClassScope() when the node in question isn't enclosed by one.
+Moved AvoidCallingFinalize from the design ruleset to the finalize ruleset and then deleted redundant ExplicitCallToFinalize rule from the finalize ruleset.
+Deleted redundant ExceptionTypeChecking rule from the strictexception ruleset; use AvoidInstanceofChecksInCatchClause in the design ruleset instead.
+Added some new XSLT scripts that create nifty HTML output; thanks to Wouter Zelle for the code.
+Improved UseCorrectExceptionLogging; thx to Wouter Zelle for the new XPath.
+Improved warning message from UnusedPrivateMethod.
+Improved EmptyIfStmt; now it catches the case where an IfStatement is followed by an EmptyStatement node.
+The Ant task now accepts the short names of rulesets (e.g., unusedcode for rulesets/unusedcode.xml).
+Removed unnecessary '.html' suffix from displayed filenames when the linkPrefix attribute is used with the HTML renderer.
+Added an optional 'description' attribute to the 'property' element in the ruleset XML files.
+Added a simplified SimpleNode.addViolation() method to reduce duplicated rule violation creation code.
+Moved from jaxen-1.0-fcs.jar/saxpath-1.0-fcs.jar to jaxen-1.1-beta-7.jar. This yielded a 20% speed increase in the basic ruleset!
+
+
+
June 21, 2005 - 3.2:
+
+
New rules: UseCorrectExceptionLogging (logging-jakarta-commons ruleset), AvoidPrintStackTrace (logging-java ruleset), CompareObjectsWithEquals (design ruleset)
+Fixed bug 1201577 - PMD now correctly parses method declarations that return generic types.
+Fixed bug 1205709 - PMD no longer takes a long time to report certain parsing errors.
+Fixed bug 1052356 - ImmutableField no longer triggers on fields which are assigned to in a constructor's try statement.
+Fixed bug 1215854 - Package/class/method names are now filled in whenever possible, and the XML report includes all three.
+Fixed bug 1209719 - MethodArgumentCouldBeFinal no longer triggers on arguments which are modified using postfix or prefix expressions. A bug in AvoidReassigningParameters was also fixed under the same bug id.
+Fixed bug 1188386 - MethodReturnsInternalArray no longer flags returning a local array declaration.
+Fixed bug 1172137 - PMD no longer locks up when generating a control flow graph for if statements with labelled breaks.
+Fixed bug 1221094 - JUnitTestsShouldContainAsserts no longer flags static methods.
+Fixed bug 1217028 - pmd.bat now correctly passes parameters to PMD.
+Implemented RFE 1188604 - AvoidThrowingCertainExceptionTypes has been split into AvoidThrowingRawExceptionTypes and AvoidThrowingNullPointerException.
+Implemented RFE 1188369 - UnnecessaryBooleanAssertion now checks for things like 'assertTrue(!foo)'. These should be changed to 'assertFalse(foo)' for clarity.
+Implemented RFE 1199622 - UnusedFormalParameter now defaults to only checking private methods unless a 'checkall' property is set.
+Implemented RFE 1220314 - the symbol table now includes some rudimentary type information.
+Break and continue statement labels (if present) are placed in the image field.
+Fixed bug which caused MissingSerialVersionUID to trigger on all interfaces that implemented other interfaces.
+Modified NullAssignmentRule to catch null assignments in ternary expressions.
+Added two new node types - ASTCatchStatement and ASTFinallyStatement.
+Modified rule XML definition; it no longer includes a symboltable attribute since the symbol table layer is now run for all files analyzed.
+Harden equality of AbstractRule and RuleSet objects (needed for the Eclipse plugin features)
+Change RuleSet.getRuleByName. Now return null instead of throwing a RuntimeException when the rule is not found
+Add .project and .classpath to the module so that it can be checkout as an Eclipse project
+
+
+
May 10, 2005 - 3.1:
+
+
New rules: SimplifyStartsWith, UnnecessaryParentheses, CollapsibleIfStatements, UseAssertEqualsInsteadOfAssertTrue, UseAssertSameInsteadOfAssertTrue, UseStringBufferForStringAppends, SimplifyConditional, SingularField
+Fixed bug 1170535 - LongVariable now report variables longer than 17 characters, not 12.
+Fixed bug 1182755 - SystemPrintln no longer overreports problems.
+Fixed bug 1188372 - AtLeastOneConstructor no longer fires on interfaces.
+Fixed bug 1190508 - UnnecessaryBooleanAssertion no longer fires on nested boolean literals.
+Fixed bug 1190461 - UnusedLocal no longer misses usages which are on the RHS of a right bit shift operator.
+Fixed bug 1188371 - AvoidInstantiatingObjectsInLoops no longer fires on instantiations in loops when the 'new' keyword is preceded by a 'return' or a 'throw'.
+Fixed bug 1190526 - TooManyFields now accepts a property setting correctly, and default lower bound is 15 vs 10.
+Fixed bug 1196238 - UnusedImports no longer reports false positives for various JDK 1.5 java.lang subpackages.
+Fixed bug 1169731 - UnusedImports no longer reports false positives on types used inside generics. This bug also resulted in a bug in ForLoopShouldBeWhileLoop being fixed, thanks Wim!
+Fixed bug 1187325 - UnusedImports no longer reports a false positive on imports which are used inside an Annotation.
+Fixed bug 1189720 - PMD no longer fails to parse generics that use 'member selectors'.
+Fixed bug 1170109 - The Ant task now supports an optional 'targetjdk' attribute that accepts values of '1.3', '1.4', or '1.5'.
+Fixed bug 1183032 - The XMLRenderer no longer throws a SimpleDateFormat exception when run with JDK 1.3.
+Fixed bug 1097256 - The XMLRenderer now supports optional encoding of UTF8 characters using the 'net.sourceforge.pmd.supportUTF8' environment variable.
+Fixed bug 1198832 - AbstractClassWithoutAbstractMethod no longer flags classes which implement interfaces since these can partially implement the interface and thus don't need to explicitly declare abstract methods.
+Implemented RFE 1193979 - BooleanInstantiation now catches cases like Boolean.valueOf(true)
+Implemented RFE 1171095 - LabeledStatement nodes now contain the image of the label.
+Implemented RFE 1176401 - UnusedFormalParameter now flags public methods.
+Implemented RFE 994338 - The msg produced by ConstructorCallsOverridableMethod now includes the offending method name.
+Modified command line parameters; removed -jdk15 and -jdk13 parameters and added a -'targetjdk [1.3|1.4|1.5]' parameter.
+Modified CSVRenderer to include more columns.
+Optimized rules: FinalFieldCouldBeStatic (115 seconds to 7 seconds), SuspiciousConstantFieldName (48 seconds to 14 seconds), UnusedModifer (49 seconds to 4 seconds)
+
+
+
March 23, 2005 - 3.0:
+
+
New rules: MissingSerialVersionUID, UnnecessaryFinalModifier, AbstractClassDoesNotContainAbstractMethod, MissingStaticMethodInNonInstantiatableClass, AvoidSynchronizedAtMethodLevel, AvoidCallingFinalize, UseNotifyAllInsteadOfNotify, MissingBreakInSwitch, AvoidInstanceofChecksInCatchClause, AvoidFieldNameMatchingTypeName, AvoidFieldNameMatchingMethodName, AvoidNonConstructorMethodsWithClassName, TestClassWithoutTestCases, TooManyFields, CallSuperInConstructor, UnnecessaryBooleanAssertion, UseArrayListInsteadOfVector
+Implemented RFE 1058039 - PMD's command line interface now accepts abbreviated names for the standard rulesets; for example 'java net.sourceforge.pmd.PMD /my/source/code/ text basic,unusedcode' would run the rulesets/basic.xml and the rulesets/unusedcode.xml rulesets on the source in /my/source/code and produce a text report.
+Implemented RFE 1119851 - PMD's Ant task now supports an 'excludeMarker' attribute.
+Fixed bug 994400 - False +: ConstructorCallsOverridableMethodRule, thanks to ereissner for reporting it
+Fixed bug 1146116 - JUnitTestsShouldIncludeAssert no longer crashes on inner Interface
+Fixed bug 1114625 - UnusedPrivateField no longer throws an NPE on standalone postfix expressions which are prefixed with 'this'.
+Fixed bug 1114020 - The Ant task now reports a complete stack trace when run with the -verbose flag.
+Fixed bug 1117983 - MethodArgumentCouldBeFinal no longer reports false positives on try..catch blocks.
+Fixed bug 797742 - PMD now parses JDK 1.5 source code. Note that it's not perfect yet; more testing/bug reports are welcome!
+Fixed a bug - the StatisticalRule no longer 'merges' data points when using the 'topscore' property.
+Fixed a bug - the PMD Ant task's failOnRuleViolation attribute no longer causes a BuildException in the case when no rule violations occur.
+Modified the XSLT to add a summary section.
+Added Ruby support to CPD.
+Optimized various rules and wrote a benchmarking application; results are here - http://infoether.com/~tom/pmd_timing.txt
+
+
+
February 1, 2005 - 2.3:
+
+
Fixed bug 1113927 - ExceptionAsFlowControl no longer throws NPEs on code where a throw statement exists without a try statement wrapping it.
+Fixed bug 1113981 - AvoidConcatenatingNonLiteralsInStringBuffer no longer throws NPEs on code where an append appears as a child of an ExplicitConstructorInvocation node.
+Fixed bug 1114039 - AvoidInstantiatingObjectsInLoops's message no longer contains a spelling error.
+Fixed bug 1114029 - The 'optimization' rules no longer throw NPEs at various points.
+Fixed bug 1114251 - The 'sunsecure' rules no longer throw NPEs at various points.
+
+
+
January 31, 2005 - 2.2:
+
+
New rules: LocalVariableCouldBeFinal, MethodArgumentCouldBeFinal, AvoidInstantiatingObjectsInLoops, ArrayIsStoredDirectly, MethodReturnsInternalArray, AssignmentToNonFinalStatic, AvoidConcatenatingNonLiteralsInStringBuffer
+Fixed bug 1088459 - JUnitTestsShouldContainAsserts no longer throws ClassCastException on interface, native, and abstract method declarations.
+Fixed bug 1100059 - The Ant task now generates a small empty-ish report if there are no violations.
+Implemented RFE 1086168 - PMD XML reports now contain a version and timestamp attribute in the <pmd> element.
+Implemented RFE 1031950 - The PMD Ant task now supports nested ruleset tags
+Fixed a bug in the rule override logic; it no longer requires the "class" attribute of a rule be listed in the overrides section.
+Added 'ignoreLiterals' and 'ignoreIdentifiers' boolean options to the CPD task.
+Cleaned up a good bit of the symbol table code; thanks much to Harald Gurres for the patch.
+CPD now contains a generic copy/paste checker for programs in any language
+
+
+
December 15, 2004 - 2.1:
+
+
New rules: AvoidProtectedFieldInFinalClass, SystemPrintln
+Fixed bug 1050173 - ImmutableFieldRule no longer reports false positives for static fields.
+Fixed bug 1050286 - ImmutableFieldRule no longer reports false positives for classes which have multiple constructors only a subset of which set certain fields.
+Fixed bug 1055346 - ImmutableFieldRule no longer reports false positive on preinc/predecrement/postfix expressions.
+Fixed bug 1041739 - EmptyStatementNotInLoop no longer reports false positives for nested class declarations in methods.
+Fixed bug 1039963 - CPD no longer fails to parse C++ files with multi-line macros.
+Fixed bug 1053663 - SuspiciousConstantFieldName no longer reports false positives for interface members.
+Fixed bug 1055930 - CouplingBetweenObjectsRule no longer throws a NPE on interfaces
+Fixed a possible NPE in dfa.report.ReportTree.
+Implemented RFE 1058033 - Renamed run.[sh|bat] to pmd.[sh|bat].
+Implemented RFE 1058042 - XML output is more readable now.
+Applied patch 1051956 - Rulesets that reference rules using "ref" can now override various properties.
+Applied patch 1070733 - CPD's Java checker now has an option to ignore both literals and identifiers - this can help find large duplicate code blocks, but can also result in false positives.
+YAHTMLRenderer no longer has dependence on Ant packages.
+Modified the AST to correctly include PostfixExpression nodes. Previously a statement like "x++;" was embedded in the parent StatementExpression node.
+Moved BooleanInstantiation from the design ruleset to the basic ruleset.
+Updated Xerces libraries to v2.6.2.
+Many rule names had the word "Rule" tacked on to the end. Various folks thought this was a bad idea, so here are the new names of those rules which were renamed:
+- basic.xml: UnnecessaryConversionTemporary, OverrideBothEqualsAndHashcode, DoubleCheckedLocking
+- braces.xml: WhileLoopsMustUseBraces, IfElseStmtsMustUseBraces, ForLoopsMustUseBraces
+- clone.xml: ProperCloneImplementation
+- codesize.xml: CyclomaticComplexity, ExcessivePublicCount
+- controversial.xml: UnnecessaryConstructor, AssignmentInOperand, DontImportSun, SuspiciousOctalEscape
+- coupling.xml: CouplingBetweenObjects, ExcessiveImports, LooseCoupling
+- design.xml: UseSingleton, SimplifyBooleanReturns, AvoidReassigningParameters, ConstructorCallsOverridableMethod, AccessorClassGeneration, CloseConnection, OptimizableToArrayCall, IdempotentOperations. ImmutableField
+- junit.xml: JUnitAssertionsShouldIncludeMessage, JUnitTestsShouldIncludeAssert
+- logging-java.xml: MoreThanOneLogger, LoggerIsNotStaticFinal
+- naming.xml: ShortMethodName, VariableNamingConventions, ClassNamingConventions, AbstractNaming
+- strictexception.xml: ExceptionAsFlowControl, AvoidCatchingNPE, AvoidThrowingCertainExceptionTypes
+Continued working on JDK 1.5 compatibility - added support for static import statements, varargs, and the new for loop syntax
+- still TODO: generics and annotations (note that autoboxing shouldn't require a grammar change)
+- Good article on features: http://java.sun.com/developer/technicalArticles/releases/j2se15/
+
+
+
October 19, 2004 - 2.0:
+
+
New rules: InstantiationToGetClass, IdempotentOperationsRule, SuspiciousEqualsMethodName, SimpleDateFormatNeedsLocale, JUnitTestsShouldContainAssertsRule, SuspiciousConstantFieldName, ImmutableFieldRule, MoreThanOneLoggerRule, LoggerIsNotStaticFinalRule, UseLocaleWithCaseConversions
+Applied patch in RFE 992576 - Enhancements to VariableNamingConventionsRule
+Implemented RFE 995910 - The HTML report can now include links to HTMLlized source code - for example, the HTML generated by JXR.
+Implemented RFE 665824 - PMD now ignores rule violations in lines containing the string 'NOPMD'.
+Fixed bug in SimplifyBooleanExpressions - now it catches more cases.
+Fixed bugs in AvoidDuplicateLiterals - now it ignores small duplicate literals, its message is more helpful, and it catches more cases.
+Fixed bug 997893 - UnusedPrivateField now detects assignments to members of private fields as a usage.
+Fixed bug 1020199 - UnusedLocalVariable no longer flags arrays as unused if an assignment is made to an array slot.
+Fixed bug 1027133 - Now ExceptionSignatureDeclaration skips certain JUnit framework methods.
+Fixed bug 1008548 - The 'favorites' ruleset no longer contains a broken reference.
+Fixed bug 1045583 - UnusedModifier now correctly handles anonymous inner classes within interface field declarations.
+Partially fixed bug 998122 - CloseConnectionRule now checks for imports of java.sql before reporting a rule violation.
+Applied patch 1001694 - Now PMD can process zip/jar files of source code.
+Applied patch 1032927 - The XML report now includes the rule priority.
+Added data flow analysis facade from Raik Schroeder.
+Added two new optional attributes to rule definitions - symboltable and dfa. These allow the symbol table and DFA facades to be configured on a rule-by-rule basis. Note that if your rule needs the symbol table; you'll need to add symboltable="true" to your rule definition. FWIW, this also results in about a 5% speedup for rules that don't need either layer.
+Added a "logging" ruleset - thanks to Miguel Griffa for the code!
+Enhanced the ASTViewer - and renamed it 'Designer' - to display data flows.
+Moved development environment to Maven 1.0.
+Moved development environment to Ant 1.6.2. This is nice because using the new JUnit task attribute "forkmode='perBatch'" cuts test runtime from 90 seconds to 7 seconds. Sweet.
+MethodWithSameNameAsEnclosingClass now reports a more helpful line number.
+
+
+
July 14, 2004 - 1.9:
+
+
New rules: CloneMethodMustImplementCloneable, CloneThrowsCloneNotSupportedException, EqualsNull, ConfusingTernary
+Created new "clone" ruleset and moved ProperCloneImplementationRule over from the design ruleset.
+Moved LooseCoupling from design.xml to coupling.xml.
+Some minor performance optimizations - removed some unnecessary casts from the grammar, simplified some XPath rules.
+Postfix expressions (i.e., x++) are now available in the grammar. To access them, search for StatementExpressions with an image of "++" or "--" - i.e., in XPath, //StatementExpression[@Image="++"]. This is an odd hack and hopefully will get cleared up later.
+Ant task and CLI now used BufferedInputStreams.
+Converted AtLeastOneConstructor rule from Java code to XPath.
+Implemented RFE 743460: The XML report now contains the ruleset name.
+Implemented RFE 958714: Private field and local variables that are assigned but not used are now flagged as unused.
+Fixed bug 962782 - BeanMembersShouldSerializeRule no longer reports set/is as being a violation.
+Fixed bug 977022 - UnusedModifier no longer reports false positives for modifiers of nested classes in interfaces
+Fixed bug 976643 - IfElseStmtsMustUseBracesRule no longer reports false positives for certain if..else constructs.
+Fixed bug 985961 - UseSingletonRule now fires on classes which contain static fields
+Fixed bug 977031 - FinalizeDoesNotCallSuperFinalize no longer reports a false positive when a finalizer contains a call to super.finalize in a try {} finally {} block.
+
+
+
May 19, 2004 - 1.8:
+
+
New rules: ExceptionAsFlowControlRule, BadComparisonRule, AvoidThrowingCertainExceptionTypesRule, AvoidCatchingNPERule, OptimizableToArrayCallRule
+Major grammar changes - lots of new node types added, many superfluous nodes removed from the runtime AST. Bug 786611 - http://sourceforge.net/tracker/index.php?func=detail&aid=786611&group_id=56262&atid=479921 - explains it a bit more.
+Fixed bug 786611 - Expressions are no longer over-expanded in the AST
+Fixed bug 874284 - The AST now contains tokens for bitwise or expressions - i.e., "|"
+
+
+
April 22, 2004 - 1.7:
+
+
Moved development environment to Maven 1.0-RC2.
+Fixed bug 925840 - Messages were no longer getting variable names plugged in correctly
+Fixed bug 919308 - XMLRenderer was still messed up; 'twas missing a quotation mark.
+Fixed bug 923410 - PMD now uses the default platform character set encoding; optionally, you can pass in a character encoding to use.
+Implemented RFE 925839 - Added some more detail to the UseSingletonRule.
+Added an optional 'failuresPropertyName' attribute to the Ant task.
+Refactored away duplicate copies of XPath rule definitions in regress/, yay!
+Removed manifest from jar file; it was only there for the Main-class attribute, and it's not very useful now since PMD has several dependencies.
+Began working on JDK 1.5 compatibility - added support for EnumDeclaration nodes.
+
+
+
March 15, 2004 - 1.6:
+
+
Fixed bug 895661 - XML reports containing error elements no longer have malformed XML.
+Fixed a bug in UnconditionalIfStatement - it no longer flags things like "if (x==true)".
+Applied Steve Hawkins' improvements to CPD:
+- Various optimizations; now it runs about 4 times faster!
+- fixed "single match per file" bug
+- tweaked source code slicing
+- CSV renderer
+Added two new renderers - SummaryHTMLRenderer and PapariTextRenderer.
+Moved development environment to Ant 1.6 and JavaCC 3.2.
+
+
+
February 2, 2004 - 1.5:
+
+
New rules: DontImportSunRule, EmptyFinalizer, EmptyStaticInitializer, AvoidDollarSigns, FinalizeOnlyCallsSuperFinalize, FinalizeOverloaded, FinalizeDoesNotCallSuperFinalize, MethodWithSameNameAsEnclosingClass, ExplicitCallToFinalize, NonStaticInitializer, DefaultLabelNotLastInSwitchStmt, NonCaseLabelInSwitchStatement, SuspiciousHashcodeMethodName, EmptyStatementNotInLoop, SuspiciousOctalEscapeRule
+FinalizeShouldBeProtected moved from design.xml to finalizers.xml.
+Added isTrue() to ASTBooleanLiteral.
+Added UnaryExpression to the AST.
+Added isPackagePrivate() to AccessNode.
+
+
+
January 7, 2004 - 1.4:
+
+
New rules: AbstractNamingRule, ProperCloneImplementationRule
+Fixed bug 840926 - AvoidReassigningParametersRule no longer reports a false positive when assigning a value to an array slot when the array is passed as a parameter to a method
+Fixed bug 760520 - RuleSetFactory is less strict about whitespace in ruleset.xml files.
+Fixed bug 826805 - JumbledIncrementorRule no longer reports a false positive when a outer loop incrementor is used as an array index
+Fixed bug 845343 - AvoidDuplicateLiterals now picks up cases when a duplicate literal appears in field declarations.
+Fixed bug 853409 - VariableNamingConventionsRule no longer requires that non-static final fields be capitalized
+Fixed a bug in OverrideBothEqualsAndHashcodeRule; it no longer reports a false positive when equals() is passed the fully qualified name of Object.
+Implemented RFE 845348 - UnnecessaryReturn yields more useful line numbers now
+Added a ruleset DTD and a ruleset XML Schema.
+Added 'ExplicitExtends' and 'ExplicitImplements' attributes to UnmodifiedClassDeclaration nodes.
+
+
+
October 23, 2003 - 1.3:
+
+
Relicensed under a BSD-style license.
+Fixed bug 822245 - VariableNamingConventionsRule now handles interface fields correctly.
+Added new rules: EmptySynchronizedBlock, UnnecessaryReturn
+ASTType now has an getDimensions() method.
+
+
+
October 06, 2003 - 1.2.2:
+
+
Added new rule: CloseConnectionRule
+Fixed bug 782246 - FinalFieldCouldBeStatic no longer flags fields in interfaces.
+Fixed bug 782235 - "ant -version" now prints more details when a file errors out.
+Fixed bug 779874 - LooseCouplingRule no longer triggers on ArrayList
+Fixed bug 781393 - VariableNameDeclaration no longer throws ClassCastExpression since ASTLocalVariableDeclaration now subclasses AccessNode
+Fixed bug 797243 - CPD XML report can no longer contain ]]> (CDEnd)
+Fixed bug 690196 - PMD now handles both JDK 1.3 and 1.4 code - i.e., usage of "assert" as an identifier.
+Fixed bug 805092 - VariableNamingConventionsRule no longer flags serialVersionUID as a violation
+Fixed bug - Specifying a non-existing rule format on the command line no longer results in a ClassNotFoundException.
+XPath rules may now include pluggable parameters. This feature is very limited. For now.
+Tweaked CPD time display field
+Made CPD text fields uneditable
+Added more error checking to CPD GUI input
+Added "dialog cancelled" check to CPD "Save" function
+Added Boris Gruschko's AST viewer.
+Added Jeff Epstein's TextPad integration.
+ASTType now has an isArray() method.
+
+
+
August 1, 2003 - 1.2.1:
+
+
Fixed bug 781077 - line number "-1" no longer appears for nodes with siblings.
+
+
+
July 30, 2003 - 1.2:
+
+
Added new rules: VariableNamingConventionsRule, MethodNamingConventionsRule, ClassNamingConventionsRule, AvoidCatchingThrowable, ExceptionSignatureDeclaration, ExceptionTypeChecking, BooleanInstantiation
+Fixed bug 583047 - ASTName column numbers are now correct
+Fixed bug 761048 - Symbol table now creates a scope level for anonymous inner classes
+Fixed bug 763529 - AccessorClassGenerationRule no longer crashes when given a final inner class
+Fixed bug 771943 - AtLeastOneConstructorRule and UnnecessaryConstructorRule no longer reports false positives on inner classes.
+Applied patch from Chris Webster to fix another UnnecessaryConstructorRule problem.
+Added ability to accept a comma-delimited string of files and directories on the command line.
+Added a CSVRenderer.
+Added a "-shortfilenames" argument to the PMD command line interface.
+Modified grammer to provide information on whether an initializer block is static.
+ASTViewer now shows node images and modifiers
+ASTViewer now saves last edited text to ~/.pmd_astviewer
+Moved the PMD Swing UI into a separate module - pmd-swingui.
+Updated license.txt to point to new location.
+
+
+
June 19, 2003 - 1.1:
+
+
Added new rules: FinalizeShouldBeProtected, FinalFieldCouldBeStatic, BeanMembersShouldSerializeRule
+Removed "verbose" attribute from PMD and CPD Ant tasks; now they use built in logging so you can do a "ant -verbose cpd" or "ant -verbose pmd". Thanks to Philippe T'Seyen for the code.
+Added "excludes" feature to rulesets; thanks to Gael Marziou for the suggestion.
+Removed "LinkedList" from LooseCouplingRule checks; thx to Randall Schulz for the suggestion.
+CPD now processes PHP code.
+Added VBHTMLRenderer; thanks to Vladimir Bossicard for the code.
+Added "Save" item to CPD GUI; thanks to mcclain looney for the patch.
+Fixed bug 732592 - Ant task now accepts a nested classpath element.
+Fixed bug 744915 - UseSingletonRule no longer fires on abstract classes, thanks to Pablo Casado for the bug report.
+Fixed bugs 735396 and 735399 - false positives from ConstructorCallsOverridableMethodRule
+Fixed bug 752809 - UnusedPrivateMethodRule now catches unused private static methods, thanks to Conrad Roche for the bug report.
+
+
+
April 17, 2003 - 1.05:
+
+
Added new rules: ReturnFromFinallyBlock, SimplifyBooleanExpressions
+Added a new Ant task for CPD; thanks to Andy Glover for the code.
+Added ability to specify a class name as a renderer on the command line or in the formatter "type" attribute of the Ant task.
+Brian Ewins completely rewrote CPD using a portion of the Burrows-Wheeler Transform - it's much, much, much faster now.
+Rebuilt parser with JavaCC 3.0; made several parser optimizations.
+The Ant task now accepts a <classpath> element to aid in loading custom rulesets. Thanks to Luke Francl for the suggestion.
+Fixed several bugs in UnnecessaryConstructorRule; thanks to Adam Nemeth for the reports and fixes.
+All test-data classes have been inlined into their respective JUnit tests.
+
+
+
March 21, 2003 - 1.04
+
+
Added new rules: ConstructorCallsOverridableMethodRule, AtLeastOneConstructorRule, JUnitAssertionsShouldIncludeMessageRule, DoubleCheckedLockingRule, ExcessivePublicCountRule, AccessorClassGenerationRule
+The Ant task has been updated; if you set "verbose=true" full stacktraces are printed. Thx to Paul Roebuck for the suggestion.
+Moved JUnit rules into their own package - "net.sourceforge.pmd.rules.junit".
+Incorporated new ResourceLoader; thanks to Dave Fuller
+Incorporated new XPath-based rule definitions; thanks to Dan Sheppard for the excellent work.
+Fixed bug 697187 - Problem with nested ifs
+Fixed bug 699287 - Grammar bug; good catch by David Whitmore
+
+
+
February 11, 2003 - 1.03
+
+
Added new rules: CyclomaticComplexityRule, AssignmentInOperandRule
+Added numbering to the HTMLRenderer; thx to Luke Francl for the code.
+Added an optional Ant task attribute 'failOnRuleViolation'. This stops the build if any rule violations are found.
+Added an XSLT script for processing the PMD XML report; thx to Mats for the code.
+The Ant task now determines whether the formatter toFile attribute is absolute or relative and routes the report appropriately.
+Moved several rules into a new "controversial" ruleset.
+Fixed bug 672742 - grammar typo was hosing up ASTConstructorDeclaration which was hosing up UseSingletonRule
+Fixed bug 674393 - OnlyOneReturn rule no longer counts returns that are inside anonymous inner classes as being inside the containing method. Thx to C. Lamont Gilbert for the bug report.
+Fixed bug 674420 - AvoidReassigningParametersRule no longer counts parameter field reassignment as a violation. Thx to C. Lamont Gilbert for the bug report.
+Fixed bug 673662 - The Ant task's "failOnError" attribute works again. Changed the semantics of this attribute, though, so it fails the build if errors occurred. A new attribute 'failOnRuleViolation' serves the purpose of stopping the build if rule violations are found.
+Fixed bug 676340 - Symbol table now creates new scope level when it encounters a switch statement. See the bug for code details; generally, this bug would have triggered runtime exceptions on certain blocks of code.
+Fixed bug 683465 - JavaCC parser no longer has ability to throw java.lang.Error; now it only throws java.lang.RuntimeExceptions. Thx to Gunnlaugur Thor Briem for a good discussion on this topic.
+Fixed bug in OverrideBothEqualsAndHashcodeRule - it no longer bails out with a NullPtrException on interfaces that declare a method signature "equals(Object)". Thx to Don Leckie for catching that.
+
+
+
January 22, 2003 - 1.02:
+
+
Added new rules: ImportFromSamePackageRule, SwitchDensityRule, NullAssignmentRule, UnusedModifierRule, ForLoopShouldBeWhileLoopRule
+Updated LooseCouplingRule to check for usage of Vector; thx to Vladimir for the good catch.
+Updated AvoidDuplicateLiteralsRule to report the line number of the first occurrence of the duplicate String.
+Modified Ant task to use a formatter element; this lets you render a report in several formats without having to rerun PMD.
+Added a new Ant task attribute - shortFilenames.
+Modified Ant task to ignore whitespace in the ruleset attribute
+Added rule priority settings.
+Added alternate row colorization to HTML renderer.
+Fixed bug 650623 - the Ant task now uses relative directories for the report file
+Fixed bug 656944 - PMD no longer prints errors to System.out, instead it just rethrows any exceptions
+Fixed bug 660069 - this was a symbol table bug; thanks to mcclain looney for the report.
+Fixed bug 668119 - OverrideBothEqualsAndHashcodeRule now checks the signature on equals(); thanks to mcclain looney for the report.
+
+
+
November 07 2002 - 1.01:
+
+
Fixed bug 633879: EmptyFinallyBlockRule now handles multiple catch blocks followed by a finally block.
+Fixed bug 633892: StringToStringRule false positive exposed problem in symbol table usage to declaration code.
+Fixed bug 617971: Statistical rules no longer produce tons of false positives due to accumulated results.
+Fixed bug 633209: OnlyOneReturn rule no longer requires the return stmt to be the last statement.
+Enhanced EmptyCatchBlockRule to flag multiple consecutive empty catch blocks.
+Renamed AvoidStringLiteralsRule to AvoidDuplicateLiteralsRule.
+Modified Ant task to truncate file paths to make the HTML output neater.
+
+
+
November 04 2002 - 1.0:
+
+
Added new rules: StringToStringRule, AvoidReassigningParametersRule, UnnecessaryConstructorRule, AvoidStringLiteralsRule
+Fixed bug 631010: AvoidDeeplyNestedIfStmtsRule works correctly with if..else stmts now
+Fixed bug 631605: OnlyOneReturn handles line spillover now.
+Moved AvoidDeeplyNestedIfStmts from the braces ruleset to the design ruleset.
+Moved several rules from the design ruleset to the codesize ruleset.
+Added a new "favorites" ruleset.
+
+
+
October 04 2002 - 1.0rc3:
+
+
Added new rules: OnlyOneReturnRule, JumbledIncrementerRule, AvoidDeeplyNestedIfStmtsRule
+PMD is now built and tested with JUnit 3.8.1 and Ant 1.5.
+Added support for IntelliJ's IDEAJ.
+Fixed bug 610018 - StringInstantiationRule now allows for String(byte[], int, int) usage.
+Fixed bug 610693 - UnusedPrivateInstanceVariable handles parameter shadowing better.
+Fixed bug 616535 - Command line interface input checking is better now.
+Fixed bug 616615 - Command line interface allows the text renderer to be used now
+Fixed a bug - the statistics rules now handle interfaces better.
+
+
+
September 12 2002 - 1.0rc2:
+
+
Added new rules: JUnitSpellingRule, JUnitStaticSuiteRule, StringInstantiationRule
+Added new rulesets - junit, strings.
+Added a printToConsole attribute to the Ant task so that you can see the report right there in the Ant output.
+Fixed bug in PMD GUI - rules are now saved correctly.
+Fixed bug 597916 - CPD line counts are accurate now.
+
+
+
September 09 2002 - 1.0rc1:
+
+
Added new rules: UnusedImportsRule, EmptySwitchStmtRule, SwitchStmtsShouldHaveDefaultRule, IfStmtsMustUseBracesRule
+Fixed bug 597813 - Rule properties are now parsed correctly
+Fixed bug 597905 - UseSingletonRule now resets its state correctly
+Moved several rules into a new ruleset - braces.
+Improved CPD by removing import statements and package statements from the token set.
+Added Metrics API to the Report.
+Updated PMD GUI.
+
+
+
August 16 2002 - 0.9:
+
+
Added new rules: LongParameterListRule, SimplifyBooleanReturnsRule
+Enhanced statistics rules to support various ways of triggering rule violations
+Added rule customization via XML parameters
+Enhanced CopyAndPasteDetector; added a GUI
+Fixed bug 592060 - UnusedPrivateInstanceVariable handles explicitly referenced statics correctly
+Fixed bug 593849 - UnusedPrivateInstanceVariable handles nested classes better
+
+
+
July 30 2002 - 0.8:
+
+
Added new rule: UnusedFormalParameterRule
+Fixed bug 588083 - ForLoopsNeedBraces rule correctly handles a variety of for statement formats
+Added prototype of the copy and paste detector
+
+
+
July 25 2002 - 0.7:
+
+
Added new rules: UnusedPrivateMethodRule, WhileLoopsMustUseBracesRule, ForLoopsMustUseBracesRule, LooseCouplingRule
+Fixed bug 583482 - EmptyCatchBlock and EmptyFinallyBlock no longer report an incorrect line number.
+
+
+
July 18 2002 - 0.6:
+
+
Added new rules: ExcessiveClassLength, ExcessiveMethodLength
+DuplicateImportsRule now reports the correct line number.
+Fixed bug 582639 - Rule violations are now reported on the proper line
+Fixed bug 582509 - Removed unneeded throws clause
+Fixed bug 583009 - Now rulesets.properties is in the jar file
+
+
+
July 15 2002 - 0.5:
+
+
Added new rules: DontImportJavaLangRule, DuplicateImportsRule
+Added new ruleset: rulesets/imports.xml
+Changed sorting of RuleViolations to group Files together.
+Changed XML Renderer to improved format.
+Created DVSL Stylesheet for the new format.
+Moved the Cougaar rules out of the PMD core.
+Fixed bug 580093 - OverrideBothEqualsAndHashcodeRule reports a more correct line number.
+Fixed bug 581853 - UnusedLocalVariableRule now handles anonymous inner classes correctly.
+Fixed bug 580278 - this was a side effect of bug 581853.
+Fixed bug 580123 - UnusedPrivateInstanceVariable now checks for instance variable usage in inner classes.
+
+
+
July 10 2002 - 0.4:
+
+
Added new rules: OverrideBothEqualsAndHashcodeRule, EmptyTryBlock, EmptyFinallyBlock
+Reports are now sorted by line number
+RuleSets can now reference rules in other RuleSets
+Fixed bug 579718 - made 'ruleset not found' error message clearer.
+
+
+
July 03 2002 - 0.3:
+
+
Added new rules: UseSingletonRule, ShortVariableRule, LongVariableRule, ShortMethodNameRule
+Moved rules into RuleSets which are defined in XML files in the ruleset directory
+Ant task:
+-Added a 'failonerror' attribute
+-Changed 'rulesettype' to 'rulesetfiles'
+-Removed 'text' report format; only 'html' and 'xml' are available now
+
+
+
June 27 2002 - 0.2:
+
+
Added new rules: IfElseStmtsMustUseBracesRule, EmptyWhileStmtRule
+Modified command line interface to accept a rule set
+Fixed bug in EmptyCatchBlockRule
+Fixed typo in UnnecessaryConversionTemporaryRule
+Moved Ant task to the net.sourceforge.pmd.ant package
+Added new HTML report format
+
The second parameter of System.assert/third parameter of System.assertEquals/System.assertNotEquals is a message.
+Having a second/third parameter provides more information and makes it easier to debug the test failure and
+improves the readability of test output.
@isTest
+publicclassFoo{
+ @isTest
+ staticvoidmethodATest(){
+ System.assertNotEquals('123',o.StageName);// not good
+ System.assertEquals('123',o.StageName,'OpportunitystageNameiswrong.');// good
+ System.assert(o.isClosed);// not good
+ System.assert(o.isClosed,'Opportunityisnotclosed.');// good
+ }
+}
+
Apex unit tests should include at least one assertion. This makes the tests more robust, and using assert
+with messages provide the developer a clearer idea of what the test does.
@isTest
+publicclassFoo{
+ publicstatictestMethodvoidtestSomething(){
+ Accounta=null;
+ // This is better than having a NullPointerException
+ // System.assertNotEquals(a, null, 'account not found');
+ a.toString();
+ }
+}
+
Apex test methods should have @isTest annotation.
+As testMethod keyword is deprecated, Salesforce advices to use @isTest annotation for test class/methods.
@isTest(seeAllData=true)
+publicclassFoo{
+ publicstatictestMethodvoidtestSomething(){
+ Accounta=null;
+ // This is better than having a NullPointerException
+ // System.assertNotEquals(a, null, 'account not found');
+ a.toString();
+ }
+}
+
Global classes should be avoided (especially in managed packages) as they can never be deleted or changed in signature. Always check twice if something needs to be global.
+Many interfaces (e.g. Batch) required global modifiers in the past but don’t require this anymore. Don’t lock yourself in.
As triggers do not allow methods like regular classes they are less flexible and suited to apply good encapsulation style.
+Therefore delegate the triggers work to a regular class (often called Trigger handler class).
@isTest
+publicclassFoo{
+ @isTest
+ staticvoidbar(){
+ System.debug('Heythiscodeexecuted.');// not good
+ System.debug(LoggingLevel.WARN,'Hey,somethingmightbewrong.');// good
+ System.debug(LoggingLevel.DEBUG,'Hey,somethinghappened.');// not good when on strict mode
+ }
+}
+
Configurable naming conventions for type declarations. This rule reports
+type declarations which do not match the regex that applies to their
+specific kind (e.g. enum or interface). Each regex can be configured through
+properties.
+
+
By default this rule uses the standard Apex naming convention (Pascal case).
Configurable naming conventions for field declarations. This rule reports variable declarations
+which do not match the regex that applies to their specific kind —e.g. constants (static final),
+static field, final field. Each regex can be configured through properties.
+
+
By default this rule uses the standard Apex naming convention (Camel case).
publicclassFoo{
+ IntegerinstanceField;// This is in camel case, so it's ok
+
+ IntegerINSTANCE_FIELD;// This will be reported unless you change the regex
+}
+
Avoid using ‘for’ statements without using surrounding braces. If the code formatting or
+indentation is lost then it becomes difficult to separate the code being controlled
+from the rest.
+
+
This rule is defined by the following XPath expression:
Configurable naming conventions for formal parameters of methods.
+This rule reports formal parameters which do not match the regex that applies to their
+specific kind (e.g. method parameter, or final method parameter). Each regex can be
+configured through properties.
+
+
By default this rule uses the standard Apex naming convention (Camel case).
publicclassFoo{
+ publicbar(IntegermethodParameter){}// This is in camel case, so it's ok
+
+ publicbaz(IntegerMETHOD_PARAMETER){}// This will be reported unless you change the regex
+}
+
Avoid using if..else statements without using surrounding braces. If the code formatting
+or indentation is lost then it becomes difficult to separate the code being controlled
+from the rest.
+
+
This rule is defined by the following XPath expression:
Avoid using if statements without using braces to surround the code block. If the code
+formatting or indentation is lost then it becomes difficult to separate the code being
+controlled from the rest.
+
+
This rule is defined by the following XPath expression:
Configurable naming conventions for local variable declarations.
+This rule reports variable declarations which do not match the regex that applies to their
+specific kind (e.g. local variable, or final local variable). Each regex can be configured through
+properties.
+
+
By default this rule uses the standard Apex naming convention (Camel case).
publicclassFoo{
+ publicFoo(){
+ IntegerlocalVariable;// This is in camel case, so it's ok
+
+ IntegerLOCAL_VARIABLE;// This will be reported unless you change the regex
+ }
+}
+
Configurable naming conventions for method declarations. This rule reports
+method declarations which do not match the regex that applies to their
+specific kind (e.g. static method, or test method). Each regex can be
+configured through properties.
+
+
By default this rule uses the standard Apex naming convention (Camel case).
publicclassFoo{
+ publicvoidinstanceMethod(){}// This is in camel case, so it's ok
+
+ publicvoidINSTANCE_METHOD(){}// This will be reported unless you change the regex
+
Apex allows the use of several variables declaration of the same type on one line. However, it
+can lead to quite messy code. This rule looks for several declarations on the same line.
+
+
This rule is defined by the following XPath expression:
Integera,b;// not recommended
+
+Integera,
+ b;// ok by default, can be flagged setting the strictMode property
+
+Integera;// preferred approach
+Integerb;
+
Configurable naming conventions for property declarations. This rule reports
+property declarations which do not match the regex that applies to their
+specific kind (e.g. static property, or instance property). Each regex can be
+configured through properties.
+
+
By default this rule uses the standard Apex naming convention (Camel case).
publicclassFoo{
+ publicIntegerinstanceProperty{get;set;}// This is in camel case, so it's ok
+
+ publicIntegerINSTANCE_PROPERTY{get;set;}// This will be reported unless you change the regex
+}
+
A variable naming conventions rule - customize this to your liking. Currently, it
+checks for final variables that should be fully capitalized and non-final variables
+that should not include underscores.
Avoid using ‘while’ statements without using braces to surround the code block. If the code
+formatting or indentation is lost then it becomes difficult to separate the code being
+controlled from the rest.
+
+
This rule is defined by the following XPath expression:
Methods that are highly complex are difficult to read and more costly to maintain. If you include too much decisional
+logic within a single method, you make its behavior hard to understand and more difficult to modify.
+
+
Cognitive complexity is a measure of how difficult it is for humans to read and understand a method. Code that contains
+a break in the control flow is more complex, whereas the use of language shorthands doesn’t increase the level of
+complexity. Nested control flows can make a method more difficult to understand, with each additional nesting of the
+control flow leading to an increase in cognitive complexity.
+
+
Information about Cognitive complexity can be found in the original paper here:
+https://www.sonarsource.com/docs/CognitiveComplexity.pdf
+
+
By default, this rule reports methods with a complexity of 15 or more. Reported methods should be broken down into less
+complex components.
The complexity of methods directly affects maintenance costs and readability. Concentrating too much decisional logic
+in a single method makes its behaviour hard to read and change.
+
+
Cyclomatic complexity assesses the complexity of a method by counting the number of decision points in a method,
+plus one for the method entry. Decision points are places where the control flow jumps to another place in the
+program. As such, they include all control flow statements, such as ‘if’, ‘while’, ‘for’, and ‘case’.
+
+
Generally, numbers ranging from 1-4 denote low complexity, 5-7 denote moderate complexity, 8-10 denote
+high complexity, and 11+ is very high complexity. By default, this rule reports methods with a complexity >= 10.
+Additionally, classes with many methods of moderate complexity get reported as well once the total of their
+methods’ complexities reaches 40, even if none of the methods was directly reported.
+
+
Reported methods should be broken down into several smaller methods. Reported classes should probably be broken down
+into subcomponents.
Excessive class file lengths are usually indications that the class may be burdened with excessive
+responsibilities that could be provided by external classes or functions. In breaking these methods
+apart the code becomes more managable and ripe for reuse.
Methods with numerous parameters are a challenge to maintain, especially if most of them share the
+same datatype. These situations usually denote the need for new objects to wrap the numerous parameters.
// too many arguments liable to be mixed up
+publicvoidaddPerson(IntegerbirthYear,IntegerbirthMonth,IntegerbirthDate,Integerheight,Integerweight,Integerssn){
+ // ...
+}
+// preferred approach
+publicvoidaddPerson(Datebirthdate,BodyMeasurementsmeasurements,intssn){
+ // ...
+}
+
Classes with large numbers of public methods and attributes require disproportionate testing efforts
+since combinational side effects grow rapidly and increase risk. Refactoring these classes into
+smaller ones not only increases testability and reliability but also allows new variations to be
+developed easily.
This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of lines
+of code for a given constructor. NCSS ignores comments, and counts actual statements. Using this algorithm,
+lines of code that are split are counted as one.
This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of lines
+of code for a given method. NCSS ignores comments, and counts actual statements. Using this algorithm,
+lines of code that are split are counted as one.
This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of lines
+of code for a given type. NCSS ignores comments, and counts actual statements. Using this algorithm,
+lines of code that are split are counted as one.
Complexity directly affects maintenance costs is determined by the number of decision points in a method
+plus one for the method entry. The decision points include ‘if’, ‘while’, ‘for’, and ‘case labels’ calls.
+Generally, numbers ranging from 1-4 denote low complexity, 5-7 denote moderate complexity, 8-10 denote
+high complexity, and 11+ is very high complexity.
Classes that have too many fields can become unwieldy and could be redesigned to have fewer fields,
+possibly through grouping related fields in new objects. For example, a class with individual
+city/state/zip fields could park them within a single Address field.
ApexDoc comments are present for classes, methods, and properties that are public or global, excluding
+overrides and test classes (as well as the contents of test classes).
+
ApexDoc comments should contain @description.
+
ApexDoc comments on non-void, non-constructor methods should contain @return.
+
ApexDoc comments on void or constructor methods should not contain @return.
+
ApexDoc comments on methods with parameters should contain @param for each parameter, in the same
+order as the method signature.
+
+
+
Method overrides and tests are both exempted from having ApexDoc.
Having DML operations in Apex class constructor or initializers can have unexpected side effects:
+By just accessing a page, the DML statements would be executed and the database would be modified.
+Just querying the database is permitted.
+
+
In addition to constructors and initializers, any method called init is checked as well.
+
+
Salesforce Apex already protects against this scenario and raises a runtime exception.
+
+
Note: This rule has been moved from category "Security" to "Error Prone" with PMD 6.21.0, since
+using DML in constructors is not a security problem, but crashes the application.
Avoid directly accessing Trigger.old and Trigger.new as it can lead to a bug. Triggers should be bulkified and iterate through the map to handle the actions for each item separately.
+
+
This rule is defined by the following XPath expression:
When deploying Apex code between sandbox and production environments, or installing Force.com AppExchange packages,
+it is essential to avoid hardcoding IDs in the Apex code. By doing so, if the record IDs change between environments,
+the logic can dynamically identify the proper data to operate against and not fail.
publicwithoutsharingclassFoo{
+ voidfoo(){
+ //Error - hardcoded the record type id
+ if(a.RecordTypeId=='012500000009WAr'){
+ //do some logic here.....
+ }elseif(a.RecordTypeId=='0123000000095Km'){
+ //do some logic here for a different record type...
+ }
+ }
+}
+
Apex supported non existent annotations for legacy reasons.
+In the future, use of such non-existent annotations could result in broken apex code that will not compile.
+This will prevent users of garbage annotations from being able to use legitimate annotations added to Apex in the future.
+A full list of supported annotations can be found at https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_annotation.htm
Empty Catch Block finds instances where an exception is caught, but nothing is done.
+In most circumstances, this swallows an exception which should either be acted on
+or reported.
+
+
This rule is defined by the following XPath expression:
Empty While Statement finds all instances where a while statement does nothing.
+If it is a timing loop, then you should use Thread.sleep() for it; if it is
+a while loop that does a lot in the exit expression, rewrite it to make it clearer.
+
+
This rule is defined by the following XPath expression:
publicclassMyClass{
+ // this is OK because it is a constructor
+ publicMyClass(){}
+ // this is bad because it is a method
+ publicvoidMyClass(){}
+}
+
Test methods marked as a testMethod or annotated with @IsTest,
+but not residing in a test class should be moved to a proper
+class or have the @IsTest annotation added to the class.
+
+
Support for tests inside functional classes was removed in Spring-13 (API Version 27.0),
+making classes that violate this rule fail compile-time. This rule is mostly usable when
+dealing with legacy code.
+
+
This rule is defined by the following XPath expression:
Avoid DML statements inside loops to avoid hitting the DML governor limit. Instead, try to batch up the data into a list and invoke your DML once on that list of data outside the loop.
+
+
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
+by the more general rule OperationWithLimitsInLoop.
Database class methods, DML operations, SOQL queries, or SOSL queries within loops can cause governor limit exceptions. Instead, try to batch up the data into a list and invoke the operation once on that list of data outside the loop.
The rule makes sure you are using randomly generated IVs and keys for Crypto calls.
+Hard-wiring these values greatly compromises the security of encrypted data.
The rule validates you are checking for access permissions before a SOQL/SOSL/DML operation.
+Since Apex runs in system mode not having proper permissions checks results in escalation of
+privilege and may produce runtime errors. This check forces you to handle such scenarios.
The rule has been moved to another ruleset. Use instead: ApexCSRF
+
+
Deprecated
+
+
Since: PMD 5.5.3
+
+
Priority: Medium (3)
+
+
Having DML operations in Apex class constructor or initializers can have unexpected side effects:
+By just accessing a page, the DML statements would be executed and the database would be modified.
+Just querying the database is permitted.
+
+
In addition to constructors and initializers, any method called init is checked as well.
+
+
Salesforce Apex already protects against this scenario and raises a runtime exception.
+
+
Note: This rule has been moved from category "Security" to "Error Prone" with PMD 6.21.0, since
+using DML in constructors is not a security problem, but crashes the application.
Against FinancialForce’s Configuration.disableTriggerCRUDSecurity(). Disabling CRUD security
+opens the door to several attacks and requires manual validation, which is unreliable.
+
Calling System.debug passing sensitive data as parameter, which could lead to exposure
+of private data.
Detect classes declared without explicit sharing mode if DML methods are used. This
+forces the developer to take access restrictions into account before modifying objects.
Reports on calls to addError with disabled escaping. The message passed to addError
+will be displayed directly to the user in the UI, making it prime ground for XSS
+attacks if unescaped.
ECMAScript does provide for return types on functions, and therefore there is no solid rule as to their usage.
+However, when a function does use returns they should all have a value, or all with no value. Mixed return
+usage is likely a bug, or at best poor style.
This rule helps to avoid using accidently global variables by simply missing the "var" declaration.
+Global variables can lead to side-effects that are hard to debug.
+
+
This rule is defined by the following XPath expression:
+
//Assignment[Name/@GlobalName=true()]
+
+
+
Example(s):
+
+
function(arg){
+ notDeclaredVariable=1;// this will create a global variable and trigger the rule
+
+ varsomeVar=1;// this is a local variable, that's ok
+
+ window.otherGlobal=2;// this will not trigger the rule, although it is a global variable.
+}
+
A for-in loop in which the variable name is not explicitly scoped to the enclosing scope with the ‘var’ keyword can
+refer to a variable in an enclosing scope outside the nearest enclosing scope. This will overwrite the
+existing value of the variable in the outer scope when the body of the for-in is evaluated. When the for-in loop
+has finished, the variable will contain the last value used in the for-in, and the original value from before
+the for-in loop will be gone. Since the for-in variable name is most likely intended to be a temporary name, it
+is better to explicitly scope the variable name to the nearest enclosing scope with ‘var’.
+
+
This rule is defined by the following XPath expression:
This rule checks for usages of parseInt. While the second parameter is optional and usually defaults
+to 10 (base/radix is 10 for a decimal number), different implementations may behave differently.
+It also improves readability, if the base is given.
Avoid assignments in operands; this can make code more complicated and harder to read. This is sometime
+indicative of the bug where the assignment operator ‘=’ was used instead of the equality operator ‘==’.
+
+
This rule is defined by the following XPath expression:
An unnecessary Block is present. Such Blocks are often used in other languages to
+introduce a new variable scope. Blocks do not behave like this in ECMAScipt, and using them can
+be misleading. Considering removing this unnecessary Block.
+
+
This rule is defined by the following XPath expression:
A ‘return’, ‘break’, ‘continue’, or ‘throw’ statement should be the last in a block. Statements after these
+will never execute. This is a bug, or extremely poor style.
+
+
This rule is defined by the following XPath expression:
function(arg){
+ varobj1={a:1};// Ok
+ vararr1=[1,2];// Ok
+
+ varobj2={a:1,};// Syntax error in some browsers!
+ vararr2=[1,2,];// Length 2 or 3 depending on the browser!
+}
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
allowObjectLiteral
+
false
+
Allow a trailing comma within an object literal
+
no
+
+
+
allowArrayLiteral
+
false
+
Allow a trailing comma within an array literal
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
Using == in condition may lead to unexpected results, as the variables are automatically casted to be of the
+same type. The === operator avoids the casting.
+
+
This rule is defined by the following XPath expression:
+
//InfixExpression[
+ (@Image="=="or@Image="!=")
+ and
+ (KeywordLiteral[@Image='true'or@Image='false']orNumberLiteral)
+]
+
+
+
Example(s):
+
+
// Ok
+if(someVar===true){
+ ...
+}
+// Ok
+if(someVar!==3){
+ ...
+}
+// Bad
+if(someVar==true){
+ ...
+}
+// Bad
+if(someVar!=3){
+ ...
+}
+
The numeric literal will have a different value at runtime, which can happen if you provide too much
+precision in a floating point number. This may result in numeric calculations being in error.
+
+
This rule is defined by the following XPath expression:
vara=9;// Ok
+varb=999999999999999;// Ok
+varc=999999999999999999999;// Not good
+varw=1.12e-4;// Ok
+varx=1.12;// Ok
+vary=1.1234567890123;// Ok
+varz=1.12345678901234567;// Not good
+
The abstract class does not contain any abstract methods. An abstract class suggests
+an incomplete implementation, which is to be completed by subclasses implementing the
+abstract methods. If the class is intended to be used as a base class only (not to be instantiated
+directly) a protected constructor can be provided prevent direct instantiation.
Instantiation by way of private constructors from outside of the constructor’s class often causes the
+generation of an accessor. A factory method, or non-privatization of the constructor can eliminate this
+situation. The generated class file is actually an interface. It gives the accessing class the ability
+to invoke a new hidden package scope constructor that takes the interface as a supplementary parameter.
+This turns a private constructor effectively into one with package scope, and is challenging to discern.
When accessing a private field / method from another class, the Java compiler will generate a accessor methods
+with package-private visibility. This adds overhead, and to the dex method count on Android. This situation can
+be avoided by changing the visibility of the field / method from private to package-private.
Constructors and methods receiving arrays should clone objects and store the copy.
+This prevents future changes from the user from affecting the original array.
Declaring a MessageDigest instance as a field make this instance directly available to multiple threads.
+Such sharing of MessageDigest instances should be avoided if possible since it leads to wrong results
+if the access is not synchronized correctly.
+Just create a new instance and use it locally, where you need it.
+Creating a new instance is easier than synchronizing access to a shared instance.
+
+
This rule is defined by the following XPath expression:
Reassigning exception variables caught in a catch statement should be avoided because of:
+
+
1) If it is needed, multi catch can be easily added and code will still compile.
+
+
2) Following the principle of least surprise we want to make sure that a variable caught in a catch statement
+is always the one thrown in a try block.
Reassigning loop variables can lead to hard-to-find bugs. Prevent or limit how these variables can be changed.
+
+
In foreach-loops, configured by the foreachReassign property:
+
+
deny: Report any reassignment of the loop variable in the loop body. This is the default.
+
allow: Don’t check the loop variable.
+
firstOnly: Report any reassignments of the loop variable, except as the first statement in the loop body.
+ This is useful if some kind of normalization or clean-up of the value before using is permitted, but any other change of the variable is not.
+
+
+
In for-loops, configured by the forReassign property:
+
+
deny: Report any reassignment of the control variable in the loop body. This is the default.
+
allow: Don’t check the control variable.
+
skip: Report any reassignments of the control variable, except conditional increments/decrements (++, --, +=, -=).
+ This prevents accidental reassignments or unconditional increments of the control variable.
Always check the return values of navigation methods (next, previous, first, last) of a ResultSet.
+If the value return is ‘false’, it should be handled properly.
Statementstat=conn.createStatement();
+ResultSetrst=stat.executeQuery("SELECT name FROM person");
+rst.next();// what if it returns false? bad form
+StringfirstName=rst.getString(1);
+
+Statementstat=conn.createStatement();
+ResultSetrst=stat.executeQuery("SELECT name FROM person");
+if(rst.next()){// result is properly examined and used
+ StringfirstName=rst.getString(1);
+ }else{
+ // handle missing data
+}
+
Avoid constants in interfaces. Interfaces should define types, constants are implementation details
+better placed in classes or enums. See Effective Java, item 19.
+
+
This rule is defined by the following XPath expression:
publicclassFoo{
+ voidbar(inta){
+ switch(a){
+ case1:// do something
+ break;
+ default:// the default case should be last, by convention
+ break;
+ case2:
+ break;
+ }
+ }
+}
+
Double brace initialisation is a pattern to initialise eg collections concisely. But it implicitly
+generates a new .class file, and the object holds a strong reference to the enclosing object. For those
+reasons, it is preferable to initialize the object normally, even though it’s verbose.
+
+
This rule counts any anonymous class which only has a single initializer as an instance of double-brace
+initialization. There is currently no way to find out whether a method called in the initializer is not
+accessible from outside the anonymous class, and those legit cases should be suppressed for the time being.
+
+
This rule is defined by the following XPath expression:
// this is double-brace initialization
+returnnewArrayList<String>(){{
+ add("a");
+ add("b");
+ add("c");
+}};
+
+// the better way is to not create an anonymous class:
+List<String>a=newArrayList<>();
+a.add("a");
+a.add("b");
+a.add("c");
+returna;
+
Reports loops that can be safely replaced with the foreach syntax. The rule considers loops over
+lists, arrays and iterators. A loop is safe to replace if it only uses the index variable to
+access an element of the list or array, only has one update statement, and loops through every
+element of the list or array left to right.
Having a lot of control variables in a ‘for’ loop makes it harder to see what range of values
+the loop iterates over. By default this rule allows a regular ‘for’ loop with only one variable.
+
+
This rule is defined by the following XPath expression:
In JUnit 3, the tearDown method was used to clean up all data entities required in running tests.
+JUnit 4 skips the tearDown method and executes all methods annotated with @After after running each test.
+JUnit 5 introduced @AfterEach and @AfterAll annotations to execute methods after each test or after all tests in the class, respectively.
+
+
This rule is defined by the following XPath expression:
In JUnit 3, the setUp method was used to set up all data entities required in running tests.
+JUnit 4 skips the setUp method and executes all methods annotated with @Before before all tests.
+JUnit 5 introduced @BeforeEach and @BeforeAll annotations to execute methods before each test or before all tests in the class, respectively.
+
+
This rule is defined by the following XPath expression:
In JUnit 3, the framework executed all methods which started with the word test as a unit test.
+In JUnit 4, only methods annotated with the @Test annotation are executed.
+In JUnit 5, one of the following annotations should be used for tests: @Test, @RepeatedTest, @TestFactory, @TestTemplate or @ParameterizedTest.
+
+
This rule is defined by the following XPath expression:
Unit tests should not contain too many asserts. Many asserts are indicative of a complex test, for which
+it is harder to verify correctness. Consider breaking the test scenario into multiple, shorter test scenarios.
+Customize the maximum number of assertions used by this Rule to suit your needs.
+
+
This rule checks for JUnit4, JUnit5 and TestNG Tests, as well as methods starting with "test".
+
+
This rule is defined by the following XPath expression:
JUnit tests should include at least one assertion. This makes the tests more robust, and using assert
+with messages provide the developer a clearer idea of what the test does.
publicclassFooextendsTestCase{
+ publicvoidtestSomething(){
+ Barb=findBar();
+ // This is better than having a NullPointerException
+ // assertNotNull("bar not found", b);
+ b.work();
+ }
+}
+
Position literals first in all String comparisons, if the second argument is null then NullPointerExceptions
+can be avoided, they will just return false. Note that switching literal positions for compareTo and
+compareToIgnoreCase may change the result, see examples.
The use of implementation types (i.e., HashSet) as object references limits your ability to use alternate
+implementations in the future as requirements change. Whenever available, referencing objects
+by their interface types (i.e, Set) provides much more flexibility.
Exposing internal arrays to the caller violates object encapsulation since elements can be
+removed or replaced outside of the object that owns it. It is safer to return a copy of the array.
Annotating overridden methods with @Override ensures at compile time that
+the method really overrides one, which helps refactoring and clarifies intent.
Java allows the use of several variables declaration of the same type on one line. However, it
+can lead to quite messy code. This rule looks for several declarations on the same line.
+
+
This rule is defined by the following XPath expression:
Stringname;// separate declarations
+Stringlastname;
+
+Stringname,lastname;// combined declaration, a violation
+
+Stringname,
+ lastname;// combined declaration on multiple lines, no violation by default.
+ // Set property strictMode to true to mark this as violation.
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
strictMode
+
false
+
If true, mark combined declaration even if the declarations are on separate lines.
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
Throwing a new exception from a catch block without passing the original exception into the
+new exception will cause the original stack trace to be lost making it difficult to debug
+effectively.
References to System.(out|err).print are usually intended for debugging purposes and can remain in
+the codebase even in production code. By using a logger one can enable/disable this behaviour at
+will (and by priority) and avoid clogging the Standard out log.
+
+
This rule is defined by the following XPath expression:
+
//Name[
+ starts-with(@Image,'System.out.print')
+ or
+ starts-with(@Image,'System.err.print')
+ ]
+
+
+
Example(s):
+
+
classFoo{
+ Loggerlog=Logger.getLogger(Foo.class.getName());
+ publicvoidtestA(){
+ System.out.println("Entering test");
+ // Better use this
+ log.fine("Entering test");
+ }
+}
+
Reports assignments to variables that are never used before the variable is overwritten,
+or goes out of scope. Unused assignments are those for which
+
+
The variable is never read after the assignment, or
+
The assigned value is always overwritten by other assignments before the next read of
+the variable.
+
+
+
The rule doesn’t consider assignments to fields except for those of this in a constructor,
+or static fields of the current class in static initializers.
+
+
The rule may be suppressed with the standard @SuppressWarnings("unused") tag.
+
+
The rule subsumes UnusedLocalVariable, and UnusedFormalParameter.
+Those violations are filtered
+out by default, in case you already have enabled those rules, but may be enabled with the property
+reportUnusedVariables. Variables whose name starts with ignored are filtered out, as
+is standard practice for exceptions.
+
+
Limitations:
+
+
The rule currently cannot know which method calls throw exceptions, or which exceptions they throw.
+In the body of a try block, every method or constructor call is assumed to throw. This may cause false-negatives.
+The only other language construct that is assumed to throw is the throw statement, in particular,
+things like assert statements, or NullPointerExceptions on dereference are ignored.
+
The rule cannot resolve assignments across constructors, when they’re called with the special
+this(...) syntax. This may cause false-negatives.
+
+
+
Both of those limitations may be partly relaxed in PMD 7.
classA{
+ // this field initializer is redundant,
+ // it is always overwritten in the constructor
+ intf=1;
+
+ A(intf){
+ this.f=f;
+ }
+ }
+
+
+
classB{
+
+ intmethod(inti,intj){
+ // this initializer is redundant,
+ // it is overwritten in all branches of the `if`
+ intk=0;
+
+ // Both the assignments to k are unused, because k is
+ // not read after the if/else
+ // This may hide a bug: the programmer probably wanted to return k
+ if(i<j)
+ k=i;
+ else
+ k=j;
+
+ returnj;
+ }
+
+}
+
+
+
classC{
+
+ intmethod(){
+ inti=0;
+
+ checkSomething(++i);
+ checkSomething(++i);
+ checkSomething(++i);
+ checkSomething(++i);
+
+ // That last increment is not reported unless
+ // the property `checkUnusedPrefixIncrement` is
+ // set to `true`
+ // Technically it could be written (i+1), but it
+ // is not very important
+ }
+
+}
+
+
+
classC{
+
+ // variables that are truly unused (at most assigned to, but never accessed)
+ // are only reported if property `reportUnusedVariables` is true
+
+ voidmethod(intparam){}// for example this method parameter
+
+ // even then, you can suppress the violation with an annotation:
+
+ voidmethod(@SuppressWarning("unused")intparam){}// no violation, even if `reportUnusedVariables` is true
+
+ // For catch parameters, or for resources which don't need to be used explicitly,
+ // you can give a name that starts with "ignored" to ignore such warnings
+
+ {
+ try(Somethingignored=Something.create()){
+ // even if ignored is unused, it won't be flagged
+ // its purpose might be to side-effect in the create/close routines
+
+ }catch(Exceptione){// this is unused and will cause a warning if `reportUnusedVariables` is true
+ // you should choose a name that starts with "ignored"
+ return;
+ }
+ }
+
+}
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
checkUnusedPrefixIncrement
+
false
+
Report expressions like ++i that may be replaced with (i + 1)
+
no
+
+
+
reportUnusedVariables
+
false
+
Report variables that are only initialized, and never read at all. The rule UnusedVariable already cares for that, but you can enable it if needed
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
Avoid passing parameters to methods or constructors without actually referencing them in the method body.
+Removing unused formal parameters from public methods could cause a ripple effect through the code base.
+Hence, by default, this rule only considers private methods. To include non-private methods, set the
+checkAll property to true.
This rule detects JUnit assertions in object references equality. These assertions should be made by
+more specific methods, like assertNull, assertNotNull.
+
+
This rule is defined by the following XPath expression:
This rule detects JUnit assertions in object references equality. These assertions should be made
+by more specific methods, like assertSame, assertNotSame.
+
+
This rule is defined by the following XPath expression:
publicclassMyTestCaseextendsTestCase{
+ publicvoidtestMyCase(){
+ booleanmyVar=true;
+ // Ok
+ assertTrue("myVar is true",myVar);
+ // Bad
+ assertEquals("myVar is true",true,myVar);
+ // Bad
+ assertEquals("myVar is false",false,myVar);
+ // Bad
+ assertEquals("myVar is true",Boolean.TRUE,myVar);
+ // Bad
+ assertEquals("myVar is false",Boolean.FALSE,myVar);
+ }
+}
+
The isEmpty() method on java.util.Collection is provided to determine if a collection has any elements.
+Comparing the value of size() to 0 does not convey intent as well as the isEmpty() method.
Java 7 introduced the try-with-resources statement. This statement ensures that each resource is closed at the end
+of the statement. It avoids the need of explicitly closing the resources in a finally block. Additionally exceptions
+are better handled: If an exception occurred both in the try block and finally block, then the exception from
+the try block was suppressed. With the try-with-resources statement, the exception thrown from the try-block is
+preserved.
+
+
This rule is defined by the following XPath expression:
Java 5 introduced the varargs parameter declaration for methods and constructors. This syntactic
+sugar provides flexibility for users of these methods and constructors, allowing them to avoid
+having to deal with the creation of an array.
+
+
This rule is defined by the following XPath expression:
do {} while (true); requires reading the end of the statement before it is
+apparent that it loops forever, whereas while (true) {} is easier to understand.
+
+
do {} while (false); is redundant, and if an inner variable scope is required,
+a block {} is sufficient.
+
+
while (false) {} will never execute the block and can be removed in its entirety.
+
+
This rule is defined by the following XPath expression:
Each non-static class should declare at least one constructor.
+Classes with solely static members are ignored, refer to UseUtilityClassRule to detect those.
Avoid using final local variables, turn them into fields.
+
+
Note that this is a controversial rule which is merely useful to enforce a certain code style
+(which is contradictory to good coding practices in most of the cases it’s applied to) and
+avoid local literals being declared in a scope smaller than the class.
+
+
Also note, that this rule is the opposite of LocalVariableCouldBeFinal.
+Having both rules enabled results in contradictory violations being reported.
+
+
This rule is deprecated and will be removed with PMD 7.0.0. There is no replacement planned.
+If the goal is to avoid defining constants in a scope smaller than the class, then the rule
+AvoidDuplicateLiterals should be used instead.
+
+
This rule is defined by the following XPath expression:
+
//LocalVariableDeclaration[
+ @Final=true()
+ andnot(../../ForStatement)
+ and
+ (
+ (count(VariableDeclarator/VariableInitializer)=0)
+ or
+ (VariableDeclarator/VariableInitializer/Expression/PrimaryExpression/PrimaryPrefix/Literal)
+ )
+]
+
Prefixing parameters by ‘in’ or ‘out’ pollutes the name of the parameters and reduces code readability.
+To indicate whether or not a parameter will be modify in a method, its better to document method
+behavior with Javadoc.
+
+
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
+by the more general rule FormalParameterNamingConventions.
+
+
This rule is defined by the following XPath expression:
Do not use protected fields in final classes since they cannot be subclassed.
+Clarify your intent by using private or package access modifiers instead.
+
+
This rule is defined by the following XPath expression:
Do not use protected methods in most final classes since they cannot be subclassed. This should
+only be allowed in final classes that extend other classes with protected methods (whose
+visibility cannot be reduced). Clarify your intent by using private or package access modifiers instead.
+
+
This rule is defined by the following XPath expression:
publicfinalclassFoo{
+ privateintbar(){}
+ protectedintbaz(){}// Foo cannot be subclassed, and doesn't extend anything, so is baz() really private or package visible?
+}
+
Methods that return boolean results should be named as predicate statements to denote this.
+I.e, ‘isReady()’, ‘hasValues()’, ‘canCommit()’, ‘willFail()’, etc. Avoid the use of the ‘get’
+prefix for these methods.
+
+
This rule is defined by the following XPath expression:
It is a good practice to call super() in a constructor. If super() is not called but
+another constructor (such as an overloaded constructor) is called, this rule will not report it.
+
+
This rule is defined by the following XPath expression:
publicclassFooextendsBar{
+ publicFoo(){
+ // call the constructor of Bar
+ super();
+ }
+ publicFoo(intcode){
+ // do something with code
+ this();
+ // no problem with this
+ }
+}
+
Configurable naming conventions for type declarations. This rule reports
+type declarations which do not match the regex that applies to their
+specific kind (e.g. enum or interface). Each regex can be configured through
+properties.
+
+
By default this rule uses the standard Java naming convention (Pascal case),
+and reports utility class names not ending with ‘Util’.
// This is Pascal case, the recommended naming convention in Java
+// Note that the default values of this rule don't allow underscores
+// or accented characters in type names
+publicclassFooBar{}
+
+// You may want abstract classes to be named 'AbstractXXX',
+// in which case you can customize the regex for abstract
+// classes to 'Abstract[A-Z]\w+'
+publicabstractclassThing{}
+
+// This class doesn't respect the convention, and will be flagged
+publicclassÉléphant{}
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
classPattern
+
[A-Z][a-zA-Z0-9]*
+
Regex which applies to concrete class names
+
no
+
+
+
abstractClassPattern
+
[A-Z][a-zA-Z0-9]*
+
Regex which applies to abstract class names
+
no
+
+
+
interfacePattern
+
[A-Z][a-zA-Z0-9]*
+
Regex which applies to interface names
+
no
+
+
+
enumPattern
+
[A-Z][a-zA-Z0-9]*
+
Regex which applies to enum names
+
no
+
+
+
annotationPattern
+
[A-Z][a-zA-Z0-9]*
+
Regex which applies to annotation names
+
no
+
+
+
utilityClassPattern
+
[A-Z][a-zA-Z0-9]+(Utils?|Helper|Constants)
+
Regex which applies to utility class names
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
To avoid mistakes if we want that an Annotation, Class, Enum, Method, Constructor or Field have a default access modifier
+we must add a comment at the beginning of it’s declaration.
+By default the comment must be /* default */ or /* package */, if you want another, you have to provide a regular expression.
+This rule ignores by default all cases that have a @VisibleForTesting annotation. Use the
+property "ignoredAnnotations" to customize the recognized annotations.
Avoid negation within an "if" expression with an "else" clause. For example, rephrase:
+if (x != y) diff(); else same(); as: if (x == y) same(); else diff();.
+
+
Most "if (x != y)" cases without an "else" are often return cases, so consistent use of this
+rule makes the code easier to read. Also, this resolves trivial ordering problems, such
+as "does the error case go first?" or "does the common case go first?".
Enforce a policy for braces on control statements. It is recommended to use braces on ‘if … else’
+statements and loop statements, even if they are optional. This usually makes the code clearer, and
+helps prepare the future when you need to add another statement. That said, this rule lets you control
+which statements are required to have braces via properties.
+
+
From 6.2.0 on, this rule supersedes WhileLoopMustUseBraces, ForLoopMustUseBraces, IfStmtMustUseBraces,
+and IfElseStmtMustUseBraces.
+
+
This rule is defined by the following XPath expression:
+
//WhileStatement[$checkWhileStmtandnot(Statement/Block)andnot($allowEmptyLoopandStatement/EmptyStatement)]
+ |
+ //ForStatement[$checkForStmtandnot(Statement/Block)andnot($allowEmptyLoopandStatement/EmptyStatement)]
+ |
+ //DoStatement[$checkDoWhileStmtandnot(Statement/Block)andnot($allowEmptyLoopandStatement/EmptyStatement)]
+ |
+ (: The violation is reported on the sub statement -- not the if statement :)
+ //Statement[$checkIfElseStmtandparent::IfStatementandnot(child::Blockorchild::IfStatement)
+ (: Whitelists single if statements :)
+ and($checkSingleIfStmt
+ (: Inside this not(...) is the definition of a "single if statement" :)
+ ornot(count(../Statement)=1(: No else stmt :)
+ (: Not the last branch of an 'if ... else if' chain :)
+ andnot(parent::IfStatement[parent::Statement[parent::IfStatement]])))]
+ |
+ (: Reports case labels if one of their subordinate statements is not braced :)
+ //SwitchLabel[$checkCaseStmt]
+ [count(following-sibling::BlockStatementexceptfollowing-sibling::SwitchLabel[1]/following-sibling::BlockStatement)>1
+ or(some$stmt(: in only the block statements until the next label :)
+ infollowing-sibling::BlockStatementexceptfollowing-sibling::SwitchLabel[1]/following-sibling::BlockStatement
+ satisfiesnot($stmt/Statement/Block))]
+
Use explicit scoping instead of accidental usage of default package private level.
+The rule allows methods and fields annotated with Guava’s @VisibleForTesting and JUnit 5’s annotations.
+
+
This rule is defined by the following XPath expression:
importjava.lang.String;// this is unnecessary
+
+publicclassFoo{}
+
+// --- in another source code file...
+
+importjava.lang.*;// this is bad
+
+publicclassFoo{}
+
Empty or auto-generated methods in an abstract class should be tagged as abstract. This helps to remove their inapproprate
+usage by developers who should be implementing their own versions in the concrete subclasses.
+
+
This rule is defined by the following XPath expression:
+
//ClassOrInterfaceDeclaration[@Abstract=true()]
+ /ClassOrInterfaceBody
+ /ClassOrInterfaceBodyDeclaration
+ /MethodDeclaration[@Abstract=false()and@Native=false()]
+ [
+ (boolean(./Block[count(./BlockStatement)=1]/BlockStatement/Statement/ReturnStatement/Expression/PrimaryExpression/PrimaryPrefix/Literal/NullLiteral)=true())
+ or
+ (boolean(./Block[count(./BlockStatement)=1]/BlockStatement/Statement/ReturnStatement/Expression/PrimaryExpression/PrimaryPrefix/Literal[@Image='0'])=true())
+ or
+ (boolean(./Block[count(./BlockStatement)=1]/BlockStatement/Statement/ReturnStatement/Expression/PrimaryExpression/PrimaryPrefix/Literal[string-length(@Image)=2])=true())
+ or
+ (./Block[count(./BlockStatement)=1]/BlockStatement/Statement/EmptyStatement)
+ or
+ (not(./Block/*))
+ ]
+
Configurable naming conventions for field declarations. This rule reports variable declarations
+which do not match the regex that applies to their specific kind —e.g. constants (static final),
+enum constant, final field. Each regex can be configured through properties.
+
+
By default this rule uses the standard Java naming convention (Camel case), and uses the ALL_UPPER
+convention for constants and enum constants.
classFoo{
+ intmyField=1;// This is in camel case, so it's ok
+ intmy_Field=1;// This contains an underscore, it's not ok by default
+ // but you may allow it, or even require the "my_" prefix
+
+ finalintFinalField=1;// you may configure a different convention for final fields,
+ // e.g. here PascalCase: [A-Z][a-zA-Z0-9]*
+
+ interfaceInterface{
+ doublePI=3.14;// interface "fields" use the constantPattern property
+ }
+
+ enumAnEnum{
+ ORG,NET,COM;// These use a separate property but are set to ALL_UPPER by default
+ }
+ }
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
publicConstantPattern
+
[A-Z][A-Z_0-9]*
+
Regex which applies to public constant names
+
no
+
+
+
constantPattern
+
[A-Z][A-Z_0-9]*
+
Regex which applies to non-public static final field names
+
no
+
+
+
enumConstantPattern
+
[A-Z][A-Z_0-9]*
+
Regex which applies to enum constant names
+
no
+
+
+
finalFieldPattern
+
[a-z][a-zA-Z0-9]*
+
Regex which applies to final field names
+
no
+
+
+
staticFieldPattern
+
[a-z][a-zA-Z0-9]*
+
Regex which applies to static field names
+
no
+
+
+
defaultFieldPattern
+
[a-z][a-zA-Z0-9]*
+
Regex which applies to field names
+
no
+
+
+
exclusions
+
serialVersionUID | serialPersistentFields
+
Names of fields to whitelist.
+
yes. Delimiter is ‘|’.
+
+
+
+
+
Use this rule with the default properties by just referencing it:
Avoid using ‘for’ statements without using curly braces. If the code formatting or
+indentation is lost then it becomes difficult to separate the code being controlled
+from the rest.
+
+
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
+by the rule ControlStatementBraces.
+
+
This rule is defined by the following XPath expression:
Configurable naming conventions for formal parameters of methods and lambdas.
+This rule reports formal parameters which do not match the regex that applies to their
+specific kind (e.g. lambda parameter, or final formal parameter). Each regex can be
+configured through properties.
+
+
By default this rule uses the standard Java naming convention (Camel case).
classFoo{
+
+ abstractvoidbar(intmyInt);// This is Camel case, so it's ok
+
+ voidbar(intmy_i){// this will be reported
+
+ }
+
+ voidlambdas(){
+
+ // lambdas parameters can be configured separately
+ Consumer<String>lambda1=s_str->{};
+
+ // lambda parameters with an explicit type can be configured separately
+ Consumer<String>lambda1=(Stringstr)->{};
+
+ }
+
+ }
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
methodParameterPattern
+
[a-z][a-zA-Z0-9]*
+
Regex which applies to formal parameter names
+
no
+
+
+
finalMethodParameterPattern
+
[a-z][a-zA-Z0-9]*
+
Regex which applies to final formal parameter names
+
no
+
+
+
lambdaParameterPattern
+
[a-z][a-zA-Z0-9]*
+
Regex which applies to inferred-type lambda parameter names
+
no
+
+
+
explicitLambdaParameterPattern
+
[a-z][a-zA-Z0-9]*
+
Regex which applies to explicitly-typed lambda parameter names
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
Names for references to generic values should be limited to a single uppercase letter.
+
+
This rule is defined by the following XPath expression:
+
//TypeDeclaration/ClassOrInterfaceDeclaration/TypeParameters/TypeParameter[
+ string-length(@Image)>1
+ or
+ upper-case(@Image)!=@Image
+]
+
+
+
Example(s):
+
+
publicinterfaceGenericDao<EextendsBaseModel,KextendsSerializable>extendsBaseDao{
+ // This is ok...
+}
+
+publicinterfaceGenericDao<EextendsBaseModel,KextendsSerializable>{
+ // Also this
+}
+
+publicinterfaceGenericDao<eextendsBaseModel,KextendsSerializable>{
+ // 'e' should be an 'E'
+}
+
+publicinterfaceGenericDao<EFextendsBaseModel,KextendsSerializable>{
+ // 'EF' is not ok.
+}
+
Identical catch branches use up vertical space and increase the complexity of code without
+adding functionality. It’s better style to collapse identical branches into a single multi-catch
+branch.
try{
+ // do something
+}catch(IllegalArgumentExceptione){
+ throwe;
+}catch(IllegalStateExceptione){// Can be collapsed into the previous block
+ throwe;
+}
+
+try{
+ // do something
+}catch(IllegalArgumentException|IllegalStateExceptione){// This is better
+ throwe;
+}
+
Avoid using if..else statements without using surrounding braces. If the code formatting
+or indentation is lost then it becomes difficult to separate the code being controlled
+from the rest.
+
+
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
+by the rule ControlStatementBraces.
+
+
This rule is defined by the following XPath expression:
Avoid using if statements without using braces to surround the code block. If the code
+formatting or indentation is lost then it becomes difficult to separate the code being
+controlled from the rest.
+
+
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
+by the rule ControlStatementBraces.
+
+
This rule is defined by the following XPath expression:
This rule finds Linguistic Naming Antipatterns. It checks for fields, that are named, as if they should
+be boolean but have a different type. It also checks for methods, that according to their name, should
+return a boolean, but don’t. Further, it checks, that getters return something and setters won’t.
+Finally, it checks that methods, that start with "to" - so called transform methods - actually return
+something, since according to their name, they should convert or transform one object into another.
+There is additionally an option, to check for methods that contain "To" in their name - which are
+also transform methods. However, this is disabled by default, since this detection is prone to
+false positives.
publicclassLinguisticNaming{
+ intisValid;// the field name indicates a boolean, but it is an int.
+ booleanisTrue;// correct type of the field
+
+ voidmyMethod(){
+ inthasMoneyLocal;// the local variable name indicates a boolean, but it is an int.
+ booleanhasSalaryLocal;// correct naming and type
+ }
+
+ // the name of the method indicates, it is a boolean, but the method returns an int.
+ intisValid(){
+ return1;
+ }
+ // correct naming and return type
+ booleanisSmall(){
+ returntrue;
+ }
+
+ // the name indicates, this is a setter, but it returns something
+ intsetName(){
+ return1;
+ }
+
+ // the name indicates, this is a getter, but it doesn't return anything
+ voidgetName(){
+ // nothing to return?
+ }
+
+ // the name indicates, it transforms an object and should return the result
+ voidtoDataType(){
+ // nothing to return?
+ }
+ // the name indicates, it transforms an object and should return the result
+ voidgrapeToWine(){
+ // nothing to return?
+ }
+}
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
ignoredAnnotations
+
java.lang.Override
+
Fully qualified names of the annotation types that should be ignored by this rule
+
yes. Delimiter is ‘|’.
+
+
+
checkBooleanMethod
+
true
+
Check method names and types for inconsistent naming.
+
no
+
+
+
checkGetters
+
true
+
Check return type of getters.
+
no
+
+
+
checkSetters
+
true
+
Check return type of setters.
+
no
+
+
+
checkPrefixedTransformMethods
+
true
+
Check return type of methods whose names start with the configured prefix (see transformMethodNames property).
+
no
+
+
+
checkTransformMethods
+
false
+
Check return type of methods which contain the configured infix in their name (see transformMethodNames property).
+
no
+
+
+
booleanMethodPrefixes
+
is | has | can | have | will | should
+
The prefixes of methods that return boolean.
+
yes. Delimiter is ‘|’.
+
+
+
transformMethodNames
+
to | as
+
The prefixes and infixes that indicate a transform method.
+
yes. Delimiter is ‘|’.
+
+
+
checkFields
+
true
+
Check field names and types for inconsistent naming.
+
no
+
+
+
checkVariables
+
true
+
Check local variable names and types for inconsistent naming.
+
no
+
+
+
booleanFieldPrefixes
+
is | has | can | have | will | should
+
The prefixes of fields and variables that indicate boolean.
+
yes. Delimiter is ‘|’.
+
+
+
+
+
Use this rule with the default properties by just referencing it:
The Local Home interface of a Session EJB should be suffixed by ‘LocalHome’.
+
+
This rule is defined by the following XPath expression:
+
//ClassOrInterfaceDeclaration
+[
+ (
+ (./ExtendsList/ClassOrInterfaceType[ends-with(@Image,'EJBLocalHome')])
+ )
+ and
+ not
+ (
+ ends-with(@SimpleName,'LocalHome')
+ )
+]
+
+
+
Example(s):
+
+
publicinterfaceMyBeautifulLocalHomeextendsjavax.ejb.EJBLocalHome{}// proper name
+
+publicinterfaceMissingProperSuffixextendsjavax.ejb.EJBLocalHome{}// non-standard name
+
The Local Interface of a Session EJB should be suffixed by ‘Local’.
+
+
This rule is defined by the following XPath expression:
+
//ClassOrInterfaceDeclaration
+[
+ (
+ (./ExtendsList/ClassOrInterfaceType[ends-with(@Image,'EJBLocalObject')])
+ )
+ and
+ not
+ (
+ ends-with(@SimpleName,'Local')
+ )
+]
+
+
+
Example(s):
+
+
publicinterfaceMyLocalextendsjavax.ejb.EJBLocalObject{}// proper name
+
+publicinterfaceMissingProperSuffixextendsjavax.ejb.EJBLocalObject{}// non-standard name
+
Configurable naming conventions for local variable declarations and other locally-scoped
+variables. This rule reports variable declarations which do not match the regex that applies to their
+specific kind (e.g. final variable, or catch-clause parameter). Each regex can be configured through
+properties.
+
+
By default this rule uses the standard Java naming convention (Camel case).
classFoo{
+ voidbar(){
+ intlocalVariable=1;// This is in camel case, so it's ok
+ intlocal_variable=1;// This will be reported unless you change the regex
+
+ finalinti_var=1;// final local variables can be configured separately
+
+ try{
+ foo();
+ }catch(IllegalArgumentExceptione_illegal){
+ // exception block parameters can be configured separately
+ }
+
+ }
+ }
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
localVarPattern
+
[a-z][a-zA-Z0-9]*
+
Regex which applies to non-final local variable names
+
no
+
+
+
finalVarPattern
+
[a-z][a-zA-Z0-9]*
+
Regex which applies to final local variable names
+
no
+
+
+
catchParameterPattern
+
[a-z][a-zA-Z0-9]*
+
Regex which applies to exception block parameter names
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
publicvoidfoo1(Stringparam){// do stuff with param never assigning it
+
+}
+
+publicvoidfoo2(finalStringparam){// better, do stuff with param never assigning it
+
+}
+
Configurable naming conventions for method declarations. This rule reports
+method declarations which do not match the regex that applies to their
+specific kind (e.g. JUnit test or native method). Each regex can be
+configured through properties.
+
+
By default this rule uses the standard Java naming convention (Camel case).
Checks for variables that are defined before they might be used. A reference is deemed to be premature if it is created right before a block of code that doesn’t use it that also has the ability to return or throw an exception.
A Remote Home interface type of a Session EJB should be suffixed by ‘Home’.
+
+
This rule is defined by the following XPath expression:
+
//ClassOrInterfaceDeclaration
+[
+ (
+ (./ExtendsList/ClassOrInterfaceType[ends-with(@Image,'EJBHome')])
+ )
+ and
+ not
+ (
+ ends-with(@SimpleName,'Home')
+ )
+]
+
+
+
Example(s):
+
+
publicinterfaceMyBeautifulHomeextendsjavax.ejb.EJBHome{}// proper name
+
+publicinterfaceMissingProperSuffixextendsjavax.ejb.EJBHome{}// non-standard name
+
publicclassSomething{
+ privateintq=15;// field - too short
+ publicstaticvoidmain(Stringas[]){// formal arg - too short
+ intr=20+q;// local var - too short
+ for(inti=0;i<10;i++){// not a violation (inside 'for' loop)
+ r+=q;
+ }
+ for(Integeri:numbers){// not a violation (inside 'for-each' loop)
+ r+=q;
+ }
+ }
+}
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
minimum
+
3
+
Number of characters that are required as a minimum for a variable name.
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
publicclassFoo{
+ // this is bad, since someone could accidentally
+ // do PI = 2.71828; which is actually e
+ // final double PI = 3.16; is ok
+ doublePI=3.16;
+}
+
If you overuse the static import feature, it can make your program unreadable and
+unmaintainable, polluting its namespace with all the static members you import.
+Readers of your code (including you, a few months after you wrote it) will not know
+which class a static member comes from (Sun 1.5 Language Guide).
+
+
This rule is defined by the following XPath expression:
This rule detects when a cast is unnecessary while accessing collection elements. This rule is mostly useful
+for old java code before generics where introduced with java 1.5.
This rule detects when a constructor is not necessary; i.e., when there is only one constructor and the
+constructor is identical to the default constructor. The default constructor should has same access
+modifier as the declaring class. In an enum type, the default constructor is implicitly private.
Import statements allow the use of non-fully qualified names. The use of a fully qualified name
+which is covered by an import statement is redundant. Consider using the non-fully qualified name.
If set to false this rule no longer requires the variable declaration and return statement to be on consecutive lines. Any variable that is used solely in a return statement will be reported.
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
Fields in interfaces and annotations are automatically public static final, and methods are public abstract.
+Classes, interfaces or annotations nested in an interface or annotation are automatically public static
+(all nested interfaces and annotations are automatically static).
+Nested enums are automatically static.
+For historical reasons, modifiers which are implied by the context are accepted by the compiler, but are superfluous.
public@interfaceAnnotation{
+ publicabstractvoidbar();// both abstract and public are ignored by the compiler
+ publicstaticfinalintX=0;// public, static, and final all ignored
+ publicstaticclassBar{}// public, static ignored
+ publicstaticinterfaceBaz{}// ditto
+}
+publicinterfaceFoo{
+ publicabstractvoidbar();// both abstract and public are ignored by the compiler
+ publicstaticfinalintX=0;// public, static, and final all ignored
+ publicstaticclassBar{}// public, static ignored
+ publicstaticinterfaceBaz{}// ditto
+}
+publicclassBar{
+ publicstaticinterfaceBaz{}// static ignored
+ publicstaticenumFoorBar{// static ignored
+ FOO;
+ }
+}
+
Use the diamond operator to let the type be inferred automatically. With the Diamond operator it is possible
+to avoid duplication of the type parameters.
+Instead, the compiler is now able to infer the parameter types for constructor calls,
+which makes the code also more readable.
+
+
The diamond operator has been introduced with java 7. However, type inference has been improved further
+with java8, rendering more type parameters unnecessary. This is only possible with java8 and the resulting
+code won’t compile with java7. If you use java7, make sure to enable java7Compatibility for this rule to avoid
+false positives.
+
+
This rule is defined by the following XPath expression:
List<String>strings=newArrayList<String>();// unnecessary duplication of type parameters
+List<String>stringsWithDiamond=newArrayList<>();// using the diamond operator is more concise
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
java7Compatibility
+
false
+
If disabled, the rule shows also violations that are applicable for java8+
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
When declaring and initializing array fields or variables, it is not necessary to explicitly create a new array
+using new. Instead one can simply define the initial content of the array as a expression in curly braces.
+
+
E.g. int[] x = new int[] { 1, 2, 3 }; can be written as int[] x = { 1, 2, 3 };.
+
+
This rule is defined by the following XPath expression:
Since Java 1.7, numeric literals can use underscores to separate digits. This rule enforces that
+numeric literals above a certain length use these underscores to increase readability.
+
+
The rule only supports decimal (base 10) literals for now. The acceptable length under which literals
+are not required to have underscores is configurable via a property. Even under that length, underscores
+that are misplaced (not making groups of 3 digits) are reported.
+
+
This rule is defined by the following XPath expression:
+
//Literal[
+ @IntLiteral=true()
+ or@LongLiteral=true()
+ or@DoubleLiteral=true()
+ or@FloatLiteral=true()
+]
+ (: Filter out literals in base other than 10 :)
+ [not(matches(@Image,"^0[^.]"))]
+ (: Filter out ignored field name :)
+ [not(ancestor::VariableDeclarator[1][@Name='serialVersionUID'])]
+ [
+ some$numintokenize(@Image,"[dDfFlLeE+\-]")
+ satisfiesnot(
+ (contains($num,".")
+ andstring-length(substring-before($num,"."))<=$acceptableDecimalLength
+ andstring-length(substring-after($num,"."))<=$acceptableDecimalLength
+ orstring-length($num)<=$acceptableDecimalLength
+ )
+ andnot(contains($num,"_"))
+ ormatches($num,"^[0-9]{1,3}(_[0-9]{3})*(\.([0-9]{3}_)*[0-9]{1,3})?$")
+ )
+ ]
+
+
+
Example(s):
+
+
publicclassFoo{
+ privateintnum=1000000;// should be 1_000_000
+}
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
acceptableDecimalLength
+
4
+
Length under which literals in base 10 are not required to have underscores
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
A variable naming conventions rule - customize this to your liking. Currently, it
+checks for final variables that should be fully capitalized and non-final variables
+that should not include underscores.
Avoid using ‘while’ statements without using braces to surround the code block. If the code
+formatting or indentation is lost then it becomes difficult to separate the code being
+controlled from the rest.
+
+
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
+by the rule ControlStatementBraces.
+
+
This rule is defined by the following XPath expression:
If an abstract class does not provides any methods, it may be acting as a simple data container
+that is not meant to be instantiated. In this case, it is probably better to use a private or
+protected constructor in order to prevent instantiation than make the class misleadingly abstract.
+
+
This rule is defined by the following XPath expression:
Avoid throwing NullPointerExceptions manually. These are confusing because most people will assume that the
+virtual machine threw it. To avoid a method being called with a null parameter, you may consider
+using an IllegalArgumentException instead, making it clearly seen as a programmer-initiated exception.
+However, there are better ways to handle this:
+
+
+
Effective Java, 3rd Edition, Item 72: Favor the use of standard exceptions
+
+
Arguably, every erroneous method invocation boils down to an illegal argument or state,
+but other exceptions are standardly used for certain kinds of illegal arguments and states.
+If a caller passes null in some parameter for which null values are prohibited, convention dictates that
+NullPointerException be thrown rather than IllegalArgumentException.
+
+
+
To implement that, you are encouraged to use java.util.Objects.requireNonNull()
+(introduced in Java 1.7). This method is designed primarily for doing parameter
+validation in methods and constructors with multiple parameters.
+
+
Your parameter validation could thus look like the following:
+
public class Foo {
+ private String exampleValue;
+
+ void setExampleValue(String exampleValue) {
+ // check, throw and assignment in a single standard call
+ this.exampleValue = Objects.requireNonNull(exampleValue, "exampleValue must not be null!");
+ }
+ }
+
Avoid throwing certain exception types. Rather than throw a raw RuntimeException, Throwable,
+Exception, or Error, use a subclassed exception or error instead.
+
+
This rule is defined by the following XPath expression:
A method or constructor should not explicitly declare unchecked exceptions in its
+throws clause. Java doesn’t force the caller to handle an unchecked exception,
+so it’s unnecessary except for documentation. A better practice is to document the
+exceptional cases with a @throws Javadoc tag, which allows being more descriptive.
+
+
This rule is defined by the following XPath expression:
This rule counts the number of unique attributes, local variables, and return types within an object.
+A number higher than the specified threshold can indicate a high degree of coupling.
The complexity of methods directly affects maintenance costs and readability. Concentrating too much decisional logic
+in a single method makes its behaviour hard to read and change.
+
+
Cyclomatic complexity assesses the complexity of a method by counting the number of decision points in a method,
+plus one for the method entry. Decision points are places where the control flow jumps to another place in the
+program. As such, they include all control flow statements, such as if, while, for, and case. For more
+details on the calculation, see the documentation of the Cyclo metric.
+
+
Generally, numbers ranging from 1-4 denote low complexity, 5-7 denote moderate complexity, 8-10 denote
+high complexity, and 11+ is very high complexity. By default, this rule reports methods with a complexity >= 10.
+Additionally, classes with many methods of moderate complexity get reported as well once the total of their
+methods’ complexities reaches 80, even if none of the methods was directly reported.
+
+
Reported methods should be broken down into several smaller methods. Reported classes should probably be broken down
+into subcomponents.
Data Classes are simple data holders, which reveal most of their state, and
+without complex functionality. The lack of functionality may indicate that
+their behaviour is defined elsewhere, which is a sign of poor data-behaviour
+proximity. By directly exposing their internals, Data Classes break encapsulation,
+and therefore reduce the system’s maintainability and understandability. Moreover,
+classes tend to strongly rely on their data representation, which makes for a brittle
+design.
+
+
Refactoring a Data Class should focus on restoring a good data-behaviour proximity. In
+most cases, that means moving the operations defined on the data back into the class.
+In some other cases it may make sense to remove entirely the class and move the data
+into the former client classes.
Using Exceptions as form of flow control is not recommended as they obscure true exceptions when debugging.
+Either add the necessary validation or use an alternate control structure.
publicvoidbar(){
+ try{
+ try{
+ }catch(Exceptione){
+ thrownewWrapperException(e);
+ // this is essentially a GOTO to the WrapperException catch block
+ }
+ }catch(WrapperExceptione){
+ // do some more stuff
+ }
+}
+
Excessive class file lengths are usually indications that the class may be burdened with excessive
+responsibilities that could be provided by external classes or functions. In breaking these methods
+apart the code becomes more manageable and ripe for reuse.
A high number of imports can indicate a high degree of coupling within an object. This rule
+counts the number of unique imports and reports a violation if the count is above the
+user-specified threshold.
When methods are excessively long this usually indicates that the method is doing more than its
+name/signature might suggest. They also become challenging for others to digest since excessive
+scrolling causes readers to lose focus.
+Try to reduce the method length by creating helper methods and removing any copy/pasted code.
Methods with numerous parameters are a challenge to maintain, especially if most of them share the
+same datatype. These situations usually denote the need for new objects to wrap the numerous parameters.
Classes with large numbers of public methods and attributes require disproportionate testing efforts
+since combinational side effects grow rapidly and increase risk. Refactoring these classes into
+smaller ones not only increases testability and reliability but also allows new variations to be
+developed easily.
The God Class rule detects the God Class design flaw using metrics. God classes do too many things,
+are very big and overly complex. They should be split apart to be more object-oriented.
+The rule uses the detection strategy described in "Object-Oriented Metrics in Practice".
+The violations are reported against the entire class.
+
+
See also the references:
+
+
Michele Lanza and Radu Marinescu. Object-Oriented Metrics in Practice:
+Using Software Metrics to Characterize, Evaluate, and Improve the Design
+of Object-Oriented Systems. Springer, Berlin, 1 edition, October 2006. Page 80.
Identifies private fields whose values never change once object initialization ends either in the declaration
+of the field or by a constructor. This helps in converting existing classes to becoming immutable ones.
+Note that this rule does not enforce referenced object to be immutable itself. A class can still be mutable, even
+if all its member fields are declared final. This is referred to as shallow immutability. For more information on
+mutability, see Effective Java, 3rd Edition, Item 17: Minimize mutability.
publicclassFoo{
+ /**
+ * This example will result in two violations.
+ */
+ publicvoidexample(Barb){
+ // this method call is ok, as b is a parameter of "example"
+ Cc=b.getC();
+
+ // this method call is a violation, as we are using c, which we got from B.
+ // We should ask b directly instead, e.g. "b.doItOnC();"
+ c.doIt();
+
+ // this is also a violation, just expressed differently as a method chain without temporary variables.
+ b.getC().doIt();
+
+ // a constructor call, not a method call.
+ Dd=newD();
+ // this method call is ok, because we have create the new instance of D locally.
+ d.doSomethingElse();
+ }
+}
+
Complexity directly affects maintenance costs is determined by the number of decision points in a method
+plus one for the method entry. The decision points include ‘if’, ‘while’, ‘for’, and ‘case labels’ calls.
+Generally, numbers ranging from 1-4 denote low complexity, 5-7 denote moderate complexity, 8-10 denote
+high complexity, and 11+ is very high complexity. Modified complexity treats switch statements as a single
+decision point.
+
+
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
+by the rule CyclomaticComplexity.
This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of lines
+of code for a given constructor. NCSS ignores comments, and counts actual statements. Using this algorithm,
+lines of code that are split are counted as one.
+
+
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
+by the rule NcssCount.
This rule uses the NCSS (Non-Commenting Source Statements) metric to determine the number of lines
+of code in a class, method or constructor. NCSS ignores comments, blank lines, and only counts actual
+statements. For more details on the calculation, see the documentation of
+the NCSS metric.
This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of lines
+of code for a given method. NCSS ignores comments, and counts actual statements. Using this algorithm,
+lines of code that are split are counted as one.
+
+
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
+by the rule NcssCount.
This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of lines
+of code for a given type. NCSS ignores comments, and counts actual statements. Using this algorithm,
+lines of code that are split are counted as one.
+
+
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
+by the rule NcssCount.
The NPath complexity of a method is the number of acyclic execution paths through that method.
+While cyclomatic complexity counts the number of decision points in a method, NPath counts the number of
+full paths from the beginning to the end of the block of the method. That metric grows exponentially, as
+it multiplies the complexity of statements in the same block. For more details on the calculation, see the
+documentation of the NPath metric.
+
+
A threshold of 200 is generally considered the point where measures should be taken to reduce
+complexity and increase readability.
A method/constructor shouldn’t explicitly throw the generic java.lang.Exception, since it
+is unclear which exceptions that can be thrown from the methods. It might be
+difficult to document and understand such vague interfaces. Use either a class
+derived from RuntimeException or a checked exception.
Look for ternary operators with the form condition ? literalBoolean : foo
+or condition ? foo : literalBoolean.
+
+
These expressions can be simplified respectively to
+condition || foo when the literalBoolean is true
+!condition && foo when the literalBoolean is false
+or
+!condition || foo when the literalBoolean is true
+condition && foo when the literalBoolean is false
+
+
This rule is defined by the following XPath expression:
publicclassFoo{
+ publicbooleantest(){
+ returncondition?true:something();// can be as simple as return condition || something();
+ }
+
+ publicvoidtest2(){
+ finalbooleanvalue=condition?false:something();// can be as simple as value = !condition && something();
+ }
+
+ publicbooleantest3(){
+ returncondition?something():true;// can be as simple as return !condition || something();
+ }
+
+ publicvoidtest4(){
+ finalbooleanotherValue=condition?something():false;// can be as simple as condition && something();
+ }
+}
+
publicbooleanisBarEqualTo(intx){
+ if(bar==x){// this bit of code...
+ returntrue;
+ }else{
+ returnfalse;
+ }
+}
+
+publicbooleanisBarEqualTo(intx){
+ returnbar==x;// can be replaced with this
+}
+
Fields whose scopes are limited to just single methods do not rely on the containing
+object to provide them to other methods. They may be better implemented as local variables
+within those methods.
Complexity directly affects maintenance costs is determined by the number of decision points in a method
+plus one for the method entry. The decision points include ‘if’, ‘while’, ‘for’, and ‘case labels’ calls.
+Generally, numbers ranging from 1-4 denote low complexity, 5-7 denote moderate complexity, 8-10 denote
+high complexity, and 11+ is very high complexity.
+
+
This rule is deprecated and will be removed with PMD 7.0.0. The rule is replaced
+by the rule CyclomaticComplexity.
A high ratio of statements to labels in a switch statement implies that the switch statement
+is overloaded. Consider moving the statements into new methods or creating subclasses based
+on the switch variable.
Classes that have too many fields can become unwieldy and could be redesigned to have fewer fields,
+possibly through grouping related fields in new objects. For example, a class with individual
+city/state/zip fields could park them within a single Address field.
publicclassPerson{// too many separate fields
+ intbirthYear;
+ intbirthMonth;
+ intbirthDate;
+ floatheight;
+ floatweight;
+}
+
+publicclassPerson{// this is more manageable
+ DatebirthDate;
+ BodyMeasurementsmeasurements;
+}
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
maxfields
+
15
+
Max allowable fields
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
A class with too many methods is probably a good suspect for refactoring, in order to reduce its
+complexity and find a way to have more fine grained objects.
+
+
This rule is defined by the following XPath expression:
When you write a public method, you should be thinking in terms of an API. If your method is public, it means other class
+will use it, therefore, you want (or need) to offer a comprehensive and evolutive API. If you pass a lot of information
+as a simple series of Strings, you may think of using an Object to represent all those information. You’ll get a simpler
+API (such as doWork(Workload workload), rather than a tedious series of Strings) and more importantly, if you need at some
+point to pass extra data, you’ll be able to do so by simply modifying or extending Workload without any modification to
+your API.
+
+
This rule is defined by the following XPath expression:
publicclassMyClass{
+ publicvoidconnect(Stringusername,
+ Stringpssd,
+ StringdatabaseName,
+ StringdatabaseAdress)
+ // Instead of those parameters object
+ // would ensure a cleaner API and permit
+ // to add extra data transparently (no code change):
+ // void connect(UserData data);
+ {
+
+ }
+}
+
For classes that only have static methods, consider making them utility classes.
+Note that this doesn’t apply to abstract classes, since their subclasses may
+well include non-static methods. Also, if you want this class to be a utility class,
+remember to add a private constructor to prevent instantiation.
+(Note, that this use was known before PMD 5.1.0 as UseSingleton).
Uncommented Empty Constructor finds instances where a constructor does not
+contain statements, but there is no comment. By explicitly commenting empty
+constructors it is easier to distinguish between intentional (commented)
+and unintentional empty constructors.
+
+
This rule is defined by the following XPath expression:
Uncommented Empty Method Body finds instances where a method body does not contain
+statements, but there is no comment. By explicitly commenting empty method bodies
+it is easier to distinguish between intentional (commented) and unintentional
+empty methods.
+
+
This rule is defined by the following XPath expression:
Methods such as getDeclaredConstructors(), getDeclaredConstructor(Class[]) and setAccessible(),
+as the interface PrivilegedAction, allow for the runtime alteration of variable, class, or
+method visibility, even if they are private. This violates the principle of encapsulation.
+
+
This rule is defined by the following XPath expression:
+
//PrimaryExpression[
+(
+(PrimarySuffix[
+ ends-with(@Image,'getDeclaredConstructors')
+ or
+ ends-with(@Image,'getDeclaredConstructor')
+ or
+ ends-with(@Image,'setAccessible')
+ ])
+or
+(PrimaryPrefix/Name[
+ ends-with(@Image,'getDeclaredConstructor')
+ or
+ ends-with(@Image,'getDeclaredConstructors')
+ or
+ starts-with(@Image,'AccessibleObject.setAccessible')
+ ])
+)
+and
+(//ImportDeclaration/Name[
+ contains(@Image,'java.security.PrivilegedAction')])
+]
+
Using a branching statement as the last part of a loop may be a bug, and/or is confusing.
+Ensure that the usage is not a bug, or consider using another approach.
// unusual use of branching statement in a loop
+for(inti=0;i<10;i++){
+ if(i*i<=25){
+ continue;
+ }
+ break;
+}
+
+// this makes more sense...
+for(inti=0;i<10;i++){
+ if(i*i>25){
+ break;
+ }
+}
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
checkBreakLoopTypes
+
for | do | while
+
List of loop types in which break statements will be checked
+
yes. Delimiter is ‘|’.
+
+
+
checkContinueLoopTypes
+
for | do | while
+
List of loop types in which continue statements will be checked
+
yes. Delimiter is ‘|’.
+
+
+
checkReturnLoopTypes
+
for | do | while
+
List of loop types in which return statements will be checked
+
yes. Delimiter is ‘|’.
+
+
+
+
+
Use this rule with the default properties by just referencing it:
The method Object.finalize() is called by the garbage collector on an object when garbage collection determines
+that there are no more references to the object. It should not be invoked by application logic.
+
+
Note that Oracle has declared Object.finalize() as deprecated since JDK 9.
Code should never throw NullPointerExceptions under normal circumstances. A catch block may hide the
+original error, causing other, more subtle problems later on.
+
+
This rule is defined by the following XPath expression:
Catching Throwable errors is not recommended since its scope is very broad. It includes runtime issues such as
+OutOfMemoryError that should be exposed and managed separately.
One might assume that the result of "new BigDecimal(0.1)" is exactly equal to 0.1, but it is actually
+equal to .1000000000000000055511151231257827021181583404541015625.
+This is because 0.1 cannot be represented exactly as a double (or as a binary fraction of any finite
+length). Thus, the long value that is being passed in to the constructor is not exactly equal to 0.1,
+appearances notwithstanding.
+
+
The (String) constructor, on the other hand, is perfectly predictable: ‘new BigDecimal("0.1")’ is
+exactly equal to 0.1, as one would expect. Therefore, it is generally recommended that the
+(String) constructor be used in preference to this one.
+
+
This rule is defined by the following XPath expression:
BigDecimalbd=newBigDecimal(1.123);// loss of precision, this would trigger the rule
+
+BigDecimalbd=newBigDecimal("1.123");// preferred approach
+
+BigDecimalbd=newBigDecimal(12);// preferred approach, ok for integer values
+
Deprecated (Use ‘exceptionList’ property) File containing strings to skip (one string per line), only used if ignore list is not set. File must be UTF-8 encoded.
+
no
+
+
+
separator
+
,
+
Ignore list separator
+
no
+
+
+
maxDuplicateLiterals
+
4
+
Max duplicate literals
+
no
+
+
+
minimumLength
+
3
+
Minimum string length to check
+
no
+
+
+
skipAnnotations
+
false
+
Skip literals within annotations
+
no
+
+
+
exceptionList
+
+
List of literals to ignore. A literal is ignored if its image can be found in this list. Components of this list should not be surrounded by double quotes.
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
It can be confusing to have a field name with the same name as a method. While this is permitted,
+having information (field) and actions (method) is not clear naming. Developers versed in
+Smalltalk often prefer this approach as the methods denote accessor methods.
It is somewhat confusing to have a field name matching the declaring class name.
+This probably means that type and/or field names should be chosen more carefully.
Avoid using hard-coded literals in conditional statements. By declaring them as static variables
+or private members with descriptive names maintainability is enhanced. By default, the literals "-1" and "0" are ignored.
+More exceptions can be defined with the property "ignoreMagicNumbers".
+
+
The rule doesn’t consider deeper expressions by default, but this can be enabled via the property ignoreExpressions.
+With this property set to false, if-conditions like i == 1 + 5 are reported as well. Note that in that case,
+the property ignoreMagicNumbers is not taken into account, if there are multiple literals involved in such an expression.
+
+
This rule is defined by the following XPath expression:
Statements in a catch block that invoke accessors on the exception without using the information
+only add to code size. Either remove the invocation, or use the return result.
+
+
This rule is defined by the following XPath expression:
+
//CatchStatement/Block/BlockStatement/Statement/StatementExpression/PrimaryExpression/PrimaryPrefix/Name
+[
+ @Image=concat(../../../../../../../FormalParameter/VariableDeclaratorId/@Name,'.getMessage')
+ or
+ @Image=concat(../../../../../../../FormalParameter/VariableDeclaratorId/@Name,'.getLocalizedMessage')
+ or
+ @Image=concat(../../../../../../../FormalParameter/VariableDeclaratorId/@Name,'.getCause')
+ or
+ @Image=concat(../../../../../../../FormalParameter/VariableDeclaratorId/@Name,'.getStackTrace')
+ or
+ @Image=concat(../../../../../../../FormalParameter/VariableDeclaratorId/@Name,'.toString')
+]
+
The use of multiple unary operators may be problematic, and/or confusing.
+Ensure that the intended usage is not a bug, or consider simplifying the expression.
// These are typo bugs, or at best needlessly complex and confusing:
+inti=--1;
+intj=+-+1;
+intz=~~2;
+booleanb=!!true;
+booleanc=!!!true;
+
+// These are better:
+inti=1;
+intj=-1;
+intz=2;
+booleanb=true;
+booleanc=false;
+
+// And these just make your brain hurt:
+inti=~-2;
+intj=-~7;
+
Avoid equality comparisons with Double.NaN. Due to the implicit lack of representation
+precision when comparing floating point numbers these are likely to cause logic errors.
+
+
This rule is defined by the following XPath expression:
If a class is a bean, or is referenced by a bean directly or indirectly it needs to be serializable.
+Member variables need to be marked as transient, static, or have accessor methods in the class. Marking
+variables as transient is the safest and easiest modification. Accessor methods should follow the Java
+naming conventions, i.e. for a variable named foo, getFoo() and setFoo() accessor methods should be provided.
When deriving an array of a specific class from your Collection, one should provide an array of
+the same class as the parameter of the toArray() method. Doing otherwise you will will result
+in a ClassCastException.
+
+
This rule is defined by the following XPath expression:
Collectionc=newArrayList();
+Integerobj=newInteger(1);
+c.add(obj);
+
+ // this would trigger the rule (and throw a ClassCastException if executed)
+Integer[]a=(Integer[])c.toArray();
+
+ // this is fine and will not trigger the rule
+Integer[]b=(Integer[])c.toArray(newInteger[c.size()]);
+
publicclassFooimplementsCloneable{
+ @Override
+ protectedObjectclone()throwsCloneNotSupportedException{// Violation, must be public
+ }
+}
+
+publicclassFooimplementsCloneable{
+ @Override
+ protectedFooclone(){// Violation, must be public
+ }
+}
+
+publicclassFooimplementsCloneable{
+ @Override
+ publicObjectclone()// Ok
+}
+
The method clone() should only be implemented if the class implements the Cloneable interface with the exception of
+a final method that only throws CloneNotSupportedException.
+
+
The rule can also detect, if the class implements or extends a Cloneable class.
If a class implements cloneable the return type of the method clone() must be the class name. That way, the caller
+of the clone method doesn’t need to cast the returned clone to the correct type.
+
+
Note: This is only possible with Java 1.5 or higher.
+
+
This rule is defined by the following XPath expression:
Ensure that resources (like java.sql.Connection, java.sql.Statement, and java.sql.ResultSet objects
+and any subtype of java.lang.AutoCloseable) are always closed after use.
+Failing to do so might result in resource leaks.
+
+
Note: It suffices to configure the super type, e.g. java.lang.AutoClosable, so that this rule automatically triggers
+on any subtype (e.g. java.io.FileInputStream). Additionally specifying java.sql.Connection helps in detecting
+the types, if the type resolution / auxclasspath is not correctly setup.
+
+
Note: Since PMD 6.16.0 the default value for the property types contains java.lang.AutoCloseable and detects
+now cases where the standard java.io.*Stream classes are involved. In order to restore the old behaviour,
+just remove "AutoCloseable" from the types.
Calling overridable methods during construction poses a risk of invoking methods on an incompletely
+constructed object and can be difficult to debug.
+It may leave the sub-class unable to construct its superclass or forced to replicate the construction
+process completely within itself, losing the ability to call super(). If the default constructor
+contains a call to an overridable method, the subclass may be completely uninstantiable. Note that
+this includes method calls throughout the control flow graph - i.e., if a constructor Foo() calls a
+private method bar() that calls a public method buz(), this denotes a problem.
The dataflow analysis tracks local definitions, undefinitions and references to variables on different paths on the data flow.
+From those informations there can be found various problems.
+
+
+
DU - Anomaly: A recently defined variable is undefined. These anomalies may appear in normal source text.
+
DD - Anomaly: A recently defined variable is redefined. This is ominous but don’t have to be a bug.
+
+
+
This rule is deprecated. Use UnusedAssignment in category bestpractices instead.
publicvoidfoo(){
+ intbuz=5;
+ buz=6;// redefinition of buz -> dd-anomaly
+ foo(buz);
+ buz=2;
+}// buz is undefined when leaving scope -> du-anomaly
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
maxPaths
+
1000
+
Maximum number of checked paths per method. A lower value will increase the performance of the rule but may decrease anomalies found.
+
no
+
+
+
maxViolations
+
100
+
Maximum number of anomalies per class
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
The method appears to be a test case since it has public or default visibility,
+non-static access, no arguments, no return value, has no annotations, but is a
+member of a class that has one or more JUnit test cases. If it is a utility
+method, it should likely have private visibility. If it is an ignored test, it
+should be annotated with @Test and @Ignore.
+
+
This rule is defined by the following XPath expression:
Calls to System.gc(), Runtime.getRuntime().gc(), and System.runFinalization() are not advised. Code should have the
+same behavior whether the garbage collection is disabled using the option -Xdisableexplicitgc or not.
+Moreover, "modern" jvms do a very good job handling garbage collections. If memory usage issues unrelated to memory
+leaks develop within an application, it should be dealt with JVM options rather than within the code itself.
+
+
This rule is defined by the following XPath expression:
Web applications should not call System.exit(), since only the web container or the
+application server should stop the JVM. Otherwise a web application would terminate all other applications
+running on the same application server.
+
+
This rule also checks for the equivalent calls Runtime.getRuntime().exit() and Runtime.getRuntime().halt().
+
+
This rule was called DoNotCallSystemExit until PMD 6.29.0.
+
+
This rule is defined by the following XPath expression:
+
//Name[
+ starts-with(@Image,'System.exit')
+ or
+ (starts-with(@Image,'Runtime.getRuntime')and../../PrimarySuffix[ends-with(@Image,'exit')orends-with(@Image,'halt')])
+][not(ancestor::MethodDeclaration[1][@Name="main"and@Static=true()])]
+
+
+
Example(s):
+
+
publicvoidbar(){
+ System.exit(0);// never call this when running in an application server!
+}
+publicvoidfoo(){
+ Runtime.getRuntime().exit(0);// never stop the JVM manually, the container will do this.
+}
+
Web applications should not call System.exit(), since only the web container or the
+application server should stop the JVM. Otherwise a web application would terminate all other applications
+running on the same application server.
+
+
This rule also checks for the equivalent calls Runtime.getRuntime().exit() and Runtime.getRuntime().halt().
+
+
This rule was called DoNotCallSystemExit until PMD 6.29.0.
+
+
This rule is defined by the following XPath expression:
+
//Name[
+ starts-with(@Image,'System.exit')
+ or
+ (starts-with(@Image,'Runtime.getRuntime')and../../PrimarySuffix[ends-with(@Image,'exit')orends-with(@Image,'halt')])
+][not(ancestor::MethodDeclaration[1][@Name="main"and@Static=true()])]
+
+
+
Example(s):
+
+
publicvoidbar(){
+ System.exit(0);// never call this when running in an application server!
+}
+publicvoidfoo(){
+ Runtime.getRuntime().exit(0);// never stop the JVM manually, the container will do this.
+}
+
Throwing exceptions within a ‘finally’ block is confusing since they may mask other exceptions
+or code defects.
+Note: This is a PMD implementation of the Lint4j rule "A throw in a finally block"
+
+
This rule is defined by the following XPath expression:
+
//FinallyStatement[descendant::ThrowStatement]
+
+
+
Example(s):
+
+
publicclassFoo{
+ publicvoidbar(){
+ try{
+ // Here do some stuff
+ }catch(Exceptione){
+ // Handling the issue
+ }finally{
+ // is this really a good idea ?
+ thrownewException();
+ }
+ }
+}
+
Don’t use floating point for loop indices. If you must use floating point, use double
+unless you’re certain that float provides enough precision and you have a compelling
+performance need (space or time).
+
+
This rule is defined by the following XPath expression:
Empty Catch Block finds instances where an exception is caught, but nothing is done.
+In most circumstances, this swallows an exception which should either be acted on
+or reported.
+
+
This rule is defined by the following XPath expression:
An empty statement (or a semicolon by itself) that is not used as the sole body of a ‘for’
+or ‘while’ loop is probably a bug. It could also be a double semicolon, which has no purpose
+and should be removed.
+
+
This rule is defined by the following XPath expression:
publicvoiddoit(){
+ // this is probably not what you meant to do
+ ;
+ // the extra semicolon here this is not necessary
+ System.out.println("look at the extra semicolon");;
+}
+
Empty While Statement finds all instances where a while statement does nothing.
+If it is a timing loop, then you should use Thread.sleep() for it; if it is
+a while loop that does a lot in the exit expression, rewrite it to make it clearer.
+
+
This rule is defined by the following XPath expression:
If the finalize() is implemented, its last action should be to call super.finalize. Note that Oracle has declared Object.finalize() as deprecated since JDK 9.
+
+
This rule is defined by the following XPath expression:
If the finalize() is implemented, it should do something besides just calling super.finalize(). Note that Oracle has declared Object.finalize() as deprecated since JDK 9.
+
+
This rule is defined by the following XPath expression:
Methods named finalize() should not have parameters. It is confusing and most likely an attempt to
+overload Object.finalize(). It will not be called by the VM.
+
+
Note that Oracle has declared Object.finalize() as deprecated since JDK 9.
+
+
This rule is defined by the following XPath expression:
+
//MethodDeclaration[@Name='finalize'][@Arity>0]
+
+
+
Example(s):
+
+
publicclassFoo{
+ // this is confusing and probably a bug
+ protectedvoidfinalize(inta){
+ }
+}
+
LOGGER.error("forget the arg {}");
+LOGGER.error("too many args {}","arg1","arg2");
+LOGGER.error("param {}","arg1",newIllegalStateException("arg"));//The exception is shown separately, so is correct.
+
LOGGER.error("forget the arg {}");
+LOGGER.error("too many args {}","arg1","arg2");
+LOGGER.error("param {}","arg1",newIllegalStateException("arg"));//The exception is shown separately, so is correct.
+
In JUnit 3, the setUp method is used to set up all data entities required in running tests.
+The tearDown method is used to clean up all data entities required in running tests.
+You should not misspell method name if you want your test to set up and clean up everything correctly.
importjunit.framework.*;
+
+publicclassFooextendsTestCase{
+ publicvoidsetup(){}// oops, should be setUp
+ publicvoidTearDown(){}// oops, should be tearDown
+}
+
importjunit.framework.*;
+
+publicclassFooextendsTestCase{
+ publicvoidsuite(){}// oops, should be static
+ privatestaticvoidsuite(){}// oops, should be public
+}
+
The null check here is misplaced. If the variable is null a NullPointerException will be thrown.
+Either the check is useless (the variable will never be "null") or it is incorrect.
+
+
This rule is defined by the following XPath expression:
+
//ConditionalAndExpression
+ /EqualityExpression
+ [@Image='!=']
+ (: one side is null :)
+ [PrimaryExpression/PrimaryPrefix/Literal/NullLiteral]
+ (: other side checks for the variable used somewhere in the first child of conditional and expression :)
+ [some$varinpreceding-sibling::PrimaryExpression//Name
+ [not(ancestor::ConditionalOrExpression/EqualityExpression[@Image='=='])]
+ /@Image
+ satisfiesstarts-with($var,concat(PrimaryExpression/PrimaryPrefix/Name/@Image,'.'))]
+ /PrimaryExpression/PrimaryPrefix/Name
+|
+//ConditionalOrExpression
+ /EqualityExpression
+ [@Image='==']
+ (: one side is null :)
+ [PrimaryExpression/PrimaryPrefix/Literal/NullLiteral]
+ (: other side checks for the variable used somewhere in the first child of conditional or expression :)
+ [some$varinpreceding-sibling::PrimaryExpression//Name
+ [not(ancestor::ConditionalAndExpression/EqualityExpression[@Image='!='])]
+ /@Image
+ satisfiesstarts-with($var,concat(PrimaryExpression/PrimaryPrefix/Name/@Image,'.'))]
+ /PrimaryExpression/PrimaryPrefix/Name
+
+
+
Example(s):
+
+
publicclassFoo{
+ voidbar(){
+ if(a.equals(baz)&&a!=null){}// a could be null, misplaced null check
+
+ if(a!=null&&a.equals(baz)){}// correct null check
+ }
+}
+
+
+
publicclassFoo{
+ voidbar(){
+ if(a.equals(baz)||a==null){}// a could be null, misplaced null check
+
+ if(a==null||a.equals(baz)){}// correct null check
+ }
+}
+
Switch statements without break or return statements for each case option
+may indicate problematic behaviour. Empty cases are ignored as these indicate an intentional fall-through.
+
+
This rule is defined by the following XPath expression:
publicvoidbar(intstatus){
+ switch(status){
+ caseCANCELLED:
+ doCancelled();
+ // break; hm, should this be commented out?
+ caseNEW:
+ doNew();
+ // is this really a fall-through?
+ caseREMOVED:
+ doRemoved();
+ // what happens if you add another case after this one?
+ caseOTHER:// empty case - this is interpreted as an intentional fall-through
+ caseERROR:
+ doErrorHandling();
+ break;
+ }
+}
+
Serializable classes should provide a serialVersionUID field.
+The serialVersionUID field is also needed for abstract base classes. Each individual class in the inheritance
+chain needs an own serialVersionUID field. See also Should an abstract class have a serialVersionUID.
+
+
This rule is defined by the following XPath expression:
publicclassFooimplementsjava.io.Serializable{
+ Stringname;
+ // Define serialization id to avoid serialization related bugs
+ // i.e., public static final long serialVersionUID = 4328743;
+}
+
A class that has private constructors and does not have any static methods or fields cannot be used.
+
+
When one of the private constructors is annotated with one of the annotations, then the class is not considered
+non-instantiatable anymore and no violation will be reported.
+See the property annotations.
+
+
This rule is defined by the following XPath expression:
+
//ClassOrInterfaceDeclaration[@Nested=false()]
+[
+ (
+ (: at least one constructor :)
+ ./ClassOrInterfaceBody/ClassOrInterfaceBodyDeclaration/ConstructorDeclaration
+ and
+ (: only private constructors :)count(./ClassOrInterfaceBody/ClassOrInterfaceBodyDeclaration/ConstructorDeclaration)=count(./ClassOrInterfaceBody/ClassOrInterfaceBodyDeclaration/ConstructorDeclaration[@Private=true()])
+ and
+ (: all constructors must not be annotated :)
+ (every$xin$annotationssatisfies
+ not(./ClassOrInterfaceBody/ClassOrInterfaceBodyDeclaration/ConstructorDeclaration/
+ ../Annotation/MarkerAnnotation/Name[pmd-java:typeIs($x)]))
+ )
+ and
+ (: no static methods :)not(.//MethodDeclaration[@Static=true()])
+ and
+ (: no (public, package-private, protected) static fields :)not(.//FieldDeclaration[@Private=false()][@Static=true()])
+ and
+ (: no nested classes, that are public and static, and have no constructors at all or a public constructor :)
+ (: and have a method returning the outer class type :)
+ (: or the inner class extends the outer class :)not(.//ClassOrInterfaceDeclaration[@Nested=true()]
+ [@Public=true()]
+ [@Static=true()]
+ [not(./ClassOrInterfaceBody/ClassOrInterfaceBodyDeclaration/ConstructorDeclaration)or./ClassOrInterfaceBody/ClassOrInterfaceBodyDeclaration/ConstructorDeclaration[@Public=true()]]
+ [(./ClassOrInterfaceBody/ClassOrInterfaceBodyDeclaration/MethodDeclaration
+ [@Public=true()]
+ [./ResultType/Type/ReferenceType/ClassOrInterfaceType
+ [@Image=//ClassOrInterfaceDeclaration[@Nested=false()]/@SimpleName]
+ ]
+ )or(
+ ./ExtendsList/ClassOrInterfaceType[@Image=//ClassOrInterfaceDeclaration[@Nested=false()]/@SimpleName]
+ )]
+ )
+]
+
+
+
Example(s):
+
+
// This class is unusable, since it cannot be
+// instantiated (private constructor),
+// and no static method can be called.
+
+publicclassFoo{
+ privateFoo(){}
+ voidfoo(){}
+}
+
publicclassFoo{
+ Loggerlog=Logger.getLogger(Foo.class.getName());
+ // It is very rare to see two loggers on a class, normally
+ // log information is multiplexed by levels
+ Loggerlog2=Logger.getLogger(Foo.class.getName());
+}
+
A non-case label (e.g. a named break/continue label) was present in a switch statement.
+This legal, but confusing. It is easy to mix up the case labels and the non-case labels.
+
+
This rule is defined by the following XPath expression:
A non-static initializer block will be called any time a constructor is invoked (just prior to
+invoking the constructor). While this is a valid language construct, it is rarely used and is
+confusing.
+
+
This rule is defined by the following XPath expression:
Assigning a "null" to a variable (outside of its declaration) is usually bad form. Sometimes, this type
+of assignment is an indication that the programmer doesn’t completely understand what is going on in the code.
+
+
NOTE: This sort of assignment may used in some cases to dereference objects and encourage garbage collection.
publicvoidbar(){
+ Objectx=null;// this is OK
+ x=newObject();
+ // big, complex piece of code here
+ x=null;// this is not required
+ // big, complex piece of code here
+}
+
Override both public boolean Object.equals(Object other), and public int Object.hashCode(), or override neither. Even if you are inheriting a hashCode() from a parent class, consider implementing hashCode and explicitly delegating to your superclass.
A logger should normally be defined private static final and be associated with the correct class.
+private final Log log; is also allowed for rare cases where loggers need to be passed around,
+with the restriction that the logger needs to be passed into the constructor.
+
+
This rule is defined by the following XPath expression:
+
//FieldDeclaration
+[Type/ReferenceType/ClassOrInterfaceType[pmd-java:typeIs($loggerClass)]]
+[
+ (: check modifiers :)
+ (@Private=false()or@Final=false())
+ (: check logger name :)
+ or(@StaticandVariableDeclarator/VariableDeclaratorId[@Name!=$staticLoggerName])
+ or(@Static=false()andVariableDeclarator/VariableDeclaratorId[@Name!=$loggerName])
+
+ (: check logger argument type matches class or enum name :)
+ or.//ArgumentList//ClassOrInterfaceType[@Image!=ancestor::ClassOrInterfaceDeclaration/@SimpleName]
+ or.//ArgumentList//ClassOrInterfaceType[@Image!=ancestor::EnumDeclaration/@SimpleName]
+]
+[not(
+ (: special case - final logger initialized inside constructor :)
+ not(VariableDeclarator/VariableInitializer)
+ and@Static=false()
+ and
+ ancestor::ClassOrInterfaceBody//ConstructorDeclaration//StatementExpression
+ [PrimaryExpression[PrimaryPrefix[@ThisModifier]]/PrimarySuffix[@Image=$loggerName]]
+ [AssignmentOperator[@Image='=']]
+ [Expression/PrimaryExpression/PrimaryPrefix/Name[@Image=ancestor::ConstructorDeclaration//FormalParameter/VariableDeclaratorId/@Name]]
+ [not(.//AllocationExpression)]
+ )
+]
+
For any method that returns an array, it is a better to return an empty array rather than a
+null reference. This removes the need for null checking all results and avoids inadvertent
+NullPointerExceptions.
+
+
This rule is defined by the following XPath expression:
Some classes contain overloaded getInstance. The problem with overloaded getInstance methods
+is that the instance created using the overloaded method is not cached and so,
+for each call and new objects will be created for every invocation.
Some classes contain overloaded getInstance. The problem with overloaded getInstance methods
+is that the instance created using the overloaded method is not cached and so,
+for each call and new objects will be created for every invocation.
According to the J2EE specification, an EJB should not have any static fields
+with write access. However, static read-only fields are allowed. This ensures proper
+behavior especially when instances are distributed by the container on several JREs.
+
+
This rule is defined by the following XPath expression:
+
//ClassOrInterfaceDeclaration[
+ (
+ (./ImplementsList/ClassOrInterfaceType[ends-with(@Image,'SessionBean')])
+ or
+ (./ImplementsList/ClassOrInterfaceType[ends-with(@Image,'EJBHome')])
+ or
+ (./ImplementsList/ClassOrInterfaceType[ends-with(@Image,'EJBLocalObject')])
+ or
+ (./ImplementsList/ClassOrInterfaceType[ends-with(@Image,'EJBLocalHome')])
+ or
+ (./ExtendsList/ClassOrInterfaceType[ends-with(@Image,'EJBObject')])
+ )
+ and
+ (./ClassOrInterfaceBody/ClassOrInterfaceBodyDeclaration[
+ (./FieldDeclaration[@Static=true()])
+ and
+ (./FieldDeclaration[@Final=false()])
+ ])
+]
+
+
+
Example(s):
+
+
publicclassSomeEJBextendsEJBObjectimplementsEJBLocalHome{
+
+ privatestaticintCountA;// poor, field can be edited
+
+ privatestaticfinalintCountB;// preferred, read-only access
+}
+
Individual character values provided as initialization arguments will be converted into integers.
+This can lead to internal buffer sizes that are larger than expected. Some examples:
// misleading instantiation, these buffers
+// are actually sized to 99 characters long
+StringBuffersb1=newStringBuffer('c');
+StringBuildersb2=newStringBuilder('c');
+
+// in these forms, just single characters are allocated
+StringBuffersb3=newStringBuffer("c");
+StringBuildersb4=newStringBuilder("c");
+
The method name and parameter number are suspiciously close to Object.equals, which can denote an
+intention to override it. However, the method does not override Object.equals, but overloads it instead.
+Overloading Object.equals method is confusing for other programmers, error-prone and hard to maintain,
+especially when using inheritance, because @Override annotations used in subclasses can provide a false
+sense of security. For more information on Object.equals method, see Effective Java, 3rd Edition,
+Item 10: Obey the general contract when overriding equals.
+
+
This rule is defined by the following XPath expression:
publicclassFoo{
+ publicintequals(Objecto){
+ // oops, this probably was supposed to be boolean equals
+ }
+ publicbooleanequals(Strings){
+ // oops, this probably was supposed to be equals(Object)
+ }
+ publicbooleanequals(Objecto1,Objecto2){
+ // oops, this probably was supposed to be equals(Object)
+ }
+}
+
A suspicious octal escape sequence was found inside a String literal.
+The Java language specification (section 3.10.6) says an octal
+escape sequence inside a literal String shall consist of a backslash
+followed by:
Any octal escape sequence followed by non-octal digits can be confusing,
+e.g. "\038" is interpreted as the octal escape sequence "\03" followed by
+the literal character "8".
Test classes end with the suffix Test. Having a non-test class with that name is not a good practice,
+since most people will assume it is a test case. Test classes have test methods named testXXX.
//Consider changing the name of the class if it is not a test
+//Consider adding test methods if it is a test
+publicclassCarTest{
+ publicstaticvoidmain(String[]args){
+ // do something
+ }
+ // code
+}
+
A JUnit test assertion with a boolean literal is unnecessary since it always will evaluate to the same thing.
+Consider using flow control (in case of assertTrue(false) or similar) or simply removing
+statements like assertTrue(true) and assertFalse(false). If you just want a test to halt after finding
+an error, use the fail() method and provide an indication message of why it did.
+
+
This rule is defined by the following XPath expression:
booleananswer1=buz.toUpperCase().equals("baz");// should be buz.equalsIgnoreCase("baz")
+
+booleananswer2=buz.toUpperCase().equalsIgnoreCase("baz");// another unnecessary toUpperCase()
+
An operation on an Immutable object (String, BigDecimal or BigInteger) won’t change the object itself
+since the result of the operation is a new object. Therefore, ignoring the operation result is an error.
When doing String::toLowerCase()/toUpperCase() conversions, use an explicit locale argument to specify the case transformation rules.
+
+
Using String::toLowerCase() without arguments implicitly uses Locale::getDefault().
+The problem is that the default locale depends on the current JVM setup (and usually on the system in which it is running).
+Using the system default may be exactly what you want (e.g. if you are manipulating strings you got through standard input),
+but it may as well not be the case (e.g. if you are getting the string over the network or a file, and the encoding is well-defined
+and independent of the environment). In the latter case, using the default locale makes the case transformation brittle, as
+it may yield unexpected results on a machine whose locale has other case translation rules. For example, in Turkish, the
+uppercase form of i is İ (U+0130, not ASCII) and not I (U+0049) as in English.
+
+
The rule is intended to force developers to think about locales when dealing with strings. By taking a conscious decision about
+the choice of locale at the time of writing, you reduce the risk of surprising behaviour down the line, and communicate your intent
+to future readers.
+
+
This rule is defined by the following XPath expression:
// violation - implicitly system-dependent conversion
+if(x.toLowerCase().equals("list")){}
+
+// The above will not match "LIST" on a system with a Turkish locale.
+// It could be replaced with
+if(x.toLowerCase(Locale.US).equals("list")){}
+// or simply
+if(x.equalsIgnoreCase("list")){}
+
+// ok - system independent conversion
+Stringz=a.toLowerCase(Locale.ROOT);
+
+// ok - explicit system-dependent conversion
+Stringz2=a.toLowerCase(Locale.getDefault());
+
Method-level synchronization can cause problems when new code is added to the method.
+Block-level synchronization helps to ensure that only the code that needs synchronization
+gets it.
+
+
This rule is defined by the following XPath expression:
+
//MethodDeclaration[@Synchronized=true()]
+
+
+
Example(s):
+
+
publicclassFoo{
+ // Try to avoid this:
+ synchronizedvoidfoo(){
+ // code, that doesn't need synchronization
+ // ...
+ // code, that requires synchronization
+ if(!sharedData.has("bar")){
+ sharedData.add("bar");
+ }
+ // more code, that doesn't need synchronization
+ // ...
+ }
+ // Prefer this:
+ voidbar(){
+ // code, that doesn't need synchronization
+ // ...
+ synchronized(this){
+ if(!sharedData.has("bar")){
+ sharedData.add("bar");
+ }
+ }
+ // more code, that doesn't need synchronization
+ // ...
+ }
+
+ // Try to avoid this for static methods:
+ staticsynchronizedvoidfooStatic(){
+ }
+
+ // Prefer this:
+ staticvoidbarStatic(){
+ // code, that doesn't need synchronization
+ // ...
+ synchronized(Foo.class){
+ // code, that requires synchronization
+ }
+ // more code, that doesn't need synchronization
+ // ...
+ }
+}
+
Use of the keyword ‘volatile’ is generally used to fine tune a Java application, and therefore, requires
+a good expertise of the Java Memory Model. Moreover, its range of action is somewhat misknown. Therefore,
+the volatile keyword should not be used for maintenance purpose and portability.
+
+
This rule is defined by the following XPath expression:
+
//FieldDeclaration[@Volatile=true()]
+
+
+
Example(s):
+
+
publicclassThrDeux{
+ privatevolatileStringvar1;// not suggested
+ privateStringvar2;// preferred
+}
+
The J2EE specification explicitly forbids the use of threads. Threads are resources, that should be managed and monitored by the J2EE server.
+If the application creates threads on its own or uses own custom thread pools, then these threads are not managed, which could lead to resource exhaustion.
+Also EJB’s might be moved between machines in a cluster and only managed resources can be moved along.
+
+
This rule is defined by the following XPath expression:
Partially created objects can be returned by the Double Checked Locking pattern when used in Java.
+An optimizing JRE may assign a reference to the baz variable before it calls the constructor of the object the
+reference points to.
+
+
Note: With Java 5, you can make Double checked locking work, if you declare the variable to be volatile.
Non-thread safe singletons can result in bad state changes. Eliminate
+static singletons if possible by instantiating the object directly. Static
+singletons are usually not needed as only a single instance exists anyway.
+Other possible fixes are to synchronize the entire method or to use an
+initialize-on-demand holder class.
+
+
Refrain from using the double-checked locking pattern. The Java Memory Model doesn’t
+guarantee it to work unless the variable is declared as volatile, adding an uneeded
+performance penalty. Reference
SimpleDateFormat instances are not synchronized. Sun recommends using separate format instances
+for each thread. If multiple threads must access a static formatter, the formatter must be
+synchronized on block level.
Instances of java.text.Format are generally not synchronized.
+Sun recommends using separate format instances for each thread.
+If multiple threads must access a static formatter, the formatter must be
+synchronized on block level.
Since Java5 brought a new implementation of the Map designed for multi-threaded access, you can
+perform efficient map reads without blocking other threads.
+
+
This rule is defined by the following XPath expression:
publicclassConcurrentApp{
+ publicvoidgetMyInstance(){
+ Mapmap1=newHashMap();// fine for single-threaded access
+ Mapmap2=newConcurrentHashMap();// preferred for use with multiple threads
+
+ // the following case will be ignored by this rule
+ Mapmap3=someModule.methodThatReturnMap();// might be OK, if the returned map is already thread-safe
+ }
+}
+
Thread.notify() awakens a thread monitoring the object. If more than one thread is monitoring, then only
+one is chosen. The thread chosen is arbitrary; thus its usually safer to call notifyAll() instead.
+
+
This rule is defined by the following XPath expression:
voidbar(){
+ x.notify();
+ // If many threads are monitoring x, only one (and you won't know which) will be notified.
+ // use instead:
+ x.notifyAll();
+ }
+
The conversion of literals to strings by concatenating them with empty strings is inefficient.
+It is much better to use one of the type-specific toString() methods instead.
+
+
This rule is defined by the following XPath expression:
Problem: A Calendar is a heavyweight object and expensive to create.
+
+
Solution: Use new Date(), Java 8+ java.time.LocalDateTime.now() or ZonedDateTime.now().
+
+
This rule is defined by the following XPath expression:
+
//PrimaryPrefix[Name[ends-with(@Image,'Calendar.getInstance')]][count(../PrimarySuffix)>2and../PrimarySuffix[last()-1][@Image='getTime'or@Image='getTimeInMillis']]
+|
+//MethodDeclaration[not(MethodDeclarator/FormalParameters//ClassOrInterfaceType[pmd-java:typeIs('java.util.Calendar')])]
+ /Block/BlockStatement//PrimaryExpression
+ /PrimaryPrefix/Name
+ [pmd-java:typeIs('java.util.Calendar')]
+ [every$varin@Imagesatisfies(
+ (ends-with($var,'.getTime')orends-with($var,'.getTimeInMillis'))
+ and
+ (: ignore if .set* or .add* or .clear is called on the variable :)
+ not(ancestor::Block/BlockStatement//Name[
+ starts-with(@Image,concat((tokenize($var,'\.'),$var)[1],'.set'))
+ or
+ starts-with(@Image,concat((tokenize($var,'\.'),$var)[1],'.add'))
+ or
+ starts-with(@Image,concat((tokenize($var,'\.'),$var)[1],'.clear'))
+ ])
+ )]
+|
+//ClassOrInterfaceType[pmd-java:typeIs('org.joda.time.DateTime')orpmd-java:typeIs('org.joda.time.LocalDateTime')][../Arguments/ArgumentList/Expression/PrimaryExpression/PrimaryPrefix/Name[ends-with(@Image,'Calendar.getInstance')]]
+
The FileInputStream and FileOutputStream classes contains a finalizer method which will cause garbage
+collection pauses.
+See JDK-8080225 for details.
+
+
The FileReader and FileWriter constructors instantiate FileInputStream and FileOutputStream,
+again causing garbage collection issues while finalizer methods are called.
+
+
+
Use Files.newInputStream(Paths.get(fileName)) instead of new FileInputStream(fileName).
+
Use Files.newOutputStream(Paths.get(fileName)) instead of new FileOutputStream(fileName).
+
Use Files.newBufferedReader(Paths.get(fileName)) instead of new FileReader(fileName).
+
Use Files.newBufferedWriter(Paths.get(fileName)) instead of new FileWriter(fileName).
+
+
+
Please note, that the java.nio API does not throw a FileNotFoundException anymore, instead
+it throws a NoSuchFileException. If your code dealt explicitly with a FileNotFoundException,
+then this needs to be adjusted. Both exceptions are subclasses of IOException, so catching
+that one covers both.
+
+
This rule is defined by the following XPath expression:
Java uses the ‘short’ type to reduce memory usage, not to optimize calculation. In fact, the JVM does not have any
+arithmetic capabilities for the short type: the JVM must convert the short into an int, do the proper calculation
+and convert the int back to a short. Thus any storage gains found through use of the ‘short’ type may be offset by
+adverse impacts on performance.
+
+
This rule is defined by the following XPath expression:
Avoid instantiating Boolean objects; you can reference Boolean.TRUE, Boolean.FALSE, or call Boolean.valueOf() instead.
+Note that new Boolean() is deprecated since JDK 9 for that reason.
Calling new Byte() causes memory allocation that can be avoided by the static Byte.valueOf().
+It makes use of an internal cache that recycles earlier instances making it more memory efficient.
+Note that new Byte() is deprecated since JDK 9 for that reason.
+
+
This rule is defined by the following XPath expression:
Consecutive calls to StringBuffer/StringBuilder .append should be chained, reusing the target object. This can improve the performance
+by producing a smaller bytecode, reducing overhead and improving inlining. A complete analysis can be found here
Consecutively calling StringBuffer/StringBuilder.append(…) with literals should be avoided.
+Since the literals are constants, they can already be combined into a single String literal and this String
+can be appended in a single method call.
String.trim().length() == 0 (or String.trim().isEmpty() for the same reason) is an inefficient
+way to check if a String is really blank, as it creates a new String object just to check its size.
+Consider creating a static function that loops through a string, checking Character.isWhitespace()
+on each character and returning false if a non-whitespace character is found. A Smarter code to
+check for an empty string would be:
You can refer to Apache’s StringUtils#isBlank (in commons-lang),
+Spring’s StringUtils#hasText (in the Spring framework) or Google’s
+CharMatcher#whitespace (in Guava) for existing implementations (some might
+include the check for != null).
Avoid concatenating non-literals in a StringBuffer constructor or append() since intermediate buffers will
+need to be be created and destroyed by the JVM.
// Avoid this, two buffers are actually being created here
+StringBuffersb=newStringBuffer("tmp = "+System.getProperty("java.io.tmpdir"));
+
+// do this instead
+StringBuffersb=newStringBuffer("tmp = ");
+sb.append(System.getProperty("java.io.tmpdir"));
+
Failing to pre-size a StringBuffer or StringBuilder properly could cause it to re-size many times
+during runtime. This rule attempts to determine the total number the characters that are actually
+passed into StringBuffer.append(), but represents a best guess "worst case" scenario. An empty
+StringBuffer/StringBuilder constructor initializes the object to 16 characters. This default
+is assumed if the length of the constructor can not be determined.
StringBufferbad=newStringBuffer();
+bad.append("This is a long string that will exceed the default 16 characters");
+
+StringBuffergood=newStringBuffer(41);
+good.append("This is a long string, which is pre-sized");
+
Calling new Integer() causes memory allocation that can be avoided by the static Integer.valueOf().
+It makes use of an internal cache that recycles earlier instances making it more memory efficient.
+Note that new Integer() is deprecated since JDK 9 for that reason.
+
+
This rule is defined by the following XPath expression:
Calling new Long() causes memory allocation that can be avoided by the static Long.valueOf().
+It makes use of an internal cache that recycles earlier instances making it more memory efficient.
+Note that new Long() is deprecated since JDK 9 for that reason.
+
+
This rule is defined by the following XPath expression:
Calls to a collection’s toArray(E[]) method should specify a target array of zero size. This allows the JVM
+to optimize the memory allocation and copying as much as possible.
+
+
Previous versions of this rule (pre PMD 6.0.0) suggested the opposite, but current JVM implementations
+perform always better, when they have full control over the target array. And allocation an array via
+reflection is nowadays as fast as the direct allocation.
Note: If you don’t need an array of the correct type, then the simple toArray() method without an array
+is faster, but returns only an array of type Object[].
+
+
This rule is defined by the following XPath expression:
List<Foo>foos=getFoos();
+
+// much better; this one allows the jvm to allocate an array of the correct size and effectively skip
+// the zeroing, since each array element will be overridden anyways
+Foo[]fooArray=foos.toArray(newFoo[0]);
+
+// inefficient, the array needs to be zeroed out by the jvm before it is handed over to the toArray method
+Foo[]fooArray=foos.toArray(newFoo[foos.size()]);
+
Java will initialize fields with known default values so any explicit initialization of those same defaults
+is redundant and results in a larger class file (approximately three additional bytecode instructions per field).
Calling new Short() causes memory allocation that can be avoided by the static Short.valueOf().
+It makes use of an internal cache that recycles earlier instances making it more memory efficient.
+Note that new Short() is deprecated since JDK 9 for that reason.
+
+
This rule is defined by the following XPath expression:
Calls to string.startsWith("x") with a string literal of length 1 can be rewritten using string.charAt(0),
+at the expense of some readability. To prevent IndexOutOfBoundsException being thrown by the charAt method,
+ensure that the string is not empty by making an additional check first.
+
+
This rule is defined by the following XPath expression:
Switch statements are intended to be used to support complex branching behaviour. Using a switch for only a few
+cases is ill-advised, since switches are not as easy to understand as if-then statements. In these cases use the
+if-then statement to increase code readability.
+
+
This rule is defined by the following XPath expression:
// With a minimumNumberCaseForASwitch of 3
+publicclassFoo{
+ publicvoidbar(){
+ switch(condition){
+ caseONE:
+ instruction;
+ break;
+ default:
+ break;// not enough for a 'switch' stmt, a simple 'if' stmt would have been more appropriate
+ }
+ }
+}
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
minimumNumberCaseForASwitch
+
3
+
Minimum number of branches for a switch
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
Most wrapper classes provide static conversion methods that avoid the need to create intermediate objects
+just to create the primitive forms. Using these avoids the cost of creating objects that also need to be
+garbage-collected later.
publicintconvert(Strings){
+ inti,i2;
+
+ i=Integer.valueOf(s).intValue();// this wastes an object
+ i=Integer.parseInt(s);// this is better
+
+ i2=Integer.valueOf(i).intValue();// this wastes an object
+ i2=i;// this is better
+
+ Strings3=Integer.valueOf(i2).toString();// this wastes an object
+ s3=Integer.toString(i2);// this is better
+
+ returni2;
+}
+
publicclassSimpleTestextendsTestCase{
+ publicvoidtestX(){
+ Collectionc1=newVector();
+ Collectionc2=newArrayList();// achieves the same with much better performance
+ }
+}
+
The java.util.Arrays class has a "asList" method that should be used when you want to create a new List from
+an array of objects. It is faster than executing a loop to copy all the elements of the array one by one.
+
+
Note that the result of Arrays.asList() is backed by the specified array,
+changes in the returned list will result in the array to be modified.
+For that reason, it is not possible to add new elements to the returned list of Arrays.asList() (UnsupportedOperationException).
+You must use new ArrayList<>(Arrays.asList(…)) if that is inconvenient for you (e.g. because of concurrent access).
+
+
This rule is defined by the following XPath expression:
The use of the ‘+=’ operator for appending strings causes the JVM to create and use an internal StringBuffer.
+If a non-trivial number of these concatenations are being used then the explicit use of a StringBuilder or
+threadsafe StringBuffer is recommended to avoid this.
Use StringBuffer.length() to determine StringBuffer length rather than using StringBuffer.toString().equals("")
+or StringBuffer.toString().length() == …
In a production system, HTML comments increase the payload
+between the application server to the client, and serve
+little other purpose. Consider switching to JSP comments.
+
+
This rule is defined by the following XPath expression:
Avoid inlining HTML script content. Consider externalizing the HTML script using the ‘src’ attribute on the "script" element.
+Externalized script could be reused between pages. Browsers can also cache the script, reducing overall download bandwidth.
+
+
This rule is defined by the following XPath expression:
Most browsers should be able to interpret the following headers:
+
+<%@ page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
+
+<metahttp-equiv="Content-Type"content="text/html; charset=UTF-8"/>
+
IFrames which are missing a src element can cause security information popups in IE if you are accessing the page
+through SSL. See http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q261188
+
+
This rule is defined by the following XPath expression:
Avoid using expressions without escaping / sanitizing. This could lead to cross site scripting - as the expression
+would be interpreted by the browser directly (e.g. "<script>alert(‘hello’);</script>").
package Test
+ package Inc1
+ model X
+ end X;
+ model Y
+ end Y;
+ end Inc1;
+ package Inc2
+ model Y
+ end Y;
+ model Z
+ end Z;
+ end Inc2;
+ model B
+ import Test.Inc1.*;
+ import Test.Inc2.*;
+ Y y; // Class Y is imported twice
+ end B;
+end Test;
+
package Example
+ connector Conn
+ Real x;
+ Real y;
+ end Conn;
+
+ model Test
+ input Conn c1;
+ output Conn c2;
+ input Real x1;
+ output Real x2;
+ equation
+ connect(c1, c2); // OK
+ connect(x1, x2); // error, x1 and x2 are not (both) connectors
+ // x1 = x2; // OK
+ end Test;
+end Example;
+
BEGIN
+ -- select columns each on a separate line
+ SELECTcmer_id
+ ,version
+ ,cmp_id
+ BULKCOLLECTINTOv_cmer_ids
+ ,v_versions
+ ,v_cmp_ids
+ FROMcmer;
+
+ -- each parameter on a new line
+ PROCEDUREcreate_prospect(
+ company_info_inINprospects.company_info%TYPE-- Organization
+ ,firstname_inINpersons.firstname%TYPE-- FirstName
+ ,lastname_inINpersons.lastname%TYPE-- LastName
+ );
+
+ -- more than three parameters, each parameter on a separate line
+ webcrm_marketing.prospect_ins(
+ cmp_id_in=>NULL
+ ,company_info_in=>company_info_in
+ ,firstname_in=>firstname_in
+ ,lastname_in=>lastname_in
+ ,slt_code_in=>NULL
+ );
+
+END;
+
+
+
This rule has the following properties:
+
+
+
+
+
Name
+
Default Value
+
Description
+
Multivalued
+
+
+
+
+
indentation
+
2
+
Indentation to be used for blocks
+
no
+
+
+
+
+
Use this rule with the default properties by just referencing it:
Oracle states that the PRAQMA AUTONOMOUS_TRANSACTION must be in the declaration block,
+but the code does not complain, when being compiled on the 11g DB.
+https://docs.oracle.com/cd/B28359_01/appdev.111/b28370/static.htm#BABIIHBJ
+
+
This rule is defined by the following XPath expression:
+
//ProgramUnit/Pragma
+
+
+
Example(s):
+
+
createorreplacepackageinline_pragma_erroris
+
+end;
+/
+
+createorreplacepackagebodyinline_pragma_erroris
+ proceduredo_transaction(p_input_tokeninvarchar(200))is
+ PRAGMAAUTONOMOUS_TRANSACTION;/* this is correct place for PRAGMA */
+ begin
+ PRAGMAAUTONOMOUS_TRANSACTION;/* this is the wrong place for PRAGMA -> violation */
+ /* do something */
+ COMMIT;
+ enddo_transaction;
+
+endinline_pragma_error;
+/
+
Complexity directly affects maintenance costs is determined by the number of decision points in a method
+plus one for the method entry. The decision points include ‘if’, ‘while’, ‘for’, and ‘case labels’ calls.
+Generally, numbers ranging from 1-4 denote low complexity, 5-7 denote moderate complexity, 8-10 denote
+high complexity, and 11+ is very high complexity.
When methods are excessively long this usually indicates that the method is doing more than its
+name/signature might suggest. They also become challenging for others to digest since excessive
+scrolling causes readers to lose focus.
+Try to reduce the method length by creating helper methods and removing any copy/pasted code.
Excessive object line lengths are usually indications that the object may be burdened with excessive
+responsibilities that could be provided by other objects. In breaking these methods
+apart the code becomes more managable and ripe for reuse.
Excessive class file lengths are usually indications that the class may be burdened with excessive
+responsibilities that could be provided by external classes or functions. In breaking these methods
+apart the code becomes more managable and ripe for reuse.
Excessive class file lengths are usually indications that the class may be burdened with excessive
+responsibilities that could be provided by external classes or functions. In breaking these methods
+apart the code becomes more managable and ripe for reuse.
Methods with numerous parameters are a challenge to maintain, especially if most of them share the
+same datatype. These situations usually denote the need for new objects to wrap the numerous parameters.
Excessive class file lengths are usually indications that the class may be burdened with excessive
+responsibilities that could be provided by external classes or functions. In breaking these methods
+apart the code becomes more managable and ripe for reuse.
This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of lines
+of code for a given method. NCSS ignores comments, and counts actual statements. Using this algorithm,
+lines of code that are split are counted as one.
This rule uses the NCSS (Non-Commenting Source Statements) algorithm to determine the number of lines
+of code for a given Oracle object. NCSS ignores comments, and counts actual statements. Using this algorithm,
+lines of code that are split are counted as one.
The NPath complexity of a method is the number of acyclic execution paths through that method.
+A threshold of 200 is generally considered the point where measures should be taken to reduce
+complexity and increase readability.
Classes that have too many fields can become unwieldy and could be redesigned to have fewer fields,
+possibly through grouping related fields in new objects. For example, a class with individual
+city/state/zip fields could park them within a single Address field.
A package or type with too many methods is probably a good suspect for refactoring, in order to reduce its complexity and find a way to
+have more fine grained objects.
+
+
This rule is defined by the following XPath expression:
CREATEORREPLACEPACKAGEBODYdate_utilities
+IS
+
+-- Take single parameter, relying on current default NLS date format
+FUNCTIONstrip_time(p_dateINDATE)RETURNDATE
+IS
+BEGIN
+ RETURNTO_DATE(TO_CHAR(p_date));
+ENDstrip_time;
+
+
+ENDdate_utilities;
+/
+
CREATEORREPLACEPACKAGEBODYdate_utilities
+IS
+
+-- Take single parameter, relying on current default NLS date format
+FUNCTIONto_date_single_parameter(p_date_stringINVARCHAR2)RETURNDATE
+IS
+BEGIN
+ RETURNTO_DATE(p_date_string);
+ENDto_date_single_parameter;
+
+-- Take 2 parameters, using an explicit date format string
+FUNCTIONto_date_two_parameters(p_date_stringINVARCHAR2,p_format_maskINVARCHAR2)RETURNDATE
+IS
+BEGIN
+ TO_DATE(p_date_string,p_date_format);
+ENDto_date_two_parameters;
+
+-- Take 3 parameters, using an explicit date format string and an explicit language
+FUNCTIONto_date_three_parameters(p_date_stringINVARCHAR2,p_format_maskINVARCHAR2,p_nls_languageVARCHAR2)RETURNDATE
+IS
+BEGIN
+ TO_DATE(p_date_string,p_format_mask,p_nls_language);
+ENDto_date_three_parameters;
+
+ENDdate_utilities;
+/
+
CREATEORREPLACEPACKAGEBODYdate_utilities
+IS
+
+-- Take single parameter, relying on current default NLS date format
+FUNCTIONto_timestamp_single_parameter(p_date_stringINVARCHAR2)RETURNDATE
+IS
+BEGIN
+ RETURNTO_TIMESTAMP(p_date_string);
+ENDto_timestamp_single_parameter;
+
+-- Take 2 parameters, using an explicit date format string
+FUNCTIONto_timestamp_two_parameters(p_date_stringINVARCHAR2,p_format_maskINVARCHAR2)RETURNDATE
+IS
+BEGIN
+ TO_TIMESTAMP(p_date_string,p_date_format);
+ENDto_timestamp_two_parameters;
+
+-- Take 3 parameters, using an explicit date format string and an explicit language
+FUNCTIONto_timestamp_three_parameters(p_date_stringINVARCHAR2,p_format_maskINVARCHAR2,p_nls_languageVARCHAR2)RETURNDATE
+IS
+BEGIN
+ TO_TIMESTAMP(p_date_string,p_format_mask,p_nls_language);
+ENDto_timestamp_three_parameters;
+
+ENDdate_utilities;
+/
+
If you use an invalid dependency type in the dependency management section, Maven doesn’t fail. Instead,
+the entry is just ignored, which might have the effect, that the wrong version of the dependency is used.
+
+
The following types are considered valid: pom, jar, maven-plugin, ejb, war, ear, rar, par.
+
+
This rule is defined by the following XPath expression:
Using that expression in dependency declarations seems like a shortcut, but it can go wrong.
+By far the most common problem is the use of ${project.version} in a BOM or parent POM.
+
+
This rule is defined by the following XPath expression:
<root>
+ <child>
+ <![CDATA[[ character data ]]> - this cdata section is valid, but it contains an
+ additional square bracket at the beginning.
+ It should probably be just <![CDATA[ character data ]]>.
+ </child>
+ <child>
+ <![CDATA[ character data ]]]> - this cdata section is valid, but it contains an
+ additional square bracket in the end.
+ It should probably be just <![CDATA[ character data ]]>.
+ </child>
+</root>
+
Avoid using the ‘following’ or ‘preceding’ axes whenever possible, as these can cut
+through 100% of the document in the worst case. Also, try to avoid using ‘descendant’
+or ‘descendant-or-self’ axes, as if you’re at the top of the Document, it necessarily means
+cutting through 100% of the document.
+
+
This rule is defined by the following XPath expression:
+
//node()[
+ contains(@select,'preceding::')
+ or
+ contains(@select,'following::')
+ or
+ contains(@select,'descendant::')
+ or
+ contains(@select,'descendant-self::')
+ or(
+ ($checkSelfDescendantAbreviation=true())
+ and
+ contains(@select,'//')
+ )
+]
+
Running every existing rule will result in a huge number of rule violations, most of which will be unimportant.
+Having to sort through a thousand line report to find the few you’re really interested in takes
+all the fun out of things.
+
+
Instead, start with some selected specific rules, e.g. the rules that detect unused code from
+the category Best Practices and fix any unused locals and fields.
+
+
Then, run rules, that detect empty if statements and such-like. You can find these rules in the category
+Error Prone.
+
+
After that, look at all the categories and select the rules, that are useful for your project.
+You can find an overview of the rules on the Rule Index.
Generally, pick the ones you like, and ignore or suppress
+the warnings you don’t like. It’s just a tool.
+
+
PMD IDE plugins are nice
+
+
Using PMD within your IDE is much more enjoyable than flipping back and forth
+between an HTML report and your IDE. Most IDE plugins have the “click on the rule
+violation and jump to that line of code” feature. Find the PMD plugin for your IDE, install it,
+and soon you’ll be fixing problems much faster.
Specifies the classpath for libraries used by the source code.
+ This is used to resolve types in source files. The platform specific path delimiter
+ (":" on Linux, ";" on Windows) is used to separate the entries.
+ Alternatively, a single file: URL
+ to a text file containing path elements on consecutive lines can be specified.
Specify the location of the cache file for incremental analysis.
+ This should be the full path to the file, including the desired file name (not just the parent directory).
+ If the file doesn't exist, it will be created on the first run. The file will be overwritten on each run
+ with the most up-to-date rule violations.
+ This can greatly improve analysis performance and is highly recommended.
Specifies the character set encoding of the source code files PMD is reading.
+ The valid values are the standard character sets of java.nio.charset.Charset.
Specifies whether PMD exits with non-zero status if violations are found.
+ By default PMD exits with status 4 if violations are found.
+ Disable this feature with -failOnViolation false to exit with 0 instead and just output the report.
Path to file containing a comma delimited list of files to ignore.
+ This option can be combined with -dir and -filelist.
+ This ignore list takes precedence over any files in the filelist.
Disable automatic fixing of invalid rule references. Without the switch, PMD tries to automatically replace rule references that point to moved or renamed rules with the newer location if possible. Disabling it is not recommended.
Explicitly disables incremental analysis. This switch turns off suggestions to use Incremental Analysis,
+ and causes the -cache option to be discarded if it is provided.
Specify the version of a language PMD should use. Used together with -language. See also Supported Languages.
+
+
+
+
+
+
+
Additional Java Runtime Options
+
+
PMD is executed via a Java runtime. In some cases, you might need to set additional runtime options, e.g.
+if you want to analyze a project, that uses one of OpenJDK’s Preview Language Features.
+
+
Just set the environment variable PMD_JAVA_OPTS before executing PMD, e.g.
Please note that if PMD detects any violations, it will exit with status 4 (since 5.3).
+This behavior has been introduced to ease PMD integration into scripts or hooks, such as SVN hooks.
+
+
+
0
Everything is fine, no violations found
+
1
Couldn't understand command-line parameters or PMD exited with an exception
+
4
At least one violation has been detected, unless -failOnViolation false is set.
+
+
+
Supported Languages
+
+
The language is determined automatically by PMD from the file extensions. Some languages such as “Java”
+however support multiple versions. The default version will be used, which is usually the latest supported
+version. If you want to use an older version, so that e.g. rules, that suggest usage of language features,
+that are not available yet, won’t be executed, you need to specify a specific version via the -language
+and -version parameter.
+
+
These parameters are irrelevant for languages that don’t support different versions.
You can change a rule’s message by specifying a message
+attribute on the rule element. This will override the previous
+value and change the message the rule will print on the report.
+
+
Similarly, the priority of a rule can be changed via a nested
+element. Using priority, you can deactivate some rules based on a
+minimum priority threshold (set using the -min CLI option).
+Priority is an integer ranging from 1 to 5, with 1 being the highest
+priority.
+
+
Putting things together, the following rule reference lowers the priority
+of EmptyCatchBlock to 5, such that e.g. using the -min 4 CLI parameters
+will cause the rule to be ignored.
+
+
<ruleref="category/java/errorprone.xml/EmptyCatchBlock"
+ message="Empty catch blocks should be avoided">
+ <priority>5</priority>
+</rule>
+
+
+
Rule properties
+
+
Properties make it easy to customise the behaviour of a rule directly from the xml. They come in several types, which correspond to the type of their values. For example, NPathComplexity declares a property “reportLevel”, with an integer value type, and which corresponds to the threshold above which a method will be reported. If you believe that its default value of 200 is too high, you could lower it to e.g. 150 in the following way:
Properties are assigned a value with a property element, which should mention the name of a property as an attribute. The value of the property can be specified either in the content of the element, like above, or in the value attribute, e.g.
+
+
<propertyname="reportLevel"value="150"/>
+
+
+
All property assignments must be enclosed in a properties element, which is itself inside a rule element.
+
+
Tip: The properties of a rule are documented with the rule, e.g. here for NPathComplexity. Note that assigning a value to a property that does not exist throws an error!
+
+
Some properties take multiple values (a list), in which case you can provide them all by delimiting them with a delimiter character. It is usually a pipe (‘|’), or a comma (‘,’) for numeric properties, e.g.
Duplicate code can be hard to find, especially in a large project.
+But PMD’s Copy/Paste Detector (CPD) can find it for you!
+
+
CPD works with Java, JSP, C/C++, C#, Go, Kotlin, Ruby, Swift and many more languages.
+It can be used via command-line, or via an Ant task.
+It can also be run with Maven by using the cpd-check goal on the Maven PMD Plugin.
+
+
Your own language is missing?
+See how to add it here.
+
+
Why should you care about duplicates?
+
+
It’s certainly important to know where to get CPD, and how to call it, but it’s worth stepping back for a moment and asking yourself why you should care about this, being the occurrence of duplicate code blocks.
+
+
Assuming duplicated blocks of code are supposed to do the same thing, any refactoring, even simple, must be duplicated too – which is unrewarding grunt work, and puts pressure on the developer to find every place in which to perform the refactoring. Automated tools like CPD can help with that to some extent.
+
+
However, failure to keep the code in sync may mean automated tools will no longer recognise these blocks as duplicates. This means the task of finding duplicates to keep them in sync when doing subsequent refactorings can no longer be entrusted to an automated tool – adding more burden on the maintainer. Segments of code initially supposed to do the same thing may grow apart undetected upon further refactoring.
+
+
Now, if the code may never change in the future, then this is not a problem.
+
+
Otherwise, the most viable solution is to not duplicate. If the duplicates are already there, then they should be refactored out. We thus advise developers to use CPD to help remove duplicates, not to help keep duplicates in sync.
+
+
Refactoring duplicates
+
+
Once you have located some duplicates, several refactoring strategies may apply depending of the scope and extent of the duplication. Here’s a quick summary:
+
+
+
If the duplication is local to a method or single class:
+
+
Extract a local variable if the duplicated logic is not prohibitively long
+
Extract the duplicated logic into a private method
+
+
+
If the duplication occurs in siblings within a class hierarchy:
+
+
Extract a method and pull it up in the class hierarchy, along with common fields
By default CPD exits with status 4 if code duplications are found.
+ Disable this option with --failOnViolation false to exit with 0 instead and just write the report.
Pattern to find the blocks to skip. It is a string property and contains of two parts,
+ separated by |. The first part is the start pattern, the second part is the ending pattern.
In order to change the heap size under Windows, you’ll need to edit the batch file cpd.bat or
+set the environment variable PMD_JAVA_OPTS prior to starting CPD:
+
+
C:\ > cd C:\pmd-bin-6.30.0-SNAPSHOT\bin
+C:\...\bin > set PMD_JAVA_OPTS=-Xmx512m
+C:\...\bin > .\cpd.bat --minimum-tokens 100 --files c:\temp\src
+
+
+
If you specify a source directory but don’t want to scan the sub-directories, you can use the non-recursive option:
Please note that if CPD detects duplicated source code, it will exit with status 4 (since 5.0).
+This behavior has been introduced to ease CPD integration into scripts or hooks, such as SVN hooks.
+
+
+
0
Everything is fine, no code duplications found
+
1
Couldn't understand command line parameters or CPD exited with an exception
+
4
At least one code duplication has been detected unless '--failOnViolation false' is used.
The character set encoding (e.g., UTF-8) to use when reading the source code files, but also when
+ producing the report. A piece of warning, even if you set properly the encoding value,
+ let's say to UTF-8, but you are running CPD encoded with CP1252, you may end up with not UTF-8 file.
+ Indeed, CPD copy piece of source code in its report directly, therefore, the source files
+ keep their encoding.
+ If not specified, CPD uses the system default encoding.
if true, CPD ignores literal value differences when evaluating a duplicate
+ block. This means that foo=42; and foo=43; will be seen as equivalent. You may want
+ to run PMD with this option off to start with and then switch it on to see what it turns up.
Ignore annotations. More and more modern frameworks use annotations on classes and methods,
+ which can be very redundant and trigger CPD matches. With J2EE (CDI, Transaction Handling, etc)
+ and Spring (everything) annotations become very redundant. Often classes or methods have the
+ same 5-6 lines of annotations. This causes false positives.
Configures the pattern, to find the blocks to skip. It is a string property and contains of two parts,
+ separated by |. The first part is the start pattern, the second part is the ending pattern.
The destination file for the report. If not specified the console will be used instead.
+
+
+
+
+
+
+
Also, you can get verbose output from this task by running ant with the -v flag; i.e.:
+
+
ant -v -f mybuildfile.xml cpd
+
+
+
Also, you can get an HTML report from CPD by using the XSLT script in pmd/etc/xslt/cpdhtml.xslt. Just run
+the CPD task as usual and right after it invoke the Ant XSLT script like this:
CPD also comes with a simple GUI. You can start it via some scripts in the bin folder:
+
+
For Windows:
+
+
cpdgui.bat
+
+
+
For Linux:
+
+
./run.sh cpdgui
+
+
+
Here’s a screenshot of CPD after running on the JDK 8 java.lang package:
+
+
+
+
Suppression
+
+
Arbitrary blocks of code can be ignored through comments on Java, C/C++, Dart, Go, Javascript,
+Kotlin, Lua, Matlab, Objective-C, PL/SQL, Python, Swift and C# by including the keywords CPD-OFF and CPD-ON.
Additionally, Java allows to toggle suppression by adding the annotations
+@SuppressWarnings("CPD-START") and @SuppressWarnings("CPD-END")
+all code within will be ignored by CPD.
+
+
This approach however, is limited to the locations were @SuppressWarnings is accepted.
+It’s legacy and the new comment’s based approach should be favored.
+
+
//enable suppression
+ @SuppressWarnings("CPD-START")
+ publicObjectsomeParameterizedFactoryMethod(intx)throwsException{
+ // any code here will be ignored for the duplication detection
+ }
+ //disable suppression
+ @SuppressWarnings("CPD-END)
+ publicvoidnextMethod(){
+ }
+
+
+
Other languages currently have no support to suppress CPD reports. In the future,
+the comment based approach will be extended to those of them that can support it.
+
+
Credits
+
CPD has been through three major incarnations:
+
+
+
+
First we wrote it using a variant of Michael Wise’s Greedy String Tiling algorithm (our variant is described
+here).
CPD collects occurrences of found duplications and provides them to the selected report format.
+Each found code duplication appears in one or more other files, so that each code duplication can
+have multiple locations. Not all report formats display all locations.
+
+
The following examples always describe the same duplications:
+
+
+
a code block of 239 tokens spanning 33 lines in RuleReferenceTest. This is a duplication within the same file.
+
a code block of 110 tokens spanning 16 lines in JaxenXPathRuleQueryTest. This is a duplication that appears
+3 times within the same file.
+
+
+
text
+
+
This is the default format.
+
+
All duplications are reported one after another. For each duplication, the complete code snippet is output.
+Each duplication is separated by ======.
+
+
Example:
+
+
Found a 33 line (239 tokens) duplication in the following files:
+Starting at line 32 of /home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/RuleReferenceTest.java
+Starting at line 68 of /home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/RuleReferenceTest.java
+
+ public void testOverride() {
+ final StringProperty PROPERTY1_DESCRIPTOR = new StringProperty("property1", "Test property", null, 0f);
+ MockRule rule = new MockRule();
+ rule.definePropertyDescriptor(PROPERTY1_DESCRIPTOR);
+ rule.setLanguage(LanguageRegistry.getLanguage(Dummy2LanguageModule.NAME));
+ rule.setName("name1");
+ rule.setProperty(PROPERTY1_DESCRIPTOR, "value1");
+ rule.setMessage("message1");
+ rule.setDescription("description1");
+ rule.addExample("example1");
+ rule.setExternalInfoUrl("externalInfoUrl1");
+ rule.setPriority(RulePriority.HIGH);
+
+ final StringProperty PROPERTY2_DESCRIPTOR = new StringProperty("property2", "Test property", null, 0f);
+ RuleReference ruleReference = new RuleReference();
+ ruleReference.setRule(rule);
+ ruleReference.definePropertyDescriptor(PROPERTY2_DESCRIPTOR);
+ ruleReference.setLanguage(LanguageRegistry.getLanguage(DummyLanguageModule.NAME));
+ ruleReference
+ .setMinimumLanguageVersion(LanguageRegistry.getLanguage(DummyLanguageModule.NAME).getVersion("1.3"));
+ ruleReference
+ .setMaximumLanguageVersion(LanguageRegistry.getLanguage(DummyLanguageModule.NAME).getVersion("1.7"));
+ ruleReference.setDeprecated(true);
+ ruleReference.setName("name2");
+ ruleReference.setProperty(PROPERTY1_DESCRIPTOR, "value2");
+ ruleReference.setProperty(PROPERTY2_DESCRIPTOR, "value3");
+ ruleReference.setMessage("message2");
+ ruleReference.setDescription("description2");
+ ruleReference.addExample("example2");
+ ruleReference.setExternalInfoUrl("externalInfoUrl2");
+ ruleReference.setPriority(RulePriority.MEDIUM_HIGH);
+
+ validateOverriddenValues(PROPERTY1_DESCRIPTOR, PROPERTY2_DESCRIPTOR, ruleReference);
+=====================================================================
+Found a 16 line (110 tokens) duplication in the following files:
+Starting at line 66 of /home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/lang/rule/xpath/JaxenXPathRuleQueryTest.java
+Starting at line 88 of /home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/lang/rule/xpath/JaxenXPathRuleQueryTest.java
+Starting at line 110 of /home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/lang/rule/xpath/JaxenXPathRuleQueryTest.java
+
+ JaxenXPathRuleQuery query = createQuery(xpath);
+ List<String> ruleChainVisits = query.getRuleChainVisits();
+ Assert.assertEquals(2, ruleChainVisits.size());
+ Assert.assertTrue(ruleChainVisits.contains("dummyNode"));
+ // Note: Having AST_ROOT in the rule chain visits is probably a mistake. But it doesn't hurt, it shouldn't
+ // match a real node name.
+ Assert.assertTrue(ruleChainVisits.contains(JaxenXPathRuleQuery.AST_ROOT));
+
+ DummyNodeWithListAndEnum dummy = new DummyNodeWithListAndEnum(1);
+ RuleContext data = new RuleContext();
+ data.setLanguageVersion(LanguageRegistry.findLanguageByTerseName("dummy").getDefaultVersion());
+
+ query.evaluate(dummy, data);
+ // note: the actual xpath queries are only available after evaluating
+ Assert.assertEquals(2, query.nodeNameToXPaths.size());
+ Assert.assertEquals("self::node()[(attribute::Test1 = \"false\")][(attribute::Test2 = \"true\")]", query.nodeNameToXPaths.get("dummyNode").get(0).toString());
+
+
+
xml
+
+
This format uses XML to output the duplications in a more structured format.
+
+
Example:
+
+
<?xml version="1.0" encoding="UTF-8"?>
+<pmd-cpd>
+ <duplicationlines="33"tokens="239">
+ <filecolumn="29"endcolumn="75"endline="64"line="32"
+ path="/home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/RuleReferenceTest.java"/>
+ <filecolumn="37"endcolumn="75"endline="100"line="68"
+ path="/home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/RuleReferenceTest.java"/>
+ <codefragment><![CDATA[ public void testOverride() {
+ final StringProperty PROPERTY1_DESCRIPTOR = new StringProperty("property1", "Test property", null, 0f);
+ MockRule rule = new MockRule();
+ rule.definePropertyDescriptor(PROPERTY1_DESCRIPTOR);
+ rule.setLanguage(LanguageRegistry.getLanguage(Dummy2LanguageModule.NAME));
+ rule.setName("name1");
+ rule.setProperty(PROPERTY1_DESCRIPTOR, "value1");
+ rule.setMessage("message1");
+ rule.setDescription("description1");
+ rule.addExample("example1");
+ rule.setExternalInfoUrl("externalInfoUrl1");
+ rule.setPriority(RulePriority.HIGH);
+
+ final StringProperty PROPERTY2_DESCRIPTOR = new StringProperty("property2", "Test property", null, 0f);
+ RuleReference ruleReference = new RuleReference();
+ ruleReference.setRule(rule);
+ ruleReference.definePropertyDescriptor(PROPERTY2_DESCRIPTOR);
+ ruleReference.setLanguage(LanguageRegistry.getLanguage(DummyLanguageModule.NAME));
+ ruleReference
+ .setMinimumLanguageVersion(LanguageRegistry.getLanguage(DummyLanguageModule.NAME).getVersion("1.3"));
+ ruleReference
+ .setMaximumLanguageVersion(LanguageRegistry.getLanguage(DummyLanguageModule.NAME).getVersion("1.7"));
+ ruleReference.setDeprecated(true);
+ ruleReference.setName("name2");
+ ruleReference.setProperty(PROPERTY1_DESCRIPTOR, "value2");
+ ruleReference.setProperty(PROPERTY2_DESCRIPTOR, "value3");
+ ruleReference.setMessage("message2");
+ ruleReference.setDescription("description2");
+ ruleReference.addExample("example2");
+ ruleReference.setExternalInfoUrl("externalInfoUrl2");
+ ruleReference.setPriority(RulePriority.MEDIUM_HIGH);
+
+ validateOverriddenValues(PROPERTY1_DESCRIPTOR, PROPERTY2_DESCRIPTOR, ruleReference);]]></codefragment>
+ </duplication>
+ <duplicationlines="16"tokens="110">
+ <filecolumn="9"endcolumn="28"endline="81"line="66"
+ path="/home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/lang/rule/xpath/JaxenXPathRuleQueryTest.java"/>
+ <filecolumn="9"endcolumn="28"endline="103"line="88"
+ path="/home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/lang/rule/xpath/JaxenXPathRuleQueryTest.java"/>
+ <filecolumn="9"endcolumn="28"endline="125"line="110"
+ path="/home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/lang/rule/xpath/JaxenXPathRuleQueryTest.java"/>
+ <codefragment><![CDATA[ JaxenXPathRuleQuery query = createQuery(xpath);
+ List<String> ruleChainVisits = query.getRuleChainVisits();
+ Assert.assertEquals(2, ruleChainVisits.size());
+ Assert.assertTrue(ruleChainVisits.contains("dummyNode"));
+ // Note: Having AST_ROOT in the rule chain visits is probably a mistake. But it doesn't hurt, it shouldn't
+ // match a real node name.
+ Assert.assertTrue(ruleChainVisits.contains(JaxenXPathRuleQuery.AST_ROOT));
+
+ DummyNodeWithListAndEnum dummy = new DummyNodeWithListAndEnum(1);
+ RuleContext data = new RuleContext();
+ data.setLanguageVersion(LanguageRegistry.findLanguageByTerseName("dummy").getDefaultVersion());
+
+ query.evaluate(dummy, data);
+ // note: the actual xpath queries are only available after evaluating
+ Assert.assertEquals(2, query.nodeNameToXPaths.size());
+ Assert.assertEquals("self::node()[(attribute::Test1 = \"false\")][(attribute::Test2 = \"true\")]", query.nodeNameToXPaths.get("dummyNode").get(0).toString());]]></codefragment>
+ </duplication>
+</pmd-cpd>
+
+
+
csv
+
+
This outputs the duplication as comma separated values. It only reports the duplication size (number
+of lines and tokens) and the number of occurrences. After that, the begin lines and filenames are reported on
+after another.
This format is similar to “csv”, but it has one difference: The duplication size in number of lines is reported
+for each occurrence separately. While the tokens are the same, due to formatting or comments, the code blocks might be
+different. Whitespace and comments are usually ignored when finding duplicated code.
+
+
In each line, the duplication size in tokens is reported, then the number of occurrences. And after that, for each
+file, the begin line, the number of duplicated lines and the filename.
This outputs the duplication in a format, that Visual Studio. CPD can be added as a external tool and the output
+is shown in the console. You can then click on the filenames to jump to the source where the duplication is located.
+
+
Each occurrence of a duplication is reported in a separate line, that’s why in this example, we have 5 lines.
+
+
Example:
+
+
/home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/RuleReferenceTest.java(32): Between lines 32 and 65
+/home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/RuleReferenceTest.java(68): Between lines 68 and 101
+/home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/lang/rule/xpath/JaxenXPathRuleQueryTest.java(66): Between lines 66 and 82
+/home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/lang/rule/xpath/JaxenXPathRuleQueryTest.java(88): Between lines 88 and 104
+/home/pmd/source/pmd-core/src/test/java/net/sourceforge/pmd/lang/rule/xpath/JaxenXPathRuleQueryTest.java(110): Between lines 110 and 126
+
Rule properties are a way to make your rules configurable directly from the
+ruleset XML. Their usage is described on the Configuring Rules page.
+
+
If you’re a rule developer, you may want to think about what would be useful for
+a user of your rule to parameterise. It could be a numeric report level, a boolean
+flag changing the behaviour of your rule… Chances are there is some detail
+that can be abstracted away from your implementation, and in that case, this
+page can help you squeeze that sweet flexibility out of your rule.
+
+
Overview of properties
+
+
The basic thing you need to do as a developer is to define a property descriptor and declare that your rule uses it. A property descriptor defines a number of attributes for your property:
+
+
Its name, with which the user will refer to your property;
+
Its description, for documentation purposes;
+
Its default value
+
+
+
Don’t worry, all of these attributes can be specified in a single Java statement (or xml element for XPath rules).
+
+
For Java rules
+
+
The procedure to define a property is quite straightforward:
+
+
Create a property descriptor of the type you want, by using a
+builder from PropertyFactory
Properties can be built using type-specific builders, which can be obtained
+from the factory methods of PropertyFactory. For example, to build a
+string property, you’d call
+
PropertyFactory.stringProperty("myProperty")
+ .desc("This is my property")
+ .defaultValue("foo")
+ .build();
+
+
+
This is fairly more readable than a constructor call, but keep in mind the description and the default value are not optional.
+
+
Note: As of version 6.10.0, all property concrete classes are deprecated for
+removal in 7.0.0. See the detailed list of planned removals for
+information about how to migrate.
+
+
For numeric properties, you can add constraints on the range of acceptable values, e.g.
+
PropertyFactory.intProperty("myIntProperty")
+ .desc("This is my property")
+ .defaultValue(3)
+ .require(positive())
+ .range(0,100)
+ .build();
+
+
+
The positive method is part of
+the NumericConstraints class, which provides some
+other constraints. The constraint mechanism will be completely unlocked with 7.0.0,
+since we’ll be migrating our API to Java 8.
+
+
Enumerated properties are a bit less straightforward to define, though they are
+arguably more powerful. These properties don’t have a specific value type, instead,
+you can choose any type of value, provided the values are from a closed set. To make
+that actionable, you give string labels to each of the acceptable values, and the user
+will provide one of those labels as a value in the XML. The property will give you back
+the associated value, not the label. Here’s an example:
You can see an example of properties used in a PMD rule here.
+There are several things to notice here:
+
+
The property descriptors are declared static final, which should generally be
+the case, as descriptors are immutable and can be shared between instances of the same rule;
+
The property is declared using definePropertyDescriptor` in the constructor,
+which ensures the property gets recognised by PMD at the time the properties
+are overridden (which happens before rule execution);
+
The value of the property is not retrieved in the constructor, but in one of
+the visit methods (typically on the highest node in the tree, since the property
+doesn’t change).
+
+
+
For XPath rules
+
+
XPath rules can also define their own properties. To do so, you must add a property element in the properties element of your rule, which declares the type attribute. This attribute conditions what type the underlying property has, and can have the following values:
+
+
+
+
+
type attribute
+
XSD type
+
+
+
+
+
Integer
+
xs:integer
+
+
+
Long
+
xs:integer
+
+
+
Double
+
xs:decimal
+
+
+
Boolean
+
xs:boolean
+
+
+
String
+
xs:string
+
+
+
Character
+
xs:string
+
+
+
Regex
+
xs:string
+
+
+
+
+
Note: In XPath 1.0 mode, all values are actually represented as
+ string values, which is mostly fine as there is no type
+ checking. This is a problem when migrating from XPath 1.0
+ to 2.0 though
+
+
Note that enumerated properties are not available in XPath rules (yet?).
+
+
Properties defined in XPath also must declare the description attribute.
+Numeric properties also expect the min and max attributes for now. Here are
+a few examples to sum it up:
You can then use the property in XPath with the syntax $propertyName, for example:
+
+
<rulename="MyXpathRule"...>
+ <properties>
+ <propertyname="maxStatements"type="Integer"value="10"min="1"max="40"
+ description="Max number of statements per method"/>
+ <propertyname="xpath">
+ <![CDATA[
+ //MethodDeclaration/Block[count(//BlockStatement) > $maxStatements]
+ ]]></property>
+ </properties>
+</rule>
+
+
+
Multivalued properties
+
+
Multivalued properties are also allowed and their type attribute has the form
+List[Boolean] or List[Character], with every above type allowed. These
+properties require XPath 2.0 to work properly, and make use of the
+sequence datatype provided by that language. You thus need to set the
+version property to 2.0 to use them. Properties can also declare the
+delimiter attribute.
Notice that in the example above, @Image = $reportedIdentifiers doesn’t test
+@Image for equality with the whole sequence ('foo', 'bar'), it tests whether
+the sequence contains@Image. That is, the above rule will report all variables
+named foo or bar. All other XPath 2.0 functions operating on sequences
+are supported.
The app needs JRE 1.8 or above to run. Be aware that on JRE 11+, the JavaFX distribution should be installed separately. Visit the JavaFX download page to download a distribution, extract it, and set the JAVAFX_HOME environment variable.
+
+
If the bin directory of your PMD distribution is on your shell’s path, then you can launch the app with
+
+
run.sh designer on Linux/ OSX
+designer.bat on Windows
+
+
+
Note: pmd-ui.jar is not a runnable jar, because it doesn’t include any PMD language module, or PMD Core.
+
+
This is to allow easy updating, and let you choose the dependencies you’re interested in.
+The available language modules are those on the classpath of the app’s JVM. That’s why it’s recommended to use the standard PMD startup scripts, which setup the classpath with the available PMD libraries.
+
+
Updating
+
+
The latest version of the designer currently works with PMD 6.12.0 and above. You can simply replace pmd-ui-6.X.Y.jar with the latest build in the installation folder of your PMD distribution, and run it normally. Note that updating may cause some persisted state to get lost, for example the code snippet.
+
+
Usage reference
+
+
The rule designer is both a tool to inspect the tree on which PMD rules run on, and to write XPath rules in an integrated manner. This page describes the features that enable this.
+
+
AST inspection
+
+
+
+
You can enter source code in the middle zone.
+
+
Make sure to select the correct language and version for your source code:
+
+
Language is set app-wide with the blue button in the menu-bar
+
If the language has several language versions, you can select a specific one with the choicebox just above the code area
+
+
+
If the source is valid using this setting, the tree to the right will update to display the AST of the code
+
When selecting a node, the left panel updates with information about a node
+
+
+
Selecting nodes
+
+
There are several ways to focus a node for inspection:
+
+
From the tree view: just click on an item
+
+
Since 6.16.0, the tree view is also searchable: press CTRL+F when it’s focused, or click on the Search button and enter a search query. You can cycle through results with CTRL+TAB or CTRL+F3, and cycle back with CTRL+SHIFT+TAB or CTRL+SHIFT+F3
+
+
+
From the crumb bar: the crumb bar below the code area shows the ancestors of the currently selected node, and is empty if you have no selection:
+
+
+Ancestor crumb bar demo
+
+
+
+
+
+
From the source code: maintain CTRL for a second until the code area becomes mostly blue. Then, each node you hover over on the code area will be selected automatically. Example:
+
+
+CTRL-hover selection demo
+
+
+
+
+
Node inspection
+
+
The left panel displays the following information:
+
+
+
XPath attributes: this basically are all the attributes available in XPath queries. Those attributes are wrappers around a Java getter, so you can obtain documentation on the relevant Javadoc (that’s not yet integrated into the designer)
+
Metrics: for nodes that support it, the values of metrics are displayed in this panel
+
Scopes: This is java specific and displays some representation of the symbol table. You mostly don’t need it. If you select eg a variable id, its usages are already highlighted automatically without opening the panel:
+
+
+
+
+
XPath rule design
+
+
The bottom part of the UI is dedicated to designing XPath rules:
+
+
+
+
The center is an XPath expression. As you type it, the matched nodes are updated on the right, and highlighted on the code area. Autocompletion is available on some languages.
+
+
Note: you can keep several rules in the editor (there’s a tab for each of them).
+
+
Rule properties
+
+
Above the XPath expression area, the “Properties” button allows you to define new properties for your prototype rule. You can also edit the existing properties.
+
+
When you click on it, a small popup appears:
+
+
+
+
The popup contains in the center a list of currently defined properties, displaying their name and expected type.
+
+
+
Adding: the “Add property” button adds a row to the table
+
Deleting: each item has a “Trash” button to delete the property
+
Editing: each property can be further edited by clicking on the “Ellipsis” button on the right
+
+
+
Editing properties
+
+
The edition menu of a property looks like the following:
+
+
+
+
+
You can edit the name, description, expected type, and default value of the property
The default value is used unless you’re editing a test case, and you set a custom value for the test case. TODO link
+
+
+
Exporting to an XML rule
+
+
The little export icon next to the gear icon opens a menu to export your rule. This menu lets you fill-in the metadata necessary for an XPath rule to be included in a ruleset.
+
+Rule export demo
+
+
+
+
+
Testing a rule
+
+
PMD has its own XML format to describe rule tests and execute them using our test framework. The designer includes a test editor, which allows you to edit such files or create a new one directly as you edit the rule. This is what the panel left of the XPath expression area is for.
When executing a test, the rule is run on the source with the given configuration, then the violations it finds are compared to the expected ones.
+
+
Adding tests
+
+
Tests can be added in one of four ways:
+
+
From an XML file: if you already have a test XML file for your tests, you can load all the tests it defines easily.
+
+
+Test import demo
+
+
+
+
+
+
+
From the current source: A new test case with a default configuration is created, with the source that is currently in the editor
+
+
+
With an empty source: A new test case with a default configuration is created, with an empty source file. You must edit the source yourself then.
+
+
+
From an existing test case: Each test case list item has a “Copy” button which duplicates the test and loads the new one.
+
+
+
+
Test status
+
+
In the designer, the test panel is a list of test cases. Their status (passing, failing, error, unknown) is color coded.
+
+Test status color coding examples
+
All tests passing (green):
+
+
+
+
A failing test (orange):
+
+
+
+
+
+
Loading a test case
+
+
Each test has a piece of source, which you can edit independently of the others, when the test is loaded in the editor. Additional rule configuration options can be chosen when the test is loaded.
+
+
Loading is done with the Load button:
+
+Test loading demo
+
+
+
+
+
Only one test case may be loaded at a time. If the loaded test is unloaded, the editor reverts back to the state it had before the first test case was loaded.
+
+
Editing a loaded test case
+
+
When a test is loaded, the source you edit in the code area is the source of the test. Changes are independent from other tests, and from the piece of source that was previously in the editor.
+
+
When a test is loaded, an additional toolbar shows up at the top of the code area:
+
+
+
+
Expected violations
+
+
The “Expected violations” button is used to add or edit the expected violations.
+
+
Initially the list of violations is empty. You can add violations by dragging and dropping nodes onto the button or its popup, from any control that displays nodes. For example:
+
+Adding a violation demo
+
+
+
+
+
Test case rule configuration
+
+
Rule properties can be configured for each test case independently using the “Property mapping” button. For example:
+
+Test rule property demo
+
+
+
+
+
This configuration will be used when executing the test to check its status.
+
+
Exporting tests
+
+
When you’re done editing tests, it’s a good idea to save the test file to an XML file. Exporting is done using the “Export” button above the list of test cases:
+
+Test export demo
+
+
+
+
+
Note that the exported file does not contain any information about the rule. The rule must be in a ruleset file somewhere else.
+
+
If you want to use PMD’s test framework to use the test file in your build, please refer to the conventions explained in the test framework documentation.
Since version 6.0.0, PMD is enhanced with the ability to compute code metrics on Java and Apex source (the so-called Metrics Framework). This framework provides developers with a straightforward interface to use code metrics in their rules, and to extend the framework with their own custom metrics.
Note: The following explains how to use the Java metrics framework. The Apex framework
+differs only by the name of its classes.
+
+
In PMD’s Metrics framework, a metric is an operation that can be carried out on nodes of a certain type and produces
+a numeric result. In the Java framework, metrics can be computed on operation declaration nodes (constructor and
+method declaration), and type declaration nodes (class, interface, enum, and annotation declarations). A metric
+object in the framework can only handle either types or operations, but not both.
+
+
PMD ships with a library of already implemented metrics. These metrics are referenced by MetricKey objects,
+which are listed in two public enums: JavaClassMetricKey and JavaOperationMetricKey.
+Metric keys wrap a metric, and know which type of node their metric can be computed on. That way, you cannot compute an operation metric on a class
+declaration node. Metrics that can be computed on both operation and type declarations (e.g. NCSS) have one metric key in
+each enum.
+
+
For XPath rules
+
+
XPath rules can compute metrics using the metric function. This function takes a single string argument,
+which is the name of the metric key as defined in JavaClassMetricKey or JavaOperationMetricKey. The metric
+ will be computed on the context node.
+
+
The function will throw an exception in the following cases:
//MethodDeclaration[metric('CYCLO') > 10 and metric('NCSS') > 20]
+
//ClassOrInterfaceDeclaration[metric('CYCLO') > 50]: IllegalArgumentException!
+CYCLO’s only defined for methods and constructors.
+
+
+
For Java Rules
+
+
The static façade class JavaMetrics is the single entry point to compute metrics in the Java framework.
+
+
This class provides the method get and its overloads. The following sections describes the interface of this class.
+
+
Basic usage
+
+
The simplest overloads of JavaMetrics.get take two parameters: a MetricKey and a node of the corresponding type.
+Say you want to write a rule to report methods that have a high cyclomatic complexity. In your rule’s visitor, you
+can get the value of Cyclo for a method node like so:
The same goes for class metrics: you select one among JavaClassMetricKey’s constants and pass it along with the node
+to JavaMetrics.get.
+
+
Tip: A specific base rule class (AbstractJavaMetricsRule) exists
+ to e.g. check constructors and method nodes completely alike. This comes
+ in handy for metrics, as they usually don’t make the distinction
+
+
Capability checking
+
+
Metrics are not necessarily computable on any node of the type they handle. For example, Cyclo cannot be computed on
+abstract methods. Metric keys provides a supports(Node) boolean method
+to find out if the metric can be computed on
+the specified node. If the metric cannot be computed on the given node, JavaMetrics.get will return Double.NaN .
+If you’re concerned about that, you can condition your call on whether the node is supported or not:
Some metrics define options that can be used to slightly modify the computation. You’ll typically see these options
+gathered inside an enum in the implementation class of the metric, for example CycloMetric.CycloOption. They’re
+also documented on the index of metrics.
+
+
To use options with a metric, you must first bundle them into a MetricOptions object. MetricOptions provides the
+utility method ofOptions to get a MetricOptions bundle from a collection or with varargs parameters. You can then
+pass this bundle as a parameter to JavaMetrics.get:
The version of MetricOptions.ofOptions using a collection is useful when you’re building a MetricOptions from eg
+the value of an EnumeratedMultiProperty, which gives users control of the options they use. See
+CyclomaticComplexityRule
+for an example usage.
+
+
Result options
+
+
The Metrics API also gives you the possibility to aggregate the result of an operation metric on all operations of a
+class very simply. You can for example get the highest value of the metric over a class that way:
Notice that we use an operation metric and a class node. The ResultOption parameter controls what result will be
+computed: you can choose among HIGHEST, SUM and AVERAGE. You can use metric options together with a result
+option too.
+
+
Complete use case
+
+
The following is a sample code for a rule reporting methods with a cyclomatic
+complexity over 10 and classes with a total cyclo over 50. A metric option can be
+user-configured with a rule property. More complete examples can be found in
+CyclomaticComplexityRule,
+NcssCountRule,
+or GodClassRule.
You can use the framework to customize the existing metrics at will, or define
+new ones quite easily. Here’s some info to get you started. Again, the examples are for
+the Java framework but it’s symmetrical in the Apex framework.
+
+
The really short guide
+
+
+
Determine whether your metric is an operation metric or a class metric and
+extend the correct base class (AbstractJavaClassMetric or
+AbstractJavaOperationMetric)
+
You’re immediately prompted by your IDE to implement the computeFor method.
+This method takes a node of the type you want to handle, a bundle of options,
+and returns the result of the metric.
+
Optionally specify a predicate to check if a node can be handled by overriding
+the supports method.
+
Optionally define options (implementing MetricOption)
+and handle them as you see fit in your computeFor method
+
Create a metric key using MetricKeyUtil’s of method, specifying a name
+for your metric and an instance of your metric. You’re done and can use your
+metric key as if it were a standard one.
+
+
+
Best practices
+
+
+
Metrics should be stateless. In any case, instances of the same metric class
+are considered equals. The same instance of your metric will be used to
+compute the metric on the AST of different nodes so it should really be
+“functionnally pure”. That rule also makes you keep it simple and understandable
+which is nice.
+
Implementation patterns: You can implement your computeFor method as you
+like it. But most metrics in our library are implemented following a few
+patterns you may want to look at:
+
+
+
Visitor metrics: Those metrics use one or more AST visitor to compute their
+value. That’s especially good to implement metrics that count some kind of node,
+e.g. NPath complexity
+or NCSS.
+Additionally, it makes your metric more easily generalisable to other node types.
+
+
+
Signature matching metrics: That’s even more straightforward when you want
+to count the number of methods or fields that match a specific signature, e.g.
+public static final fields. Basically a signature is an object that describes
+a field or method, with info about its modifers and other node-specific info.
+ AbstractJavaClassMetric has a few methods that allow you to count signatures
+ directly, see e.g. the metrics NOPA
+ and WOC.
+
+
+
+
+
+
Capability checking
+
+
You may have noticed that when you extend e.g. AbstractJavaClassMetric, the
+computeFor method you’re prompted to implement takes a node of type
+ASTAnyTypeDeclaration as a parameter. That’s not a concrete node type, but
+an interface, implemented by several concrete node types. Basically that’s done
+so that class metrics are given the ability to be computed on any type
+declaration, and operation metrics on constructors and methods. Here are the
+concrete node types you can target with class and operation metrics, by language:
*Apex method metrics are also applied to triggers by default (see #771). Finer capability checking is not available out of the box for now.
+
+
What if you don’t want such a generalisation? The supports method lets you
+define a predicate to check that the node is supported by your metric. For example,
+if your metric can only be computed on classes, you may override the default behaviour
+like so:
Tip: You can be sure that if your supports method returns false on a node, then
+ that node will never be passed as a parameter to computeFor. That allows you
+ to write your computeFor method without worrying about unsupported nodes.
+
+
The supports method already has a default implementation in the abstract base
+classes. Here’s the default behaviour by language and type of metric:
+
+
+
+
+
Language
+
Java
+
Apex
+
+
+
+
+
Operation metrics
+
supports constructors and non abstract methods
+
supports any non abstract method (including triggers), except <init>, <clinit>, and clone
Here is a bunch of thing to do you may consider once your rule is “up and running”.
+
+
How to define rules priority
+
+
Rule priority may, of course, changes a lot depending on the context of the project. However, you can use the following guidelines to assert the legitimate priority of your rule:
+
+
+
Change absolutely required. Behavior is critically broken/buggy.
+
Change highly recommended. Behavior is quite likely to be broken/buggy.
+
Change recommended. Behavior is confusing, perhaps buggy, and/or against standards/best practices.
+
Change optional. Behavior is not likely to be buggy, but more just flies in the face of standards/style/good taste.
+
Change highly optional. Nice to have, such as a consistent naming policy for package/class/fields…
+
+
+
For instance, let’s take the ExplicitCallToGC rule (“Do not explicitly trigger a garbage collection.”). Calling GC is a bad idea, but it doesn’t break the application. So we skip priority one. However, as explicit call to gc may really hinder application performances, we set for the priority 2.
+
+
Correctness
+
+
You should try to run the rule on a large code base, like the jdk source code for instance. This will help ensure that the rule does not raise exceptions when dealing with unusual constructs.
+
+
If your rule is stateful, make sure that it is reinitialized correctly. The “-stress” command line option can be used as the files will then not be ordered but processed randomly. Running pmd with the “-stress” option several times and sorting the text output should produce identical results if the state information is correctly reset.
+
+
Performance issues
+
+
When writing a new rule, using command line option “-benchmark” on a few rules can give an indication on how the rule compares to others. To get the full picture, use the rulesets/internal/all-java.xml ruleset with “-benchmark”.
+
+
Rules which use the RuleChain to visit the AST are faster than rules which perform manual visitation of the AST. The difference is small for an individual Java rule, but when running 100s of rules, it is measurable. For XPath rules, the difference is extremely noticeable due to Jaxen overhead for AST navigation. Make sure your XPath rules using the RuleChain.
+
+
(TODO How does one know except by running in a debugger or horrendous performance?).
Good rules have tests. At least a positive test case - a code example, that triggers the rule and reports
+a violation - and a negative test case - a code example, that doesn’t trigger the rule - should be created.
+Of course, the more tests, the better the rule is verified. If the rule is more complex or defines properties,
+with which the behavior can be modified, then these different cases can also be tested.
+
+
And if there is a bug fix for a rule, be it a false positive or a false negative case, it should be accompanied
+with an additional test case, so that the bug is not accidentally reintroduced later on.
+
+
How it works
+
+
PMD’s built-in rules are organized in rulesets, where all rules belonging to the same category are placed
+in a single ruleset, such as “category/java/bestpractices.xml”.
+Each category-ruleset has a single abstract base test class, from which the individual test classes inherit.
+We have one test class per rule, which executes all test cases for a single rule. The actual test cases are
+stored in separate XML files, for each rule a separate file is used.
+
+
All the test classes inherit from net.sourceforge.pmd.testframework.PmdRuleTst,
+which provides the seamless integration with JUnit. This base class determines the language, the category name
+and the rule name from the concrete test class. It then searches the test code on its own.
+E.g. the individual rule test class
+net.sourceforge.pmd.lang.java.rule.bestpractices.AbstractClassWithoutAbstractMethodTest tests the
+rule with the name “AbstractClassWithoutAbstractMethod”, which is in the category “bestpractices” for the
+language “java”.
+
+
The test code (see below Test XML Reference) describes the test case completely with
+the expected behavior like number of expected rule violations, where the violations are expected, and so on.
+
+
When you are running the test class in your IDE (e.g. Eclipse or IntelliJ IDEA) you can also select a single
+test case and just execute this one.
+
+
Where to place the test code
+
+
The PmdRuleTst class searches the XML file, that describes the test cases for a certain rule
+using the following convention:
+The XML file is a test resource, so it is searched in the tree under src/test/resources.
+
+
The sub package xml of the test class’s package should contain a file with the same name as the rule’s name
+which is under test.
+
+
For example, to test the rule “AbstractClassWithoutAbstractMethod”, the fully qualified test class is:
Tip: This convention allows you to quickly find the test cases for a given rule:
+Just search in the project for a file <RuleName>.xml. Search for a class <Rule Name>Test to find the
+unit test class for the given rule.
Each test case is in an own <test-code> element. The first defines 0 expected problems, means this code doesn’t
+trigger the rule. The second test case expects 1 problem. Since the rule violations also report the exact AST node,
+you can verify the line number, too.
+
+
Test XML Reference
+
+
The root element is <test-data>. It can contain one or more <test-code> and <code-fragment> elements.
+Each <test-code> element defines a single test case. <code-fragment> elements are used to share code snippets
+between different test cases.
The <test-code> elements understands three optional attributes:
+
+
+
+
reinitializeRule: By default, it’s true, so each test case starts with a fresh instantiated rule. Set it
+to false to reproduce cases, where the previous run has influences.
+
+
+
regressionTest: By default, it’s true. Set it to false, to ignore and skip a test case.
+
+
+
useAuxClasspath: By default, it’s true. Set it to false to reproduce issues which only
+appear without type resolution.
+
+
+
+
<test-code> children
+
+
+
+
<description>: Short description of the test case. This will be the JUnit test name in the report.
+If applicable, this description should contain a reference to the bug number, this test case reproduces.
+
+
+
<rule-property>: Optional rule properties, if the rule is configurable. Just add multiple elements, to
+set multiple properties for one test case. For an example, see below.
+
+
+
<expected-problems>: The the raw number of expected rule violations, that this rule is expected to report.
+For false-positive test cases, this is always “0”. For false-negative test cases, it can be any positive number.
+
+
+
<expected-linenumbers>: Optional element. It’s a comma separated list of line numbers.
+If there are rule violations reported, then this allows you to
+assert the line numbers. Useful if multiple violations should be detected and to be sure that
+false positives and negatives don’t erase each other.
+
+
+
<expected-messages>: Optional element, with <message> elements as children.
+Can be used to validate the correct error message, e.g. if the error message references a variable name.
+
+
+
<code>: Either the <code> element or the <code-ref> element is required. It provides the actual code
+snippet on which the rule is executed. The code itself is usually wrapped in a “CDATA” section, so that no
+further XML escapes (entity references such as <) are necessary.
+
+
+
<code-ref id=...>: Alternative to <code>. References a <code-fragment> defined earlier in the file.
+This allows you to share the same code snippet with several test cases. The attribute id must match the
+id of the references code fragment.
+
+
+
<source-type>: Optional element that specifies a specific language version. This can be used
+to select a specific parser version for parsing the code snippet. If not given, the default version of
+the rule’s language is used. This element can almost always be omitted.
+
+
+
+
<code-fragment>
+
+
The code fragment has just one required attribute: id. This is used to reference it via a <code-ref> element
+inside a <test-code>. Similar like the <code> element, the content of <code-fragment> is usually wrapped
+in a “CDATA” section, so that no further XML escapes (entity references such as <) are necessary.
+
+
Complete XML example
+
+
<?xml version="1.0" encoding="UTF-8"?>
+<test-data
+ xmlns="http://pmd.sourceforge.net/rule-tests"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://pmd.sourceforge.net/rule-tests https://pmd.sourceforge.io/rule-tests_1_0_0.xsd">
+
+ <test-codereinitializeRule="true"regressionTest="true"useAuxClasspath="true">
+ <description>Just a description, will be used as the test name for JUnit in the reports</description>
+ <rule-propertyname="somePropName">propValue</rule-property><!-- optional -->
+ <expected-problems>2</expected-problems>
+ <expected-linenumbers>5,14</expected-linenumbers><!-- optional -->
+ <expected-messages><!-- optional -->
+ <message>Violation message 1</message>
+ <message>Violation message 2</message>
+ </expected-messages>
+ <code><![CDATA[
+public class ConsistentReturn {
+ public Boolean foo() {
+ }
+}
+ ]]></code>
+ <source-type>java 1.5</source-type><!-- optional -->
+ </test-code>
+
+ <code-fragmentid="codeSnippet1"><![CDATA[
+public class ConsistentReturn {
+ public Boolean foo() {
+ }
+}
+ ]]></code-fragment>
+
+ <test-code>
+ <description>test case using a code fragment</description>
+ <expected-problems>0</expected-problems>
+ <code-refid="codeSnippet1"/>
+ </test-code>
+</test-data>
+
+
+
Note: For better readability, the indentation should be 4 for spaces and no tabs.
+Each test-code should be separated by a blank line. CDATA
+sections are only required for the code snippets which should be formatted with indentation for
+better readability. The description can be written directly without a CDATA section.
+
+
Using the test framework externally
+
+
It is also possible to use the test framework for custom rules developed outside the PMD source base.
+Therefore you just need to reference the dependency net.sourceforge.pmd:pmd-test.
Then proceed as described earlier: create your test class, create your test cases and run the unit test.
+
+
There is one difference however: Since your package structure is probably different, you’ll need to register
+the rule test manually, as SimpleAggregatorTst will fail to determine it correctly from the package and class names:
This will then search for a rule named “CustomRule” in the ruleset, that is located in “src/main/resources” under
+the path “com/example/pmd/ruleset.xml”.
+
+
The test data should be placed in an xml file located in “src/test/resources” under the path
+“com/example/pmd/rules/xml/CustomRule.xml”.
+
+
How the test framework is implemented
+
+
The framework uses a custom JUnit test runner under the hood, among a couple of utility classes:
+
+
+
+
PmdRuleTst: This is the base class for tests in PMD’s code base. It is a subclass of RuleTst and just
+contains the logic to determine the test resources based on the test class name.
+
+
+
SimpleAggregatorTst: This is a more generic base class for the test classes and defines
+the custom JUnit test runner. It doesn’t register any test cases on its own.
+It itself is a subclass of RuleTst.
+
+
+
RuleTst: contains the logic to parse the XML files and provide a list of TestDescriptors. Each test descriptor
+describes a single test case. It also contains the logic to execute such a test descriptor and assert the results.
+
+
+
PMDTestRunner: A custom JUnit test runner, that combines two separate test runners: The custom RuleTestRunner
+and the standard JUnit4 test runner. This combination allows you to add additional standard unit test methods
+annotated with @Test to your test class.
+
+
Note: Since the test class is executed through two test runners, it is actually instantiated twice. Be aware
+of this, if you do any initialization in the constructor. Also, the static hooks @BeforeClass and @AfterClass
+will be executed twice.
+
+
+
RuleTestRunner: This test runner executes the test descriptors with the help of RuleTst.
Note: TODO All that should be written in the Javadocs,
+not sure we even need a doc page. Would be simpler to maintain too
+
+
Warning: WIP lots of stuff missing
+
+
This page covers the specifics of writing a rule in Java. The basic development
+process is very similar to the process for XPath rules, which is described in
+Your First Rule.
+
+
Basically, you open the designer, look at the structure of the AST, and refine
+your rule as you add test cases.
+
+
In this page we’ll talk about rules for the Java language, but the process is
+very similar for other languages.
+
+
Basics
+
+
To write a rule in Java you’ll have to:
+
+
write a Java class that implements the interface Rule. Each
+language implementation provides a base rule class to ease your pain,
+e.g. AbstractJavaRule.
+
compile this class, linking it to PMD APIs (eg using PMD as a maven dependency)
+
bundle this into a JAR and add it to the execution classpath of PMD
+
declare the rule in your ruleset XML
+
+
+
Rule execution
+
+
Most base rule classes use a Visitor pattern
+to explore the AST.
+
+
Tree traversal
+
+
When a rule is applied to a file, it’s handed the root of the AST and told
+to traverse all the tree to look for violations. Each rule defines a specific
+visit method for each type of node for of the language, which
+by default just visits the children.
+
+
So the following rule would traverse the whole tree and do nothing:
+
+
publicclassMyRuleextendsAbstractJavaRule{
+ // all methods are default implementations!
+}
+
+
+
Generally, a rule wants to check for only some node types. In our XPath example
+in Your First Rule,
+we wanted to check for some VariableDeclaratorId nodes. That’s the XPath name,
+but in Java, you’ll get access to the ASTVariableDeclaratorId
+full API.
+
+
If you want to check for some specific node types, you can override the
+corresponding visit method:
+
+
publicclassMyRuleextendsAbstractJavaRule{
+
+ @Override
+ publicObjectvisit(ASTVariableDeclaratorIdnode,Objectdata){
+ // This method is called on each node of type ASTVariableDeclaratorId
+ // in the AST
+
+ if(node.getType()==short.class){
+ // reports a violation at the position of the node
+ // the "data" parameter is a context object handed to by your rule
+ // the message for the violation is the message defined in the rule declaration XML element
+ addViolation(data,node);
+ }
+
+ // this calls back to the default implementation, which recurses further down the subtree
+ returnsuper.visit(node,data);
+ }
+}
+
+
+
The super.visit(node, data) call is super common in rule implementations,
+because it makes the traversal continue by visiting all the descendants of the
+current node.
+
+
Stopping the traversal
+
+
Sometimes you have checked all you needed and you’re sure that the descendants
+of a node may not contain violations. In that case, you can avoid calling the
+super implementation and the traversal will not continue further down. This
+means that your callbacks (visit implementations) won’t be called on the rest
+of the subtree. The siblings of the current node may be visited
+recursively nevertheless.
+
+
Economic traversal: the rulechain
+
+
If you don’t care about the order in which the nodes are traversed (e.g. your
+rule doesn’t maintain any state between visits), then you can monumentally
+speed-up your rule by using the rulechain.
+
+
That mechanism doesn’t recurse on all the tree, instead, your rule will only be
+passed the nodes it is interested in. To use the rulechain correctly:
+
+
Your rule must register those node types by calling addRuleChainVisit
+in its constructor.
+
Your visit methods must not recurse! In effect, you should call never
+call super.visit in the methods.
+
+
+
Execution across files, thread-safety and statefulness
+
+
When starting execution, PMD will instantiate a new instance of your rule.
+If PMD is executed in multiple threads, then each thread is using its own
+instance of the rule. This means, that the rule implementation does not need to care about
+threading issues, as PMD makes sure, that a single instance is not used concurrently
+by multiple threads.
+
+
However, for performance reasons, the rule instances are used for multiple files.
+This means, that the constructor of the rule is only executed once (per thread)
+and the rule instance is reused. If you rely on a proper initialization of instance
+properties, you can do the initialization e.g. in the visit-method of the ASTCompilationUnit
+node - which is visited first and only once per file. However, this
+solution would only work for rules written for the Java language. A language
+independent way is to override the method start of the rule.
+The start method is called exactly once per file.
+
+
+
+
Rule lifecycle reference
+
+
Construction
+
+
Exactly once:
+
+
+
The rule’s no-arg constructor is called when loading the ruleset.
+The rule’s constructor must define:
+
If the rule was included in the ruleset as a rule reference,
+some properties may be overridden.
+If an overridden property is unknown, an error is reported.
+
Misconfigured rules are removed from the ruleset
+
+
+
Execution
+
+
For each thread, a deep copy of the rule is created. Each thread is given
+a different set of files to analyse. Then, for each such file, for each
+rule copy:
apply is called with the root
+of the AST. That method performs the AST traversal that ultimately calls visit methods.
+It’s not called for RuleChain rules.
+
end is called when the rule is done processing
+the file
PMD is a framework to perform code analysis. You can create your own rules to
+check for patterns specific to your codebase, or the coding practices of your
+team.
+
+
How rules work: the AST
+
+
Before running rules, PMD parses the source file into a data structure called an
+abstract syntax tree (AST). This tree represents the syntactic structure of the
+code, and encodes syntactic relations between source code elements. For instance,
+in Java, method declarations belong to a class: in the AST, the nodes representing
+method declarations will be descendants of a node representing the declaration of
+their enclosing class. This representation is thus much richer than the original
+source code (which, for a program, is just a chain of characters), or the token
+chain produced by a lexer (which is e.g. what Checkstyle works on). For example:
Conceptually, PMD rules work by matching a “pattern” against the AST of a
+file.
+Rules explore the AST and find nodes that satisfy some conditions that are characteristic
+of the specific thing the rule is trying to flag. Rules then report a violation on these nodes.
+
+
Discovering the AST
+
+
ASTs are represented by Java classes deriving from Node.
+Each PMD language has its own set of such classes, and its own rules about how
+these classes relate to one another, based on the grammar of the language. For
+example, all Java AST nodes extend JavaNode.
+
+
The structure of the AST can be discovered through
PMD supports two ways to define rules: using an XPath query, or using a
+Java visitor. XPath rules are much easier to set up, since they’re defined
+directly in your ruleset XML, and are expressive enough for nearly any task.
+
+
On the other hand, some parts of PMD’s API are only accessible from Java, e.g.
+accessing the usages of a declaration. And Java rules allow you to do some
+complicated processing, to which an XPath rule couldn’t scale.
+
+
In the end, choosing one strategy or the other depends on the difficulty of what
+your rule does. I’d advise to keep to XPath unless you have no other choice.
+
+
XML rule definition
+
+
New rules must be declared in a ruleset before they’re referenced. This is the
+case for both XPath and Java rules. To do this, the rule element is used, but
+instead of mentioning the ref attribute, it mentions the class attribute,
+with the implementation class of your rule.
+
+
+
For Java rules: this is the class extending AbstractRule (transitively)
+
For XPath rules: this is net.sourceforge.pmd.lang.rule.XPathRule
Note: In PMD 7, the language attribute will be required on all rule
+ elements that declare a new rule. Some base rule classes set the language implicitly in their
+ constructor, and so this is not required in all cases for the rule to work. But this
+ behavior will be discontinued in PMD 7, so missing language attributes are
+ reported beginning with PMD 6.27.0 as a forward compatibility warning.
+
+
Resource index
+
+
To learn how to write a rule:
+
+
+
Your First Rule
+introduces the basic development process of a rule with a running example
+
Writing XPath Rules
+explains a bit more about XPath rules and our XPath API
PMD supports three XPath versions for now: 1.0, 2.0, and 1.0 compatibility mode.
+The version can be specified with the version property in the rule definition, like so:
+
+
<propertyversion="2.0"/><!-- or "1.0", or "1.0 compatibility" -->
+
+
+
The default has always been version 1.0.
+
+
As of PMD version 6.22.0, XPath versions 1.0 and the 1.0 compatibility mode are
+deprecated. XPath 2.0 is superior in many ways, for example for its support for
+type checking, sequence values, or quantified expressions. For a detailed
+but approachable review of the features of XPath 2.0 and above, see the Saxon documentation.
+
+
It is recommended that you migrate to 2.0 before 7.0.0, but we expect
+to be able to provide an automatic migration tool when releasing 7.0.0.
+See the migration guide below.
+
+
DOM representation of ASTs
+
+
XPath rules view the AST as an XML-like DOM, which is what the XPath language is
+defined on. Concretely, this means:
+
+
Every AST node is viewed as an XML element
+
+
The element has for local name the value of getXPathNodeName
+for the given node
+
+
+
Some Java getters are exposed as XML attributes on those elements
+
+
This means, that documentation for attributes can be found in our Javadocs. For
+example, the attribute @SimpleName of the Java node EnumDeclaration is backed
+by the Java getter getSimpleName.
+
+
+
+
+
Value conversion
+
+
To represent attributes, we must map Java values to XPath Data Model (XDM) values. The conversion
+depends on the XPath version used.
+
+
XPath 1.0
+
+
On XPath 1.0 we map every Java value to an xs:string value by using the toString
+of the object. Since XPath 1.0 allows many implicit conversions this works, but it
+causes some incompatibilities with XPath 2.0 (see the section about migration further
+ down).
+
+
XPath 2.0
+
+
XPath 2.0 is a strongly typed language, and so we use more precise type annotations.
+In the following table we refer to the type conversion function as conv, a
+function from Java types to XDM types.
+
+
+
+
+
Java type T
+
XSD type conv(T)
+
+
+
+
+
int
+
xs:integer
+
+
+
long
+
xs:integer
+
+
+
double
+
xs:decimal
+
+
+
float
+
xs:decimal
+
+
+
boolean
+
xs:boolean
+
+
+
String
+
xs:string
+
+
+
Character
+
xs:string
+
+
+
Enum<E>
+
xs:string (uses Object::toString)
+
+
+
List<E>
+
conv(E)* (a sequence type) ⚠️ List support is deprecated with 6.25.0. See below.
+
+
+
+
+
The same conv function is used to translate rule property values to XDM values.
+
+
Warning: Support for attributes of type List<E> has been deprecated
+with PMD 6.25.0 and will be removed completely with PMD 7. The reason is that newer Saxon
+versions don’t support sequences as attributes anymore. Lists are still possible in Java-based
+rules but not with XPath.
+
+Multivalued rule properties
+are still supported.
+
+
Migrating from 1.0 to 2.0
+
+
XPath 1.0 and 2.0 have some incompatibilities. The XPath 2.0 specification
+describes them precisely. Those are however mostly corner cases and XPath
+rules usually don’t feature any of them.
+
+
The incompatibilities that are most relevant to migrating your rules are not
+caused by the specification, but by the different engines we use to run
+XPath 1.0 and 2.0 queries. Here’s a list of known incompatibilities:
+
+
+
The namespace prefixes fn: and string: should not be mentioned explicitly.
+In XPath 2.0 mode, the engine will complain about an undeclared namespace, but
+the functions are in the default namespace. Removing the namespace prefixes fixes it.
+
+
fn:substring("Foo", 1) → substring("Foo", 1)
+
+
+
Conversely, calls to custom PMD functions like typeIsmust be prefixed
+with the namespace of the declaring module (pmd-java).
+
+
typeIs("Foo") → pmd-java:typeIs("Foo")
+
+
+
Boolean attribute values on our 1.0 engine are represented as the string values
+"true" and "false". In 2.0 mode though, boolean values are truly represented
+as boolean values, which in XPath may only be obtained through the functions
+true() and false().
+If your XPath 1.0 rule tests an attribute like @Private="true", then it just
+needs to be changed to @Private=true() when migrating. A type error will warn
+you that you must update the comparison. More is explained on issue #1244.
+
+
"true", 'true' → true()
+
"false", 'false' → false()
+
+
+
In XPath 1.0, comparing a number to a string coerces the string to a number.
+In XPath 2.0, a type error occurs. Like for boolean values, numeric values are
+represented by our 1.0 implementation as strings, meaning that @BeginLine > "1"
+worked —that’s not the case in 2.0 mode.
+
+
@ArgumentCount > '1' → @ArgumentCount > 1
+
+
+
In XPath 1.0, the expression /Foo matches the children of the root named Foo.
+In XPath 2.0, that expression matches the root, if it is named Foo. Consider the following tree:
+
Foo
+└─Foo
+└─Foo
+
+
Then /Foo will match the root in XPath 2, and the other nodes (but not the root) in XPath 1.
+See eg an issue caused by this in Apex,
+with nested classes.
PMD provides some language-specific XPath functions to access semantic
+information from the AST.
+
+
On XPath 2.0, the namespace of custom PMD function must be explicitly mentioned.
+
+
+
+
Java
+
+
Java functions are in the namespace pmd-java.
+
+
+
+
+
+
+
Function name
+
Description (click for details)
+
+
+
+
+
+
+
+
+
+
+
+
typeIs
+
Tests a node's static type
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ pmd-java:typeIs(xs:string) as xs:boolean
+
+
+
+
+
+
Returns true if the context node's static Java type is a subtype of the given type. This tests for the resolved type of the Java construct, not the type of the AST node. For example, the AST node for a literal (e.g. 5d) has type ASTLiteral, however this function will compare the type of the literal (eg here, double) against the argument.
Matches variable declarators of type List or any of its subtypes (including e.g. ArrayList)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
typeIsExactly
+
Tests a node's static type, ignoring subtypes
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ pmd-java:typeIsExactly(xs:string) as xs:boolean
+
+
+
+
+
+
Returns true if the context node's static type is exactly the given type. In particular, returns false if the context node's type is a subtype of the given type.
Note: There is also a typeOf function which is
+deprecated and whose usages should be replaced with uses of typeIs or
+typeIsExactly. That one will be removed with PMD 7.0.0.
This page is a gentle introduction to rule writing, and the Rule Designer.
+
+
Using the designer is useful both to write Java
+rules and XPath rules, but it’s more specifically geared towards XPath rules.
+This page uses a simple XPath rule to illustrate the common workflow. We assume
+here that you already know what XPath is and how to read basic XPath queries. W3C
+has a good tutorial here if
+you don’t (in the context of XML only), and the Saxon documentation
+features a comprehensive but approachable description of the syntax of XPath
+expressions.
+
+
The Rule Designer
+
+
The rule designer is a tool that packs a lot of features to help you develop XPath
+rules quickly and painlessly. Basically, it allows you to examine the AST of a code
+snippet and evaluate an XPath expression against it.
+
+
Like for PMD and CPD, you can launch it using run.sh designer on Linux/Unix
+and designer.bat on Windows. The interface looks like the following:
+
+
+
+
The zone (2) is the main editor. When you write a code snippet in the
+ code area to the left, you’ll see that the tree to the right will be updated
+ automatically: it’s the AST of the code.
+ Note that the code snippet must be a syntactically valid compilation unit for the
+ language you’ve chosen, e.g. for Java, a compilation unit necessarily has a top-level
+ type declaration.
+
+
If you select a node in the AST, its specific properties will also be displayed
+in the panel (1): they’re the XPath attributes of the node. More on that later.
+
+
The zone (3) is the XPath editor. If you enter an XPath query in that area,
+it will be evaluated on the current AST and the results will be displayed in the
+list to the bottom right.
+
+
Rule development process
+
+
The basic development process is straightforward:
+
+
+
Write a code snippet in the main editor that features the offending code you’re looking for
+
Examine the AST and determine what node the violation should be reported on
+
Write an XPath expression matching that node in the XPath editor
+
Refine the XPath expression iteratively using different code snippets, so that
+it matches violation cases, but no other node
+
Export your XPath expression to an XML rule element, and place it in your ruleset
+
+
+
Each time you test your rule against a different snippet, it’s a good idea to
+save it to make test cases.
+
+
In the following sections, we walk through several examples to refine your rule.
+
+
A simple rule
+
+
Let’s say you want to prevent your coding team from naming variables of type
+short after your boss, whose name is Bill. You try the designer on the following
+ offending code snippet:
Examining the AST, you find out that the LocalVariableDeclaration has a VariableDeclaratorId
+descendant, whose Image XPath attribute is exactly bill. You thus write your first attempt
+in the XPath editor:
+
//VariableDeclaratorId[@Image="bill"]
+
+
+
You can see the XPath result list is updated with the variable declarator.
+If you try the query against the following updated snippet though, you can
+see that the field declaration id is matched even though it’s not of type short.
You thus refine your XPath expression with an additional predicate,
+based on your examination of the Type node of the field and local variable
+declaration nodes.
You estimate that your rule is now production ready, and you’d like to use it in your ruleset.
+The File > Export XPath to rule... allows you to do that in a few clicks: just enter some
+additional metadata for your rule, and the popup will generate an XML element that you can
+copy-paste into your ruleset XML. The resulting element looks like so:
Ever since PMD 5.6.0, PMD has been able to perform Incremental Analysis.
+
+
When performing Incremental Analysis for the first time, PMD will cache analysis data and results.
+This allows subsequent analysis to only look into those files that are new / have changed. For
+a typical development environment, where you only change a few files at a time, this can reduce
+analysis time dramatically.
+
+
The generated report will be exactly the same as it would if running without incremental analysis.
+Files included in the final report will reflect exactly those files in your filesystem. Even if
+untouched, files with violations will be listed with full detail. Therefore, its usage is highly recommended.
+
+
Enabling incremental analysis
+
+
Incremental analysis is enabled automatically once a location to store the cache has been defined.
+From command-line that is done through the -cache argument, but support for the feature is
+available for tools integrating PMD such as Ant,
+Maven, and Gradle.
+
+
Disabling incremental analysis
+
+
By default, PMD will suggest to use an analysis cache by logging a warning.
+If you’d like to disable this warning, or ignore the analysis cache for a
+few runs, you can use the -no-cache switch.
+
+
FAQ
+
+
When is the cache invalidated?
+
+
On the following reasons, the complete cache file is considered invalid:
+
+
+
The PMD version differs. Since each PMD version might have fixed some false-positives or false-negatives for rules,
+a cache file created with a different version is considered invalid. The version comparison is exact.
+
The used ruleset has been changed. If the ruleset is changed in any way (e.g. adding/removing rules, changing
+rule properties, …), the cache is considered invalid.
+
The auxclasspath changed. The auxclasspath is used during
+type resolution. A changed auxclasspath can result for rules, that use type resolution, in different
+violations. Usually, if the auxclasspath is correct and type resolution works, the rules report less false-positives.
+To make sure, the correct violations are reported, the cache is considered invalid, if the auxclasspath has changed.
+
The execution classpath has been changed. On the execution classpath not only the PMD classes are located, but also
+the implementation of e.g. custom rules. If any jar file/class file on the execution classpath is changed, then
+the cache is considered invalid as well.
+
+
+
What is stored in the cache file?
+
+
The cache file consists of a header and a body. The header stores the information which is used to decided
+whether the whole cache file is valid or not (see above). The following information is stored:
+
+
+
PMD Version
+
Ruleset checksum
+
Auxclasspath checksum
+
Execution classpath checksum
+
+
+
The body contains an entry for every file that has been analyzed. For every file, the following information
+is stored:
+
+
+
The full (absolute) pathname of the file
+
The checksum of the file itself
+
0 or more rule violations with all the info (line number, etc.)
+
+
+
You can think of the cache as a Map where the filepath is used as the key
+and the violations found in previous runs are the value.
+
+
The cache is in the end just a file with serialized data (binary). The implementation is
+FileAnalysisCache.
+
+
How does PMD detect whether a file has been changed?
+
+
When analyzing a file, PMD records the checksum of the file content and stores this
+together with the violations in the cache file. When running PMD with the cache file,
+PMD looks up the file in the cache and compares the checksums.
+If the checksums match, then the file is not even parsed, the rules
+are not executed and the violations for this file are entirely used from the cache.
+If the checksum doesn’t match, then the cached violations are discarded (if there are any)
+and the file is fully processed: the file is parsed and all the rules are run for it.
+After we are done, the cache is updated with the new violations.
+
+
Can I reuse a cache created on branch A for analyzing my project on branch B?
+
+
This is possible. As long as the same PMD version and same ruleset is used on both branches.
+Also note, that if the branch uses a different dependencies, the auxclasspath is different on both
+classes, which invalidates the cache completely. If you project uses e.g. Maven for dependency
+management and your branch uses different dependencies (either different version or completely different
+artifacts), then the auxclasspath is changed.
+
+
If files have been renamed on the branch, these files will be analyzed again since PMD uses
+the file names to assign existing rule violations from the cache. Also, if the full path name
+of the file changes, because the other branch is checked out at a different location, then all
+the cached files don’t match.
+
+
Apart from these restrictions, PMD will only analyze files that changed between runs.
+If your previous run was on branch A and then you run on branch B using the same cache file,
+it will only look at files that are different between the 2 branches.
+
+
Can I reuse a cache file across different machines?
+
+
This is only possible, if the other machine uses the exact same path names. That means that
+your project needs to be checked out into the same directory structure.
+
+
Additionally, all the other restrictions apply (same PMD version, same ruleset, same auxclasspath,
+same execution classpath).
Note: For executing the Designer (./run.sh designer) using OpenJDK or Java 11, you need additionally OpenJFX. Download it, extract it and set the environment variable JAVAFX_HOME.
+
+
Installation
+
+
PMD is distributed as a zip archive, which includes both PMD and CPD.
+You can download the latest binary distribution from the github releases page.
+
+
Unzip it into any directory, optionally add the bin subdirectory in your PATH, and you’re good to go!
+
+
Running PMD via command line
+
+
PMD comes with several command line utilities, like CPD, the rule designer or PMD itself.
+ On Unix, you can run any of them using the script run.sh, located inside the bin/
+ directory of the PMD distribution. The first argument is the name of the utility you want
+ to execute (‘pmd’, ‘designer’, …), e.g. PMD is launched via run.sh pmd. The rest of
+ the arguments are specific to the utility used.
+ On Windows, each utility has its own startup script, e.g. pmd.bat, cpd.bat.
+
+
The PMD command (pmd.bat or run.sh pmd) requires two options:
+
+
+
-d <path>: path to the sources to analyse. This can be a file name, a directory, or a jar or zip file containing the
+sources.
+
-R <path>: the ruleset file you want to use. PMD uses xml configuration files, called rulesets, which specify
+which rules to execute on your sources. You can also run a single rule by referencing it using its category and
+name (more details here). For example, you can check for unnecessary
+modifiers on Java sources with -R category/java/codestyle.xml/UnnecessaryModifier.
+
+
+
Note: At the moment the formerly provided rulesets (eg rulesets/java/basic.xml) are deprecated,
+ though you can still use them. PMD includes a quickstart ruleset for some languages (currently, Java)
+ as base configurations, which you can reference as e.g. rulesets/java/quickstart.xml. You’re strongly
+ encouraged to create your own ruleset from the start though.
+
+
Additionally, the following options, are specified most of the time even though they’re not required:
+
+
-f <format>: report format. PMD supports many report formats out of the box. You may want to start with the basic
+text format (default) or xml format. The supported formats are documented here.
+
-auxclasspath <classpath>: class path containing the compiled class files of the analysed Java sources, if any.
+Setting this up correctly allows PMD to do much deeper analysis using reflection. Some rules, such as MissingOverride,
+require it to function properly.
+
+
+
Tip: A full CLI reference, including report formats, is available under PMD CLI Reference
+
+
Sample usage
+
+
The following shows a sample run of PMD with the text format:
~ $ cd ~/bin/pmd-bin-6.30.0-SNAPSHOT/bin
+~/.../bin $ ./run.sh pmd -d ../../../src/main/java/ -f text -R rulesets/java/quickstart.xml
+
+ .../src/main/java/com/me/RuleSet.java:123 These nested if statements could be combined
+ .../src/main/java/com/me/RuleSet.java:231 Useless parentheses.
+ .../src/main/java/com/me/RuleSet.java:232 Useless parentheses.
+ .../src/main/java/com/me/RuleSet.java:357 These nested if statements could be combined
+ .../src/main/java/com/me/RuleSetWriter.java:66 Avoid empty catch blocks
+
+
+
C:\ > cd C:\pmd-bin-6.30.0-SNAPSHOT\bin
+C:\...\bin > .\pmd.bat -d ..\..\src\main\java\ -f text -R rulesets/java/quickstart.xml
+
+ .../src/main/java/com/me/RuleSet.java:123 These nested if statements could be combined
+ .../src/main/java/com/me/RuleSet.java:231 Useless parentheses.
+ .../src/main/java/com/me/RuleSet.java:232 Useless parentheses.
+ .../src/main/java/com/me/RuleSet.java:357 These nested if statements could be combined
+ .../src/main/java/com/me/RuleSetWriter.java:66 Avoid empty catch blocks
+
+
+
+
+
Running CPD via command line
+
+
Note: CPD supports Java, JSP, C, C++, C#, Fortran and PHP source code, among other languages.
+ For the full list, see Supported Languages.
+
+
Like for PMD, CPD is started on Unix by run.sh cpd and on Windows by cpd.bat.
+
+
There are two required parameters:
+
+
--files <path>: path to the sources to analyse. This can be a file name, a
+directory or a jar or zip file containing the sources.
+
--minimum-tokens <number>: the minimum token length which should be reported as a duplicate.
+
+
+
Tip: CPD’s command-line reference, Ant task usage, and many examples are documented in the
+ CPD documentation page
+
+
Sample usage
+
+
The following shows a sample run of CPD with the text format:
~ $ cd ~/bin/pmd-bin-6.30.0-SNAPSHOT/bin
+~/.../bin $ ./run.sh cpd --minimum-tokens 100 --files /home/me/src
+
+ Found a 7 line (110 tokens) duplication in the following files:
+ Starting at line 579 of /home/me/src/test/java/foo/FooTypeTest.java
+ Starting at line 586 of /home/me/src/test/java/foo/FooTypeTest.java
+
+ assertEquals(Boolean.TYPE, expressions.get(index++).getType());
+ assertEquals(Boolean.TYPE, expressions.get(index++).getType());
+ assertEquals(Boolean.TYPE, expressions.get(index++).getType());
+ assertEquals(Boolean.TYPE, expressions.get(index++).getType());
+ assertEquals(Boolean.TYPE, expressions.get(index++).getType());
+ assertEquals(Boolean.TYPE, expressions.get(index++).getType());
+ assertEquals(Boolean.TYPE, expressions.get(index++).getType());
+
+
+
C:\ > cd C:\pmd-bin-6.30.0-SNAPSHOT\bin
+C:\...\bin > .\cpd.bat --minimum-tokens 100 --files c:\temp\src
+
+ Found a 7 line (110 tokens) duplication in the following files:
+ Starting at line 579 of c:\temp\src\test\java\foo\FooTypeTest.java
+ Starting at line 586 of c:\temp\src\test\java\foo\FooTypeTest.java
+
+ assertEquals(Boolean.TYPE, expressions.get(index++).getType());
+ assertEquals(Boolean.TYPE, expressions.get(index++).getType());
+ assertEquals(Boolean.TYPE, expressions.get(index++).getType());
+ assertEquals(Boolean.TYPE, expressions.get(index++).getType());
+ assertEquals(Boolean.TYPE, expressions.get(index++).getType());
+ assertEquals(Boolean.TYPE, expressions.get(index++).getType());
+ assertEquals(Boolean.TYPE, expressions.get(index++).getType());
A ruleset is an XML configuration file, which describes a collection of rules to be executed in a PMD run. PMD includes built-in rulesets to run quick analyses with a default configuration, but users are encouraged to make their own rulesets from the start, because they allow for so much configurability. This page walk you through the creation of a ruleset and the multiple configuration features offered by rulesets.
Adding that element into the ruleset element adds the rule EmptyCatchBlock
+to your ruleset. This is a Java rule, so it will be executed on every Java file PMD encounters in
+its search space.
+
+
How to read the ref attribute?
+
+
+
+
category/java/errorprone.xml is a reference to the Java category errorprone. Since PMD 6.0.0,
+all PMD built-in rules are sorted in one of eight categories, which are consistent across languages:
+
+
+
Best Practices: These are rules which enforce generally accepted best practices.
+
Code Style: These rules enforce a specific coding style.
+
Design: Rules that help you discover design issues.
+
Documentation: These rules are related to code documentation.
+
Error Prone: Rules to detect constructs that are either broken, extremely confusing or prone to runtime errors.
+
Multithreading: These are rules that flag issues when dealing with multiple threads of execution.
+
Performance: Rules that flag suboptimal code.
+
Security: Rules that flag potential security flaws.”
+
+
+
+
+
Tip: You can discover the available rules by language and category from this page
+
+
+
EmptyCatchBlock is simply the name of the rule. If there were no rule with that name within the specified
+category, then PMD would fail before starting the analysis.
Here, the ref attribute references a whole category. You can also use a file system path or classpath relative path. In any case, the path must address an accessible ruleset XML file.
+
+
Note: Path separators in the source file path are normalized to be the / character within PMD, so the same ruleset can be used on multiple platforms transparently.
+
+
Note: Referencing a complete category or ruleset means, you’ll also get automatically any
+changes for this ruleset. If new rules are added, then these are automatically activated for you. If rules
+are deprecated, then these rules are automatically deactivated. This might or
+not might be, what you want. This can happen, if a new version of PMD provides a new rule and or deprecates
+existing rules. If you want to have
+complete control over the rules, that you are using, then it is recommended to add each rule separately via
+a single rule reference.
+
+
Filtering the processed files
+
+
You can exclude some files from being processed by a ruleset using exclude patterns, with an optional overridding include pattern. A file will be excluded from processing when there is a matching exclude pattern, but no matching include pattern. This exclude/include technique works regardless of how PMD is used (e.g. command line, IDE, Ant), making it easier to keep application of your PMD rules consistent throughout your environment. Here is an example:
PMD can report the found rule violations in various formats. Some formats can
+be customized further via properties. Violations might also be suppressed and there might
+be processing errors or configuration errors. Not all report formats display all information.
+
+
The header of the sections below are used to select the format on the command line, as
+arguments to the -format option. When a format accepts properties,
+those can be specified with the -property / -P option on the command-line.
+
+
Note: Suppressed violations are only reported, if the CLI parameter -showsuppressed is set.
+
+
codeclimate
+
+
Renderer for Code Climate JSON format.
+
+
This format is used when running PMD within Code Climate.
+The renderer will stream JSON objects, each object is a own issue (a PMD rule violation). Each issue
+is separated by the null character (\0).
The code climate format doesn’t support suppressed violations. It also doesn’t report any errors. But it contains
+the full rule details for each reported rule violation.
+
+
Example:
+
+
{"type":"issue","check_name":"GuardLogStatement","description":"Logger calls should be surrounded by log level guards.","content":{"body":"## GuardLogStatement\n\nSince: PMD 5.1.0\n\nPriority: Medium High\n\n[Categories](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#categories): Style\n\n[Remediation Points](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#remediation-points): 50000\n\nWhenever using a log level, one should check if the loglevel is actually enabled, or otherwise skip the associate String creation and manipulation.\n\n### Example:\n\n```java\n\n\n // Add this for performance\n if (log.isDebugEnabled() { ...\n log.debug('log something' + ' and ' + 'concat strings');\n\n \n``` \n\n### [PMD properties](https://pmd.github.io/pmd-6.22.0/pmd_userdocs_configuring_rules.html#rule-properties)\n\nName | Value | Description\n--- | --- | ---\nviolationSuppressRegex | | Suppress violations with messages matching a regular expression\nviolationSuppressXPath | | Suppress violations on nodes which match a given relative XPath expression.\nlogLevels | trace,debug,info,warn,error,log,finest,finer,fine,info,warning,severe | LogLevels to guard\nguardsMethods | isTraceEnabled,isDebugEnabled,isInfoEnabled,isWarnEnabled,isErrorEnabled,isLoggable | Method use to guard the log statement\n"},"categories":["Style"],"location":{"path":"/home/pmd/source/pmd-core/src/main/java/net/sourceforge/pmd/RuleContext.java","lines":{"begin":124,"end":125}},"severity":"normal","remediation_points":50000}
+{"type":"issue","check_name":"ForLoopCanBeForeach","description":"This for loop can be replaced by a foreach loop","content":{"body":"## ForLoopCanBeForeach\n\nSince: PMD 6.0.0\n\nPriority: Medium\n\n[Categories](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#categories): Style\n\n[Remediation Points](https://github.com/codeclimate/platform/blob/master/spec/analyzers/SPEC.md#remediation-points): 50000\n\nReports loops that can be safely replaced with the foreach syntax. The rule considers loops over lists, arrays and iterators. A loop is safe to replace if it only uses the index variable to access an element of the list or array, only has one update statement, and loops through *every* element of the list or array left to right.\n\n### Example:\n\n```java\n\n\npublic class MyClass {\n void loop(List<String> l) {\n for (int i = 0; i < l.size(); i++) { // pre Java 1.5\n System.out.println(l.get(i));\n }\n\n for (String s : l) { // post Java 1.5\n System.out.println(s);\n }\n }\n}\n\n \n``` \n\n### [PMD properties](https://pmd.github.io/pmd-6.22.0/pmd_userdocs_configuring_rules.html#rule-properties)\n\nName | Value | Description\n--- | --- | ---\nviolationSuppressRegex | | Suppress violations with messages matching a regular expression\nviolationSuppressXPath | | Suppress violations on nodes which match a given relative XPath expression.\n"},"categories":["Style"],"location":{"path":"/home/pmd/source/pmd-core/src/main/java/net/sourceforge/pmd/benchmark/Benchmarker.java","lines":{"begin":58,"end":62}},"severity":"normal","remediation_points":50000}
+
+
+
csv
+
+
Comma-separated values tabular format.
+
+
This format only renders rule violations. Suppressed violations or errors are ignored.
+
+
Example:
+
+
"Problem","Package","File","Priority","Line","Description","Rule set","Rule"
+"1","net.sourceforge.pmd","/home/pmd/source/pmd-core/src/main/java/net/sourceforge/pmd/RuleContext.java","2","124","Logger calls should be surrounded by log level guards.","Best Practices","GuardLogStatement"
+"1","net.sourceforge.pmd.benchmark","/home/pmd/source/pmd-core/src/main/java/net/sourceforge/pmd/benchmark/Benchmarker.java","3","58","This for loop can be replaced by a foreach loop","Best Practices","ForLoopCanBeForeach"
+
+
+
This format can be configured to display only certain columns. In order to not show the problem counter and package
+columns, use these CLI parameters additionally: -property problem=false -property package=false
+
+
Properties:
+
+
+
problem: Include problem column. Default: true.
+
package: Include package column. Default: true.
+
file: Include file column. Default: true.
+
priority: Include priority column. Default: true.
+
line: Include line column. Default: true.
+
desc: Include description column. Default: true.
+
ruleSet: Include Rule set column. Default: true.
+
rule: Include Rule column. Default: true.
+
+
+
emacs
+
+
GNU Emacs integration.
+
+
Example:
+
+
/home/pmd/source/pmd-core/src/main/java/net/sourceforge/pmd/RuleContext.java:124: Logger calls should be surrounded by log level guards.
+/home/pmd/source/pmd-core/src/main/java/net/sourceforge/pmd/benchmark/Benchmarker.java:58: This for loop can be replaced by a foreach loop
+
+
+
html
+
+
HTML format.
+
+
This renderer provides two properties to render a link to the source where the violations
+have been found. The following example has been created with -property linkPrefix=https://github.com/pmd/pmd/blob/master/ -property linePrefix=L -shortnames -d pmd.
+If “linkPrefix” is not set, then “linePrefix” has no effect anyway: just the filename will
+be rendered, with no html link. Otherwise if “linePrefix” is not set, then the link will
+not contain a line number.
+
+
When using Maven JXR Plugin to generate a html view
+of the project’s sources, then the property “htmlExtension” needs to be set to “true”. This will then replace the
+normal source file extensions (e.g. “.java”) with “.html”, so that the generated html pages are referenced.
linePrefix: Prefix for line number anchor in the source file.
+
linkPrefix: Path to HTML source.
+
htmlExtension: Replace file extension with .html for the links (default: false)
+
+
+
text (default)
+
+
This is the default format.
+
+
This format outputs one line per violation. At the end, processing errors, suppressed violations
+and configuration errors are reported.
+
+
Example:
+
+
/home/pmd/source/pmd-core/src/main/java/net/sourceforge/pmd/RuleContext.java:124: Logger calls should be surrounded by log level guards.
+/home/pmd/source/pmd-core/src/main/java/net/sourceforge/pmd/benchmark/Benchmarker.java:58: This for loop can be replaced by a foreach loop
+/home/pmd/source/pmd-core/src/test/resources/net/sourceforge/pmd/cpd/files/file_with_ISO-8859-1_encoding.java - PMDException: Error while parsing /home/pmd/source/pmd-core/src/test/resources/net/sourceforge/pmd/cpd/files/file_with_ISO-8859-1_encoding.java
+CloseResource rule violation suppressed by Annotation in /home/pmd/source/pmd-core/src/main/java/net/sourceforge/pmd/PMD.java
+LoosePackageCoupling - No packages or classes specified
+
+
+
textcolor
+
+
Text format, with color support (requires ANSI console support, e.g. xterm, rxvt, etc.).
+
+
Example:
+
+
+* file: ./pmd-core/src/main/java/net/sourceforge/pmd/RuleContext.java
+ src:RuleContext.java:124:125
+ rule: GuardLogStatement
+ msg: Logger calls should be surrounded by log level guards.
+ code: LOG.warning("The method RuleContext::setSourceCodeFilename(String) has been deprecated and will be removed."
+
+* file: ./pmd-core/src/main/java/net/sourceforge/pmd/benchmark/Benchmarker.java
+ src:Benchmarker.java:58:62
+ rule: ForLoopCanBeForeach
+ msg: This for loop can be replaced by a foreach loop
+ code: for (int i = 0; i < args.length; i++) {
+
+
+
+Summary:
+
+net.sourceforge.pmd.RuleContext : 1
+net.sourceforge.pmd.benchmark.Benchmarker : 1
+* file: ./pmd-core/src/test/resources/net/sourceforge/pmd/cpd/files/file_with_ISO-8859-1_encoding.java
+ err:PMDException: Error while parsing /home/pmd/source/pmd-core/src/test/resources/net/sourceforge/pmd/cpd/files/file_with_ISO-8859-1_encoding.java
+net.sourceforge.pmd.PMDException: Error while parsing /home/pmd/source/pmd-core/src/test/resources/net/sourceforge/pmd/cpd/files/file_with_ISO-8859-1_encoding.java
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCodeWithoutCache(SourceCodeProcessor.java:110)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCode(SourceCodeProcessor.java:89)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCode(SourceCodeProcessor.java:51)
+ at net.sourceforge.pmd.processor.PmdRunnable.call(PmdRunnable.java:78)
+ at net.sourceforge.pmd.processor.PmdRunnable.call(PmdRunnable.java:24)
+ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
+ at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
+ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
+ at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
+ at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
+ at java.base/java.lang.Thread.run(Thread.java:832)
+Caused by: net.sourceforge.pmd.lang.java.ast.ParseException: Encountered " "-" "- "" at line 6, column 30.
+Was expecting one of:
+ "extends" ...
+ "implements" ...
+ "{" ...
+ "<" ...
+
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.generateParseException(JavaParser.java:12713)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.jj_consume_token(JavaParser.java:12597)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.ClassOrInterfaceBody(JavaParser.java:1554)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.ClassOrInterfaceDeclaration(JavaParser.java:732)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.TypeDeclaration(JavaParser.java:639)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.CompilationUnit(JavaParser.java:373)
+ at net.sourceforge.pmd.lang.java.AbstractJavaParser.parse(AbstractJavaParser.java:62)
+ at net.sourceforge.pmd.SourceCodeProcessor.parse(SourceCodeProcessor.java:121)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSource(SourceCodeProcessor.java:185)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCodeWithoutCache(SourceCodeProcessor.java:107)
+ ... 10 more
+
+
+* rule: LoosePackageCoupling
+ err:No packages or classes specified
+
+* errors: 2
+* warnings: 2
+
+
+
Properties:
+
+
+
color: Enables colors with anything other than false or 0. Default: yes.
+
+
+
textpad
+
+
TextPad integration.
+
+
Example:
+
+
/home/pmd/source/pmd-core/src/main/java/net/sourceforge/pmd/RuleContext.java(124, GuardLogStatement): Logger calls should be surrounded by log level guards.
+/home/pmd/source/pmd-core/src/main/java/net/sourceforge/pmd/benchmark/Benchmarker.java(58, ForLoopCanBeForeach): This for loop can be replaced by a foreach loop
+
+
+
vbhtml
+
+
Vladimir Bossicard HTML format.
+
+
xml
+
+
XML format.
+
+
This format is a XML document, that can be validated by a XSD schema. The schema is report_2_0_0.xsd.
+
+
Example:
+
+
<?xml version="1.0" encoding="UTF-8"?>
+<pmdxmlns="http://pmd.sourceforge.net/report/2.0.0"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://pmd.sourceforge.net/report/2.0.0 https://pmd.sourceforge.io/report_2_0_0.xsd"
+ version="6.22.0"timestamp="2020-04-11T19:17:03.207">
+<filename="/home/pmd/source/pmd-core/src/main/java/net/sourceforge/pmd/RuleContext.java">
+<violationbeginline="124"endline="125"begincolumn="9"endcolumn="111"rule="GuardLogStatement"ruleset="Best Practices"package="net.sourceforge.pmd"class="RuleContext"method="setSourceCodeFilename"externalInfoUrl="https://pmd.github.io/pmd-6.22.0/pmd_rules_java_bestpractices.html#guardlogstatement"priority="2">
+Logger calls should be surrounded by log level guards.
+</violation>
+</file>
+<filename="/home/pmd/source/pmd-core/src/main/java/net/sourceforge/pmd/benchmark/Benchmarker.java">
+<violationbeginline="58"endline="62"begincolumn="9"endcolumn="9"rule="ForLoopCanBeForeach"ruleset="Best Practices"package="net.sourceforge.pmd.benchmark"class="Benchmarker"method="findBooleanSwitch"externalInfoUrl="https://pmd.github.io/pmd-6.22.0/pmd_rules_java_bestpractices.html#forloopcanbeforeach"priority="3">
+This for loop can be replaced by a foreach loop
+</violation>
+</file>
+<errorfilename="/home/pmd/source/pmd-core/src/test/resources/net/sourceforge/pmd/cpd/files/file_with_ISO-8859-1_encoding.java"msg="PMDException: Error while parsing /home/pmd/source/pmd-core/src/test/resources/net/sourceforge/pmd/cpd/files/file_with_ISO-8859-1_encoding.java">
+<![CDATA[net.sourceforge.pmd.PMDException: Error while parsing /home/pmd/source/pmd-core/src/test/resources/net/sourceforge/pmd/cpd/files/file_with_ISO-8859-1_encoding.java
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCodeWithoutCache(SourceCodeProcessor.java:110)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCode(SourceCodeProcessor.java:89)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCode(SourceCodeProcessor.java:51)
+ at net.sourceforge.pmd.processor.PmdRunnable.call(PmdRunnable.java:78)
+ at net.sourceforge.pmd.processor.PmdRunnable.call(PmdRunnable.java:24)
+ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
+ at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
+ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
+ at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
+ at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
+ at java.base/java.lang.Thread.run(Thread.java:832)
+Caused by: net.sourceforge.pmd.lang.java.ast.ParseException: Encountered " "-" "- "" at line 6, column 30.
+Was expecting one of:
+ "extends" ...
+ "implements" ...
+ "{" ...
+ "<" ...
+
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.generateParseException(JavaParser.java:12713)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.jj_consume_token(JavaParser.java:12597)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.ClassOrInterfaceBody(JavaParser.java:1554)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.ClassOrInterfaceDeclaration(JavaParser.java:732)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.TypeDeclaration(JavaParser.java:639)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.CompilationUnit(JavaParser.java:373)
+ at net.sourceforge.pmd.lang.java.AbstractJavaParser.parse(AbstractJavaParser.java:62)
+ at net.sourceforge.pmd.SourceCodeProcessor.parse(SourceCodeProcessor.java:121)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSource(SourceCodeProcessor.java:185)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCodeWithoutCache(SourceCodeProcessor.java:107)
+ ... 10 more
+]]>
+</error>
+<suppressedviolationfilename="/home/pmd/source/pmd-core/src/main/java/net/sourceforge/pmd/PMD.java"suppressiontype="annotation"msg="Ensure that resources like this OutputStreamWriter object are closed after use"usermsg=""/>
+<configerrorrule="LoosePackageCoupling"msg="No packages or classes specified"/>
+</pmd>
+
+
+
Properties:
+
+
+
encoding: XML encoding format, defaults to UTF-8.
+
+
+
xslt
+
+
XML with a XSL transformation applied.
+
+
PMD provides one built-in stylesheet, that is used by default, if no other
+stylesheet with the property “xsltFilename” is specified. It is called pmd-nicerhtml.xsl and can be used for customization.
This renderer creates an html file per analyzed source file, hence you need to specify a output directory.
+The output directory must exist. If not specified, the html files are created in the current directory.
PMD provides several methods by which Rule violations can be suppressed.
+Follow these steps to help you determine which expression method works best
+for you:
+
+
+
+
Is the thing you need to suppress universally appealing to other
+users of PMD, or is it a false positive? Can you modify the Rule to
+support this specific suppression via a configuration property, or to
+fix the false positive? If you can do this, then please do so, and
+submit a patch back to the PMD project. Since PMD is built by users
+for users, your help would be greatly appreciated by everyone. If you
+cannot…
+
+
+
Can you use Annotations or the NOPMD marker to work around your
+particular issue on a case by case basis? If not…
+
+
+
Can a regular expression matching the violation message work
+around your particular issue? If not…
+
+
+
Can a XPath query on the violation node work around your particular
+issue? If not…
+
+
+
Your last and final option is to see the first point about
+changing the Rule, but you do not need to submit a patch back to the
+PMD project.
+
+
+
+
If you need to modify the Rule, see How to write a rule.
+Otherwise, the other suppression methods are explained in the following sections.
+
+
Annotations
+
+
When using Java 1.5 or later, you can use annotations to suppress PMD warnings, like this:
+
+
// This will suppress all the PMD warnings in this class
+@SuppressWarnings("PMD")
+publicclassBar{
+ voidbar(){
+ intfoo;
+ }
+}
+
+
+
When using Apex make sure to use single quotes instead of double quotes
+
+
// This will suppress all the PMD warnings in this class
+@SuppressWarnings('PMD')
+
+
+
Or you can suppress one rule with an annotation like this:
+
+
// This will suppress UnusedLocalVariable warnings in this class
+@SuppressWarnings("PMD.UnusedLocalVariable")
+publicclassBar{
+ voidbar(){
+ intfoo;
+ }
+}
+
+
+
Multiple rules can be suppressed by providing multiple values, ie:
PMD Java also obeys the JDK annotation @SuppressWarnings(“unused”), which will apply to all rules in the unused ruleset.
+
+
// This will suppress UnusedLocalVariable and UnusedPrivateMethod warnings in this class
+@SuppressWarnings("unused")
+publicclassBar{
+ voidbar(){
+ intfoo;
+ }
+ privatevoidfoobar(){}
+}
+
+
+
NOPMD comment
+
+
Alternatively, you can tell PMD to ignore a specific line by using the “NOPMD” marker in a comment, like this:
+
+
publicclassBar{
+ // 'bar' is accessed by a native method, so we want to suppress warnings for it
+ privateintbar;//NOPMD
+}
+
+
+
You can use whatever text string you want to suppress warnings, by using the -suppressmarker CLI option.
+For example, here’s how to use TURN_OFF_WARNINGS as the suppressor:
Note that PMD expects the //NOPMD marker to be on the same line as the violation. So, for
+example, if you want to suppress an “empty if statement” warning, you’ll need to place it on
+the line containing the if keyword, e.g.:
A message placed after the NOPMD marker will get placed in the report, e.g.:
+
+
publicclassFoo{
+ voidbar(){
+ try{
+ bar();
+ }catch(FileNotFoundExceptione){}// NOPMD - this surely will never happen
+ }
+}
+
+
+
XPath and Regex message suppression
+
+
If a particular rule consistently reports a warning in a particular context, you can fall
+back to disabling the rule for all these contexts using one of two rule properties
+that are defined on every rule. Depending on what you’re after, you can suppress
+violations for specific messages using regular expressions, or specific nodes
+using an XPath expression.
+
+
The property violationSuppressRegex
+
+
This property defines a regular expression to match against the
+message of the violation. If the regular expression matches,
+then the violation will be suppressed.
+
+
For example, to suppress reporting specifically named parameters which
+are unused:
Note for message based suppression to work, you must know how to write
+a regular expression that matches the message of violations you wish to
+suppress. Regular expressions are explained in the JavaDoc for standard
+Java class java.util.regex.Pattern.
+
+
This technique of course relies on how the rule’s message is implemented.
+Some rules always report the same message, in which case this property is
+of no use.
+
+
The property violationSuppressXPath
+
+
This property defines an XPath query to be executed using the
+violation node as the context node. If the XPath query matches anything,
+then the violation will be suppressed. Note that the query shouldn’t be finding
+the violation nodes to suppress, but rather, finding a non-empty sequence of nodes
+when evaluated with the violation node as a context node.
+
+
The XPath version used by those queries is XPath 1.0, so it doesn’t support various XPath 2.0
+features. This will be updated with PMD 7.0.0.
+
+
For example, to suppress reporting specifically “String” parameters which are unused:
Note the use of . to refer to the context node. Using // at the start of the
+expression should be avoided, as it would test all nodes in the file, and suppress
+more violations than expected.
+
+
Another example, to suppress violations occurring in classes whose name contains Bean:
Note here the usage of the ./ancestor:: axis instead of //. The latter would match
+any ClassOrInterfaceDeclaration in the file, while the former matches only class
+declaration nodes that enclose the violation node, which is usually what you’d want.
+
+
Note for XPath based suppression to work, you must know how to write
+an XPath query that matches the AST structure of the nodes of the
+violations you wish to suppress. XPath queries are explained in
+XPath Rule tutorial.
Codacy automates code reviews and monitors code quality on every commit and pull request.
+It gives visibility into the technical debt and it can track code style and security issues, code coverage, code duplication, cyclomatic complexity and enforce best practices.
+Codacy is static analysis without the hassle.
+
+
With Codacy you have PMDJava analysis out-of-the-box, and it is free for open source projects.
A general note - most plugins include the PMD jar files, which has the rulesets
+inside it. So even though the rulesets parameter that some plugins
+use (i.e., “rulesets/java/unusedcode.xml”) looks like a filesystem reference, it’s really
+being used by a getResourceAsStream() call to load it out of the PMD jar files.
+
+
BlueJ
+
+
BlueJ is a teaching IDE. To install the PMD extension for BlueJ, download
+the PMDExtension jar file
+and place it in your bluej/lib/extensions/ directory.
+
+
Eclipse
+
+
To install the PMD plugin for Eclipse:
+
+
+
Start Eclipse and open a project
+
Select “Help”->”Software Updates”->”Find and Install”
Click through the rest of the dialog boxes to install the plugin
+
+
+
Alternatively, you can download the latest zip file and follow the above procedures
+except for using “New local site” and browsing to the downloaded zip file.
+
+
To configure PMD, select “Windows”->”Preferences”, then select PMD.
+
+
To run PMD, right-click on a project node and select “PMD”->”Check code with PMD”.
+
+
To run the duplicate code detector, right-click on a project node and
+select “PMD”->”Find suspect cut and paste”. The report will be placed in a “reports” directory
+in a file called “cpd-report.txt”.
+
+
To find additional help for other features, please read included help by selecting
+Help->Help Contents and browse the “How to…” section in the “PMD Plugin Documentation” book.
+
+
After installing an update, if you get an Exception such as
+“java.lang.RuntimeException: Couldn’t find that class xxxxx”,
+try deleting the ruleset.xml file in the .metadata/plugins/net.sourceforge.pmd.eclipse directory in your workspace.
+
+
To get Eclipse to not flag the @SuppressWarnings(“PMD”) annotation, look
+under the menu headings Java -> Compiler -> Errors/Warnings -> Annotations -> Unhandled Warning Token.
+
+
Emacs
+
+
Integration with GNU Emacs is performed through an ELisp package, pmd.el.
+It supports two commands, “pmd-current-buffer” and “pmd-current-dir”.
+The output is captured in a compilation buffer which allows the user to “jump”
+directly to the source code position associated with the PMD warnings.
+
+
Gel
+
+
Here’s how to set up the Gel plugin:
+
+
+
Download the pmd-gel-[version].zip file
+
Close Gel
+
Remove any old plugin versions from your gel\plugins directory
+
Unzip the new zip file into your gel\plugins directory
+
Start Gel
+
Go to Tools->Options->Plugin
+
Select the PMD plugin and click “Remove”
+
Click “Add” and select “net.sourceforge.pmd.gel.PMDPlugin”
+
Restart Gel
+
+
+
That’s pretty much it. Now you can open a Java project and click on Plugins->PMD and
+a configuration panel will pop up. You can pick which ruleset you want to run and
+you can also pick whether you want to run PMD on the current file or on every
+source file in your project.
+
+
IDEA
+
+
You can use an integrated plugin or just use it as an IDEA “External Tool”.
That’s pretty much it. Now you can right click on a source directory and select PMD,
+it’ll run recursively on the source files, and the results should
+be displayed in a window and hyperlinked into the correct file and line of code. I usually
+right-click on the message window title bar and unselect “autohide” so the window doesn’t go
+away every time I fix something in the code window.
+
+
IDEA - QAPlug
+
+
QAPlug is an Intellij IDEA plugin to manage code quality. It integrates no less than Checkstyle, FindBugs, and PMD.
Check a single file by bringing up the context menu from the file tab and selecting PMDCheck
+
Configure the rulesets that the PMD OpenTool will use by selecting Tools->PMD->Configure PMD
+
Check all the files in a project by bringing up the context menu for
+the project node and selecting PMD Check Project
+
Locate duplicate code by right clicking on a package and selection “Check with CPD”
+
+
+
When running PMD, the results will be displayed in the MessageView under a tab called PMD Results. If you click on a
+violation message within this view, you will be taken to the line in the source code where the violation was detected.
+
+
Things still to do:
+
+
+
Enable selection of individual rules within a rule set (maybe)
+
Optional insertion of @todo comments at the point of a violation
+
Possibly provide configurable ability to limit the number of violations per rule per file
+
+
+
JCreator
+
+
+
Open Configure > Options
+
Go to the Tools panel
+
Click New > Program
+
Browse for PMD’s pmd.bat
+
Put quotations around the path if it has spaces.
+
Set the initial directory to PMD’s \bin directory
+
Check capture output
+
Put ‘”$[PrjDir]” emacs’ followed by desired rulesets in the arguments
+
+
+
To run PMD on a project, just pick pmd from the Tools menu.
+
+
JDeveloper
+
+
To install the PMD plugin for JDeveloper:
+
+
+
JDeveloper 10.1.2: Download the binary release and unzip it into your jdev/lib/ext directory
+
JDeveloper 10.1.3 upwards: Click “Help”, click “Check for Updates”
+
JDeveloper 11 upwards: Select Update Center: Open Source and Partner Extensions
+
Press Next and select the actual PMD Plugin and install it
+
+
+
Restart JDeveloper
+
+
+
To run the PMD plugin for JDeveloper:
+
+
+
Open the Tools-&Preferences menu
+
Click on the PMD option
+
Select a couple of rules to try
+
To run PMD, right click on either a file, folder, package, project or workspace and select PMD via
+Toolbar Icon, Context Menu or File Menu
+
Any rule violations should show up in a LogWindow tab at the bottom of the screen
+
+
+
JEdit
+
+
The way I use the JEdit plugin is:
+
+
+
Dock the ErrorList by going to Utilities->Global Options->Docking and
+putting ErrorList at the bottom of the screen
+
Open the File Browser if it isn’t already open
+
Double-click on a source directory
+
Select Plugins->PMD->Check directory recursively
+
+
+
Note that you can select individual rules by going to Utilities->Global Options->Plugin Options->PMD.
+Also, you can change the plugin to prompt you for a directory to check by going to that same menu and
+selecting the “Ask for Directory” checkbox.
+
+
NetBeans
+
+
The SQE project includes PMD integration for NetBeans.
+
+
TextPad
+
+
Assumptions
+
+
+
The Java Development Kit, version 1.4.2 (versions 1.4 and higher are acceptable) is properly installed
+into your machine, and exists in D:\java\jdk\_142\. This means that D:\java\jdk\_142\bin\java.exe exists.
+
PMD version 5.0 exists in D:\java\pmd-bin-\.
+This means that D:\java\pmd-bin-\lib\pmd-.jar (among other jar files
+in the same directory) exist.
+
+
+
To integrate into TextPad
+
+
+
In the Configure menu, choose Preferences…. This opens the Preferences dialog
+
In the left pane of the Preferences dialog, choose the Tools branch by clicking on the word “Tools”.
+
On the far right of the dialog, click on the Add button, and then select Program… from the drop-down.
+This opens the standard Windows Open File dialog.
+
Type D:\java\jdk_142\bin\java.exe and click the Open button. In the center pane of the Preferences dialog,
+an item “Java” has now been added, and is currently selected.
+
Click the word Java, which makes the word editable. Select the entire word, and type “PMD directory”. Press Return.
+
Repeat steps three through five, but type “PMD file”, instead of “PMD directory”.
+
Click Apply.
+
Expand the Tools branch (if not already) by clicking on the ‘+’ directly to its left.
+
In the expanded list, select PMD directory. This changes the right side of this dialog to the “tool” form.
Regular expression to match output:^\([^(]+\)(\([0-9]+\),
+
Registers/File:1
+
Registers/Line:2
+
+
+
In the expanded list, select PMD file.
+
In the “tool” form, enter the same parameters as above, except replace ‘$FileDir’ with ‘$File’,
+in the Parameters textbox.
+
To save your work (truly, given a quirk of TextPad), click on OK, which closes the Preferences dialog.
+Restart TextPad and re-open the Preferences dialog.
+
Go back to both the “PMD directory” and “PMD file” Tools branches, and replace ‘E:\directory\my_pmd_ruleset.xml’
+with the ruleset of your choice. For example, basic.
+
Go to the Keyboard branch in the left pane (above Tools), which changes the right side to
+the “keyboard configuration” form.
+
In the Categories list box, select Tools.
+
In the Command list box, select PMD directory.
+
Put your cursor into the Press new shortcut key, and type your desired key command.
+For example Ctrl+Page Up
+
Click Assign.
+
In the Command list box, select PMD file.
+
Put your cursor into the Press new shortcut key, and type your desired key command.
+For example Ctrl+Page Down
+
Click Assign.
+
Save your work again: Click on OK, which closes the Preferences dialog, and then restart TextPad.
+
+
+
To run PMD against a single Java file
+
+
+
In TextPad, open any Java file.
+
Click Ctrl+Page Down. This opens an empty, read-only text document (titled “Command Results”).
+When PMD completes its analysis, this document will be populated with a listing of violated rules
+(or “Command completed successfully” indicating no violations).
+
Double click any line to go to it.
+
+
+
To run PMD against a directory of Java files
+
+
+
In TextPad, open any file in the root directory you wish to analyze. Unfortunately, you’ll need to
+create a dummy file, if no file exists there.
+
Click Ctrl+Page Up. This opens an empty, read-only text document (titled “Command Results”).
+When PMD completes its analysis, this document will be populated with a listing of violated rules
+(or “Command completed successfully” indicating no violations).
+
Double click any line to go to it.
+
+
+
Because directory analysis may take a while, you may choose to cancel this operation. Do so by closing
+the (blank Command Results) document, and then confirming that, “yes, I do really want to exit the tool”.
Runs a set of static code analysis rules on some source code files and generates a list of problems found.
+
+
Installation
+
+
Before you can use the pmd task in your ant build.xml file, you need to install PMD and its libraries into
+ant’s classpath, as described in Optional Tasks.
+
+
First you need to download PMD’s binary distribution zip file.
+Then you can either copy all “*.jar” files from PMD’s lib folder into one of ANT’s library folders
+(ANT_HOME/lib, ${user.home}/.ant/lib) or using the -lib command line parameter.
+
+
However, the preferred way is to define a <classpath> for pmd itself and use this classpath when
+adding the PMD Task. Assuming, you have extracted the PMD zip file to /home/joe/pmd-bin-6.30.0-SNAPSHOT,
+then you can make use of the PMD Task like this:
The examples below won’t repeat this taskdef element, as this is always required.
+
+
Parameters
+
+
+
+
Attribute
+
Description
+
Required
+
+
+
rulesetfiles
+
+ A comma delimited list of ruleset files ('rulesets/java/quickstart.xml,config/my-ruleset.xml').
+ If you write your own ruleset files, you can put them on the classpath and plug them in here.
+
+
Yes, unless the ruleset nested element is used
+
+
+
failonerror
+
Whether or not to fail the build if any errors occur while processing the files
+
No
+
+
+
failOnRuleViolation
+
Whether or not to fail the build if PMD finds any problems
+
No
+
+
+
minimumPriority
+
The rule priority threshold; rules with lower priority than they will not be used
+
No
+
+
+
shortFilenames
+
Places truncated filenames in the report. This can reduce your report file size by 15%-20%.
+
No
+
+
+
failuresPropertyName
+
A property name to plug the number of rule violations into when the task finishes
+
No
+
+
+
encoding
+
The character set encoding (e.g. UTF-8) to use when reading the source code files
+
No
+
+
+
suppressMarker
+
The series of characters to use to tell PMD to skip lines - the default is NOPMD.
+
No
+
+
+
maxRuleViolations
+
+ Whether or not to fail the build if PMD finds more than the value of this attribute.
+ Note that setting this attribute does not require to set the failOnRuleViolation to true.
+
+
No
+
+
+
cacheLocation
+
+ The location of the analysis cache file to be used.
+ Setting this property enables Incremental Analysis, which can greatly improve analysis time without loosing analysis quality.
+ Its use is strongly recommended.
+
+
No
+
+
+
noCache
+
+ Setting this property to true disables Incremental Analysis, even if cacheLocation is provided.
+ You can use this to explicitly turn off suggestions to use incremental analysis, or for testing purposes.
+
+
No
+
+
+
+
formatter nested element - specifies the format of and the files to which the report is written. You can
+configure multiple formatters.
Whether to show suppressed warnings; "false" is the default.
+
+
+
toFile
+
A filename to which to write the report
+
+
+
toConsole
+
Whether to output the report to the console; "false" is the default.
+
+
+
+
The formatter element can contain nested param elements to configure the formatter in detail, e.g.
+
+
encoding
+
Specifies the encoding to be used in the generated report (only honored when used with `toFile`). When rendering `toConsole` PMD will automatically detect the terminal's encoding and use it, unless the output is being redirected / piped, in which case `file.encoding` is used. See example below.
+
linkPrefix
+
Used for linking to online HTMLized source (like this). See example below. Note, this only works with
+ maven-jxr-plugin.
+
linePrefix
+
Used for linking to online HTMLized source (like this). See example below. Note, this only works with maven-jxr-plugin.
+
+
+
+
+
+
classpath nested element - useful for specifying custom rules. More details on the classpath
+element are in the Ant documentation for path-like structures and there’s
+an example below.
+
+
auxclasspath nested element - extra classpath used for type resolution. Some rules make use of type resolution
+in order to avoid false positives. The auxclasspath is configured also with path-like structures. It should contain the compiled classes of the project that is being analyzed and all the compile time
+dependencies.
+
+
sourceLanguage nested element - specify which language (Java, Ecmascript, XML,…)
+and the associated version (1.5, 1.6,…). This element is optional. The language is determined by file extension
+automatically and the latest language version is used.
+
+
ruleset nested element - another way to specify rulesets. You can specify multiple elements. Here’s an example:
fileset nested element - specify the actual java source files, that PMD should analyze. You can use multiple
+fileset elements. See FileSet for the syntax and usage.
+
+
Language version selection
+
+
PMD selects the language automatically using the file extension. If multiple versions of a language are
+supported, PMD uses the latest version as default. This is currently the case for Java only, which has
+support for multiple versions.
+
+
If a languages supports multiple versions, you can select a specific version here, so that e.g. rules, that only apply
+to specific versions, are not executed. E.g. the rule UseTryWithResources only makes
+sense with Java 1.7 and later. If your project uses Java 1.5, then you should configure the sourceLanguage
+accordingly and this rule won’t be executed.
+
+
The specific version of a language to be used is selected via the sourceLanguage
+nested element. Possible values are:
+
+
<sourceLanguage name="apex" version="48"/>
+<sourceLanguage name="ecmascript" version="3"/>
+<sourceLanguage name="java" version="1.3"/>
+<sourceLanguage name="java" version="1.4"/>
+<sourceLanguage name="java" version="1.5"/>
+<sourceLanguage name="java" version="5"/> <!-- alias for 1.5 -->
+<sourceLanguage name="java" version="1.6"/>
+<sourceLanguage name="java" version="6"/> <!-- alias for 1.6 -->
+<sourceLanguage name="java" version="1.7"/>
+<sourceLanguage name="java" version="7"/> <!-- alias for 1.7 -->
+<sourceLanguage name="java" version="1.8"/>
+<sourceLanguage name="java" version="8"/> <!-- alias for 1.8 -->
+<sourceLanguage name="java" version="9"/>
+<sourceLanguage name="java" version="1.9"/> <!-- alias for 9 -->
+<sourceLanguage name="java" version="10"/>
+<sourceLanguage name="java" version="1.10"/> <!-- alias for 10 -->
+<sourceLanguage name="java" version="11"/>
+<sourceLanguage name="java" version="12"/>
+<sourceLanguage name="java" version="13"/>
+<sourceLanguage name="java" version="13-preview"/>
+<sourceLanguage name="java" version="14"/> <!-- this is the default -->
+<sourceLanguage name="java" version="14-preview"/>
+<sourceLanguage name="jsp" version=""/>
+<sourceLanguage name="modelica" version=""/>
+<sourceLanguage name="pom" version=""/>
+<sourceLanguage name="plsql" version=""/>
+<sourceLanguage name="scala" version="2.10"/>
+<sourceLanguage name="scala" version="2.11"/>
+<sourceLanguage name="scala" version="2.12"/>
+<sourceLanguage name="scala" version="2.13"/> <!-- this is the default -->
+<sourceLanguage name="vf" version=""/>
+<sourceLanguage name="vm" version=""/>
+<sourceLanguage name="wsdl" version=""/>
+<sourceLanguage name="xml" version=""/>
+<sourceLanguage name="xsl" version=""/>
+
+
+
Postprocessing the report file with XSLT
+
+
Several folks (most recently, Wouter Zelle) have written XSLT scripts
+which you can use to transform the XML report into nifty HTML. To do this,
+make sure you use the XML formatter in the PMD task invocation, i.e.:
+
+
<formatter type="xml" toFile="${tempbuild}/report_pmd.xml">
+ <param name="encoding" value="UTF-8" /> <!-- enforce UTF-8 encoding for the XML -->
+</formatter>
+
Using a custom renderer. For this to work, you need to add you custom renderer to the classpath of PMD. This
+need to be configured when defining the task:
Memory usage has been reduced significantly starting with the PMD 4.0 release.
+When testing all Java rules on the jdk 1.6 source code (about 7000 classes),
+the allocated heap space does not go over 60M.
+
+
However, on very large projects, the Ant task may still fail with a OutOfMemoryError.
+To prevent this from happening, increase the maximum memory usable by ant using the ANT_OPTS variable
+(adjust the size according to your available memory):
The easiest way to run PMD is to just use a build plugin in your favorite build tool
+like Apache Ant, Apache Maven or
+Gradle.
+
+
There are also many integrations for IDEs available, see Tools.
+
+
If you have your own build tool or want to integrate PMD in a different way, you can call PMD programmatically,
+as described here.
+
+
Dependencies
+
+
You’ll need to add the dependency to the language, you want to analyze. For Java, it will be
+net.sourceforge.pmd:pmd-java. If you use Maven, you can add a new (compile time) dependency like this:
In order to support type resolution, PMD needs to have access to the compiled classes and dependencies
+as well. This is called “auxclasspath” and is also configured here.
+Note: you can specify multiple class paths separated by : on Unix-systems or ; under Windows.
For reporting, you can use a built-in renderer, e.g. XMLRenderer. Note, that you must manually initialize
+the renderer by setting a suitable Writer and calling start(). After the PMD run, you need to call
+end() and flush(). Then your writer should have received all output.
Create a RuleContext. This is the context instance, that is available then in the rule implementations.
+Note: when running in multi-threaded mode (which is the default), the rule context instance is cloned for
+each thread.
+
+
RuleContextctx=newRuleContext();
+
+
+
+
Optionally register a report listener. This allows you to react immediately on found violations. You could also
+use such a listener to implement your own renderer. The listener must implement the interface
+ThreadSafeReportListener and can be registered via ctx.getReport().addListener(...).
Now, all the preparations are done, and PMD can be executed. This is done by calling
+PMD.processFiles(...). This method call takes the configuration, the ruleset factory, the files
+to process, the rule context and the list of renderers. Provide an empty list, if you don’t want to use
+any renderer. Note: The auxclasspath needs to be closed explicitly. Otherwise the class or jar files may
+remain open and file resources are leaked.
When adding the maven-pmd-plugin to your pom.xml, you need to select a version. To figure out the
+latest available version, have a look at the official maven-pmd-plugin documentation.
+
+
As of March 2020, the current plugin version is 3.13.0.
+
+
The version of the plugin should be specified in <build><pluginManagement/></build> and if using the project
+report additionally in <reporting><plugins/></reporting> elements. Here’s an example for the pluginManagement
+section:
When defining the version in the pluginManagment section, then it doesn’t need to be specified in the normal plugins
+section. However, it should additionally be specified in the reporting section.
This will add an entry to the ‘project reports’ section with the PMD report when you build the maven site.
+
+
Executing PMD manually
+
+
To run PMD on a Maven project without adding it as a report, simply run
+
+
mvn pmd:pmd
+
+
+
The PMD plugin writes the report in XML which will then be formatted into more readable HTML.
+
+
Integrated into the build process
+
+
You can also run PMD automatically when building your project. You even let the build fail, if
+PMD finds some violations. Therefore the check goal is used:
+
+
<project>
+ ...
+ <build>
+ <plugins>
+ <plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-pmd-plugin</artifactId>
+ <version>3.13.0</version><!-- or use version from pluginManagement -->
+ <configuration>
+ <!-- failOnViolation is actually true by default, but can be disabled -->
+ <failOnViolation>true</failOnViolation>
+ <!-- printFailingErrors is pretty useful -->
+ <printFailingErrors>true</printFailingErrors>
+ </configuration>
+ <executions>
+ <execution>
+ <goals>
+ <goal>check</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
+ </plugins>
+ </build>
+ ...
+</project>
+
+
+
This will run PMD automatically during the verify phase of the build. You can additionally run CPD, if
+you add cpd-check as a goal.
+
+
Customization
+
+
Changing rulesets
+
+
To specify a ruleset, simply edit the previous configuration:
The value of the ‘ruleset’ element can either be a relative address, an absolute address or even an url.
+
+
A clean strategy for customizing which rules to use for a project is to write a ruleset file.
+In this file you can define which rules to use, add custom rules, and
+customizing which rules to include/exclude from official rulesets. More information on
+writing a ruleset can be found here.
+Note that if you include other rulesets in your own rulesets, you have to be sure that the plugin
+will be able to resolve those other ruleset references.
+
+
Enabling Incremental Analysis
+
+
When using the Maven PMD plugin 3.8 or later along with PMD 5.6.0 or later, you can enable incremental analysis to
+speed up PMD’s execution while retaining the quality of the analysis. You can additionally customize where the cache is stored::
+
+
<plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-pmd-plugin</artifactId>
+ <version>3.13.0</version><!-- or use version from pluginManagement -->
+ <configuration>
+ <!-- enable incremental analysis -->
+ <analysisCache>true</analysisCache>
+ <!-- analysisCacheLocation: optional - points to the following location by default -->
+ <analysisCacheLocation>${project.build.directory}/pmd/pmd.cache</analysisCacheLocation>
+ </configuration>
+ </plugin>
+
+
+
Other configurations
+
+
The Maven PMD plugin allows you to configure CPD, targetJDK, and the use of XRef to link
+the report to html source files, and the file encoding:
+
+
<plugin>
+ <groupId>org.apache.maven.plugins</groupId>
+ <artifactId>maven-pmd-plugin</artifactId>
+ <version>3.13.0</version><!-- or use version from pluginManagement -->
+ <configuration>
+ <linkXRef>true</linkXRef>
+ <sourceEncoding>ISO-8859-1</sourceEncoding>
+ <minimumTokens>30</minimumTokens>
+ <targetJdk>1.4</targetJdk>
+ </configuration>
+ </plugin>
+
+
+
Upgrading the PMD version at runtime
+
+
The Maven PMD plugin comes with a specific PMD version, which is documented on the
+plugin project page.
+
+
Given that the newer PMD version is compatible, you can override the PMD version, that the
+Maven plugin will use and benefit from the latest bugfixes and enhancements:
Warning: Apache Maven 1.x has reached its end of life, and is no longer supported. For more information, see the announcement. Users are encouraged to migrate to the current version of Apache Maven.
+
+
This section is about the maven 1 PMD plugin.
+
+
Running the pmd plugin
+
+
Generating a project report
+
+
To include the PMD report in the project reports section add the following line under
+the reports element in your project.xml:
+
+
<report>maven-pmd-plugin</report>
+
+
+
This will add an entry to the ‘project reports’ section with the PMD report.
+
+
Executing PMD manually
+
+
To run PMD on a Maven project without adding it as a report, simply run
+
+
maven pmd xdoc
+
+
+
The PMD plugin writes the report in XML which will then be formatted into more readable HTML.
+
+
Customization
+
+
Changing rulesets
+
+
To specify a set of official, built-in rulesets to be used set them in the property
+maven.pmd.rulesets. You can include this setting in your project.properties file.
+
+
A clean strategy for customizing which rules to use for a project is to write a ruleset file.
+In this file you can define which rules to use, add custom rules, and
+customizing which rules to include/exclude from official rulesets. More information on
+writing a ruleset can be found here.
+
+
Add to the root of your Maven project a pmd.xml file which contains the ruleset mentioned in
+the previous paragraph. Add the following property to your project now:
net.sourceforge.pmd.PMDException: Error while parsing pmd-core/src/test/resources/net/sourceforge/pmd/cpd/files/file_with_ISO-8859-1_encoding.java
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCodeWithoutCache(SourceCodeProcessor.java:110)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCode(SourceCodeProcessor.java:89)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCode(SourceCodeProcessor.java:51)
+ at net.sourceforge.pmd.processor.PmdRunnable.call(PmdRunnable.java:78)
+ at net.sourceforge.pmd.processor.PmdRunnable.call(PmdRunnable.java:24)
+ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
+ at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
+ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
+ at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
+ at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
+ at java.base/java.lang.Thread.run(Thread.java:832)
+Caused by: net.sourceforge.pmd.lang.java.ast.ParseException: Encountered " "-" "- "" at line 6, column 30.
+Was expecting one of:
+ "extends" ...
+ "implements" ...
+ "{" ...
+ "<" ...
+
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.generateParseException(JavaParser.java:12713)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.jj_consume_token(JavaParser.java:12597)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.ClassOrInterfaceBody(JavaParser.java:1554)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.ClassOrInterfaceDeclaration(JavaParser.java:732)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.TypeDeclaration(JavaParser.java:639)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.CompilationUnit(JavaParser.java:373)
+ at net.sourceforge.pmd.lang.java.AbstractJavaParser.parse(AbstractJavaParser.java:62)
+ at net.sourceforge.pmd.SourceCodeProcessor.parse(SourceCodeProcessor.java:121)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSource(SourceCodeProcessor.java:185)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCodeWithoutCache(SourceCodeProcessor.java:107)
+ ... 10 more
+
+ Back to top
+
+
+
\ No newline at end of file
diff --git a/report-examples/pmd-report-summaryhtml.html b/report-examples/pmd-report-summaryhtml.html
new file mode 100644
index 0000000000..92dc3e1f72
--- /dev/null
+++ b/report-examples/pmd-report-summaryhtml.html
@@ -0,0 +1,74 @@
+PMD
+
net.sourceforge.pmd.PMDException: Error while parsing pmd-core/src/test/resources/net/sourceforge/pmd/cpd/files/file_with_ISO-8859-1_encoding.java
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCodeWithoutCache(SourceCodeProcessor.java:110)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCode(SourceCodeProcessor.java:89)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCode(SourceCodeProcessor.java:51)
+ at net.sourceforge.pmd.processor.PmdRunnable.call(PmdRunnable.java:78)
+ at net.sourceforge.pmd.processor.PmdRunnable.call(PmdRunnable.java:1)
+ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
+ at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
+ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
+ at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
+ at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
+ at java.base/java.lang.Thread.run(Thread.java:834)
+Caused by: net.sourceforge.pmd.lang.java.ast.ParseException: Encountered " "-" "- "" at line 6, column 30.
+Was expecting one of:
+ "extends" ...
+ "implements" ...
+ "{" ...
+ "<" ...
+
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.generateParseException(JavaParser.java:12731)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.jj_consume_token(JavaParser.java:12615)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.ClassOrInterfaceBody(JavaParser.java:1574)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.ClassOrInterfaceDeclaration(JavaParser.java:779)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.TypeDeclaration(JavaParser.java:686)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.CompilationUnit(JavaParser.java:420)
+ at net.sourceforge.pmd.lang.java.AbstractJavaParser.parse(AbstractJavaParser.java:62)
+ at net.sourceforge.pmd.SourceCodeProcessor.parse(SourceCodeProcessor.java:121)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSource(SourceCodeProcessor.java:185)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCodeWithoutCache(SourceCodeProcessor.java:107)
+ ... 10 more
+
\ No newline at end of file
diff --git a/report-examples/pmd-report-vbhtml.html b/report-examples/pmd-report-vbhtml.html
new file mode 100644
index 0000000000..f6ce69c610
--- /dev/null
+++ b/report-examples/pmd-report-vbhtml.html
@@ -0,0 +1,42 @@
+PMD
net.sourceforge.pmd.PMDException: Error while parsing /home/pmd/source/pmd-core/src/test/resources/net/sourceforge/pmd/cpd/files/file_with_ISO-8859-1_encoding.java
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCodeWithoutCache(SourceCodeProcessor.java:110)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCode(SourceCodeProcessor.java:89)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCode(SourceCodeProcessor.java:51)
+ at net.sourceforge.pmd.processor.PmdRunnable.call(PmdRunnable.java:78)
+ at net.sourceforge.pmd.processor.PmdRunnable.call(PmdRunnable.java:24)
+ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
+ at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
+ at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
+ at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
+ at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
+ at java.base/java.lang.Thread.run(Thread.java:832)
+Caused by: net.sourceforge.pmd.lang.java.ast.ParseException: Encountered " "-" "- "" at line 6, column 30.
+Was expecting one of:
+ "extends" ...
+ "implements" ...
+ "{" ...
+ "<" ...
+
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.generateParseException(JavaParser.java:12713)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.jj_consume_token(JavaParser.java:12597)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.ClassOrInterfaceBody(JavaParser.java:1554)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.ClassOrInterfaceDeclaration(JavaParser.java:732)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.TypeDeclaration(JavaParser.java:639)
+ at net.sourceforge.pmd.lang.java.ast.JavaParser.CompilationUnit(JavaParser.java:373)
+ at net.sourceforge.pmd.lang.java.AbstractJavaParser.parse(AbstractJavaParser.java:62)
+ at net.sourceforge.pmd.SourceCodeProcessor.parse(SourceCodeProcessor.java:121)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSource(SourceCodeProcessor.java:185)
+ at net.sourceforge.pmd.SourceCodeProcessor.processSourceCodeWithoutCache(SourceCodeProcessor.java:107)
+ ... 10 more
+
PMD's Java module has an extensive framework for the calculation of metrics, which allows rule developers to implement and use new code metrics very simply. ...
Note: TODO add IDE specific indications Compiling PMD JDK 11 or higher Note: While Java 11 is required for building, running PMD only requires Java 7 (or Java 8 for Apex...
The next version of PMD will be developed in parallel with this release. We will release additional bugfix versions as needed. Source Code The complete source code can be found on github: github.com/pmd/pmd - main PMD repository. Includes all the code to support all languages, including this...
Introduction Pmdtester is a regression testing tool that ensures no new problems and unexpected behaviors will be introduced to PMD after fixing an issue. It can also be used to verify, that new rules work as expected. It has been integrated into travis CI and is actually used automatically...
TODO: Update Future direction projects, plans Google Summer of Code Future directions Want to know what’s coming? Or, better, wanna contribute ? Here is the page listing what are our plans - when we have ones, for the future of PMD. It also give you hints at...
PMD's documentation uses [Jekyll](https://jekyllrb.com/) with the [I'd rather be writing Jekyll Theme](http://idratherbewriting.com/documentation-theme-jekyll/index.html). Here are some quick tips. ## Format The pages are in general in [Github Flavored Markdown](https://kramdown.gettalong.org/parser/gfm.html). ## Structure The documentation sources can be found in two places based on how they are generated: - the ones that are...
PMD's Java module has an extensive framework for the calculation of metrics, which allows rule developers to implement and use new code metrics very simply. ...
Since version 6.0.0, PMD is enhanced with the ability to compute code metrics on Java and Apex source (the so-called Metrics Framework). This framework provi...
The information on this page has been split into several separate pages. Please update your bookmarks: * [Introduction to writing rules](pmd_userdocs_extending_writing_rules_intro.html) * [Your First Rule](pmd_userdocs_extending_your_first_rule.html) introduces the basic development process of a rule with a running example * [Writing XPath Rules](pmd_userdocs_extending_writing_xpath_rules.html) explains a bit more about XPath rules and our...
A ruleset is an XML configuration file, which describes a collection of rules to be executed in a PMD run. PMD includes built-in rulesets to run quick analys...
PMD's Java module has an extensive framework for the calculation of metrics, which allows rule developers to implement and use new code metrics very simply. ...
Since version 6.0.0, PMD is enhanced with the ability to compute code metrics on Java and Apex source (the so-called Metrics Framework). This framework provi...
PMD Description Runs a set of static code analysis rules on some source code files and generates a list of problems found. Installation Before you can use the pmd task in your ant build.xml file, you need to install PMD and its libraries...
Introduction PMD can be integrate through some of the Continuous Integration tools that exist now. Here is a list of known (to us) plugin to do so. Hudson Plugin Hafner Ullrich has developed a PMD plugin for Hudson. Please check the plugin homepage for more info. <h2...
The Gradle Build Tool provides a PMD Plugin that can be added to your build configuration. Technically it is based on the Ant Task. Example In your build.gradle add the following: plugins { id 'pmd' } Custom ruleset...
The easiest way to run PMD is to just use a build plugin in your favorite build tool like Apache Ant, Apache Maven or Gradle. There are also many integrations for IDEs available, see Tools. If you have your own build tool or want to integrate...
Maven 2 and 3 Running the pmd plugin Choosing the plugin version When adding the maven-pmd-plugin to your pom.xml, you need to select a version. To figure out the latest available version, have a look at the official maven-pmd-plugin documentation. As of March 2020, the current...
## Automated Code Review ### Codacy [Codacy](https://www.codacy.com/) automates code reviews and monitors code quality on every commit and pull request. It gives visibility into the technical debt and it can track code style and security issues, code coverage, code duplication, cyclomatic complexity and enforce best practices. Codacy is static analysis...
PMD Description Runs a set of static code analysis rules on some source code files and generates a list of problems found. Installation Before you can use the pmd task in your ant build.xml file, you need to install PMD and its libraries...
Choose the rules that are right for you Running every existing rule will result in a huge number of rule violations, most of which will be unimportant. Having to sort through a thousand line report to find the few you’re really interested in takes all the fun out of...
Introduction PMD can be integrate through some of the Continuous Integration tools that exist now. Here is a list of known (to us) plugin to do so. Hudson Plugin Hafner Ullrich has developed a PMD plugin for Hudson. Please check the plugin homepage for more info. <h2...
The Gradle Build Tool provides a PMD Plugin that can be added to your build configuration. Technically it is based on the Ant Task. Example In your build.gradle add the following: plugins { id 'pmd' } Custom ruleset...
The easiest way to run PMD is to just use a build plugin in your favorite build tool like Apache Ant, Apache Maven or Gradle. There are also many integrations for IDEs available, see Tools. If you have your own build tool or want to integrate...
A ruleset is an XML configuration file, which describes a collection of rules to be executed in a PMD run. PMD includes built-in rulesets to run quick analys...
Maven 2 and 3 Running the pmd plugin Choosing the plugin version When adding the maven-pmd-plugin to your pom.xml, you need to select a version. To figure out the latest available version, have a look at the official maven-pmd-plugin documentation. As of March 2020, the current...
Since version 6.0.0, PMD is enhanced with the ability to compute code metrics on Java and Apex source (the so-called Metrics Framework). This framework provi...
## Automated Code Review ### Codacy [Codacy](https://www.codacy.com/) automates code reviews and monitors code quality on every commit and pull request. It gives visibility into the technical debt and it can track code style and security issues, code coverage, code duplication, cyclomatic complexity and enforce best practices. Codacy is static analysis...
The information on this page has been split into several separate pages. Please update your bookmarks: * [Introduction to writing rules](pmd_userdocs_extending_writing_rules_intro.html) * [Your First Rule](pmd_userdocs_extending_your_first_rule.html) introduces the basic development process of a rule with a running example * [Writing XPath Rules](pmd_userdocs_extending_writing_xpath_rules.html) explains a bit more about XPath rules and our...
This page is purposely separated out from the rest of theme so you can see the bare minimum code to add to a page, without all the other theme's code getting in the way.
+
+
Content in the tooltips (actually "popovers" according to Bootstrap lingo) can be pulled in dynamically by placing the JSON file on a remote host.
+
+
Note: Make sure you view the file source so you can read the notes I've added in code comments.
+
+
+
+
Basketball
+
+
Baseball
+
+
Football
+
+
Soccer
+
diff --git a/tooltips.json b/tooltips.json
new file mode 100644
index 0000000000..73773c9ef3
--- /dev/null
+++ b/tooltips.json
@@ -0,0 +1,29 @@
+{
+"entries":
+[
+
+{
+"doc_id": "baseball",
+"body": "Baseball is considered America's pasttime sport, though that may be more of a historical term than a current one. There's a lot more excitement about football than baseball. A baseball game is somewhat of a snooze to watch, for the most part."
+} ,
+
+{
+"doc_id": "basketball",
+"body": "Basketball is a sport involving two teams of five players each competing to put a ball through a small circular rim 10 feet above the ground. Basketball requires players to be in top physical condition, since they spend most of the game running back and forth along a 94-foot-long floor."
+} ,
+
+{
+"doc_id": "football",
+"body": "No doubt the most fun sport to watch, football also manages to accrue the most injuries with the players. From concussions to blown knees, football players have short sport lives."
+} ,
+
+{
+"doc_id": "soccer",
+"body": "If there's one sport that dominates the world landscape, it's soccer. However, US soccer fans are few and far between. Apart from the popularity of soccer during the World Cup, most people don't even know the name of the professional soccer organization in their area."
+}
+
+]
+}
+
+
+
