policeman-tools / forbidden-apis

Policeman's Forbidden API Checker

Policeman's Forbidden API Checker

Allows to parse Java byte code to find invocations of method/class/field signatures and fail build (Apache Ant, Apache Maven, or Gradle).

Documentation

Please refer to the Github Wiki & Documentation.

The checker is available as Apache Ant Task, Apache Maven Mojo, and Gradle plugin. In addition there is a command line tool (CLI):

• Apache Ant
• Apache Maven
• Gradle
• Command Line

This project uses Apache Ant (and Apache Ivy) to build. The minimum Ant version is 1.8.0 and it is recommended to not have Apache Ivy in the Ant lib folder, because the build script will download the correct version of Ivy automatically.

Project Resources

• Github Homepage
• Blog Post
• Jenkins CI
• Open HUB

forbidden-apis's Issues

Change default phase to verify

checkstyle, pmd, findbugs and similar Maven plugins run by default in the 
verify phase; forbidden-apis is similar so it should run in the same phase.


"verify - run any checks to verify the package is valid and meets quality 
criteria"
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html


This can be accomplished by:

@Mojo(name = "check" ... defaultPhase = LifecyclePhase.VERIFY)

Original issue reported on code.google.com by [email protected] on 6 Aug 2014 at 11:38

Make it easier to scan dependencies

Currently its difficult to scan dependencies (at least with the maven plugin).

It would be nice to be able to do this, to keep dependencies "in check".

For it to really work nice, I think we should also support excludesFile (and 
maybe nuke/deprecate existing excludes mechanism), so that exception lists are 
nice commented .txt files like the signatures files. 

Or instead of separate files, maybe exceptions could be inlined into the 
signature files (this would really be the best from a maintenance standpoint, 
but wierd to the current logic I know).

A good use case is being able to keep an audit of super-dangerous apis like 
Unsafe, so there are no surprises when you add/upgrade dependencies.

Original issue reported on code.google.com by [email protected] on 20 Oct 2014 at 11:58

Allow signatures to be loaded as Maven artifacts

In issue #10 it was shown that its possible to release "signature" artifacts as 
Maven packages. You could then add a dependency to the Maven plugin section of 
your POM and load the signaures JAR file into the plugin's classpath. Those 
signatures would then be available by the "bundled-signatures" config setting.

The only problem is the package name: All those Maven artifacts need to have 
the signatures in the de.thetaphi.forbiddenapis package, which violates general 
Maven bundling, which should have package names named by the released product 
(see also OSGI).

Instead the signatures should be moved into the META-INF/ folder of the JAR, so 
its universal. An addon signature artifact would then be a JAR file with only a 
META-INF/ resource folder.

Original issue reported on code.google.com by uwe.h.schindler on 11 Oct 2013 at 3:53

Allow skipping signature checks in deprecated code

In some cases it is not possible to eliminate code that is using forbidden APIs 
immediately, e.g. because a forbidden class or interface is used in a method 
signature, but that method can only be removed in the next major release of the 
project. In that case one would deprecate the offending method. To support 
this, forbidden-apis should have an option to skip checks in deprecated code.

Original issue reported on code.google.com by [email protected] on 8 Dec 2014 at 6:41

• Merged into: #34

Attachments:

• 0001-Support-skipping-checks-in-deprecated-methods.patch

Skip execution for Maven projects with packaging "pom"

I'm using the plugin in a multi-module Maven project. To apply it consistently 
to all modules, I configure it in the root/parent POM. However, this causes a 
problem because in this setup, the plugin is also executed when the root 
project itself is build. I think that the easiest way to avoid this is to 
automatically skip execution of the plugin in Maven projects with packaging 
"pom". Since these projects never have sources, there is no point in executing 
the plugin anyway.

I've attached a patch that modifies AbstractCheckMojo in the suggested way.

Original issue reported on code.google.com by [email protected] on 18 Sep 2013 at 10:41

Attachments:

• skip-pom-packaging.patch

Upgrade to ASM 5.0 BETA

The hack needed to make Java 8 class files readable can be removed by using 
that version.

This also solves issue #16, because we don't need to modify the deprecated 
signature file generator.

Original issue reported on code.google.com by uwe.h.schindler on 7 Nov 2013 at 10:56

Could not find goal 'check' in plugin de.thetaphi:forbiddenapis:1.3

[INFO] Building Lucene parent POM 4.5.1
[INFO] ------------------------------------------------------------------------
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Skipping Grandparent POM for Apache Lucene Core and Apache Solr
[INFO] This project has been banned from the build due to previous failures.
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] Grandparent POM for Apache Lucene Core and Apache Solr  SUCCESS [4.024s]
[INFO] Lucene parent POM ................................. FAILURE [0.004s]
[INFO] Lucene Core ....................................... SKIPPED
[INFO] Lucene codecs ..................................... SKIPPED
[INFO] Lucene Common Analyzers ........................... SKIPPED
[INFO] Lucene ICU Analysis Components .................... SKIPPED
[INFO] Lucene Kuromoji Japanese Morphological Analyzer ... SKIPPED
[INFO] Lucene Morfologik Polish Lemmatizer ............... SKIPPED
[INFO] Lucene Phonetic Filters ........................... SKIPPED
[INFO] Lucene Smart Chinese Analyzer ..................... SKIPPED
[INFO] Lucene Stempel Analyzer ........................... SKIPPED
[INFO] Lucene Analysis Modules aggregator POM ............ SKIPPED
[INFO] Lucene Memory ..................................... SKIPPED
[INFO] Lucene Queries .................................... SKIPPED
[INFO] Lucene Highlighter ................................ SKIPPED
[INFO] Lucene Sandbox .................................... SKIPPED
[INFO] Lucene QueryParsers ............................... SKIPPED
[INFO] Lucene Facets ..................................... SKIPPED
[INFO] Lucene Benchmark .................................. SKIPPED
[INFO] Lucene Classification ............................. SKIPPED
[INFO] Lucene Demo ....................................... SKIPPED
[INFO] Lucene Grouping ................................... SKIPPED
[INFO] Lucene Join ....................................... SKIPPED
[INFO] Lucene Miscellaneous .............................. SKIPPED
[INFO] Lucene Replicator ................................. SKIPPED
[INFO] Lucene Spatial .................................... SKIPPED
[INFO] Lucene Suggest .................................... SKIPPED
[INFO] Apache Solr parent POM ............................ SKIPPED
[INFO] Apache Solr Solrj ................................. SKIPPED
[INFO] Apache Solr Core .................................. SKIPPED
[INFO] Apache Solr Search Server ......................... SKIPPED
[INFO] Apache Solr Analysis Extras ....................... SKIPPED
[INFO] Apache Solr DataImportHandler ..................... SKIPPED
[INFO] Apache Solr DataImportHandler Extras .............. SKIPPED
[INFO] Apache Solr Content Extraction Library ............ SKIPPED
[INFO] Apache Solr Velocity .............................. SKIPPED
[INFO] Apache Solr Contrib aggregator POM ................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7.153s
[INFO] Finished at: Mon Oct 28 19:23:40 CET 2013
[INFO] Final Memory: 105M/350M
[INFO] ------------------------------------------------------------------------
[ERROR] Could not find goal 'check' in plugin de.thetaphi:forbiddenapis:1.3 
among available goals -> [Help 1]


What version of the product are you using? On what operating system?
Apache Maven 3.0.5 (rNON-CANONICAL_2013-03-12_12-47_mockbuild; 2013-03-12 
13:47:10+0100)
Maven home: /usr/share/maven
Java version: 1.7.0_45, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.3.0.fc19.i386/jre
Default locale: it_IT, platform encoding: UTF-8
OS name: "linux", version: "3.11.6-200.fc19.i686", arch: "i386", family: "unix"
Please provide any additional information below.
[INFO] ------------------------------------------------------------------------
[INFO] Building Lucene parent POM 4.5.1
[INFO] ------------------------------------------------------------------------
[DEBUG] Lifecycle default -> [validate, initialize, generate-sources, 
process-sources, generate-resources, process-resources, compile, 
process-classes, generate-test-sources, process-test-sources, 
generate-test-resources, process-test-resources, test-compile, 
process-test-classes, test, prepare-package, package, pre-integration-test, 
integration-test, post-integration-test, verify, install, deploy]
[DEBUG] Lifecycle clean -> [pre-clean, clean, post-clean]
[DEBUG] Lifecycle site -> [pre-site, site, post-site, site-deploy]
[DEBUG] Trying to resolve artifact [de.thetaphi:forbiddenapis:1.3:pom]
[DEBUG] Trying to translate artifact [de.thetaphi:forbiddenapis]
[DEBUG] Artifact [de.thetaphi:forbiddenapis] was mapped to [JPP:forbiddenapis]
[DEBUG] Translation result is [ [JPP:forbiddenapis], 
[de.thetaphi:forbiddenapis] ]
[DEBUG] Resolving [de.thetaphi:forbiddenapis:1.3:pom]
[DEBUG] Trying to translate artifact [de.thetaphi:forbiddenapis]
[DEBUG] Artifact [de.thetaphi:forbiddenapis] was mapped to [JPP:forbiddenapis]
[DEBUG] Translation result is [ [JPP:forbiddenapis], 
[de.thetaphi:forbiddenapis] ]
[DEBUG] Artifact [de.thetaphi:forbiddenapis:1.3:pom] was resolved to 
/usr/share/maven-effective-poms/JPP-forbiddenapis.pom
[DEBUG] Trying to resolve artifact [de.thetaphi:forbiddenapis:1.3:jar]
[DEBUG] Trying to translate artifact [de.thetaphi:forbiddenapis]
[DEBUG] Artifact [de.thetaphi:forbiddenapis] was mapped to [JPP:forbiddenapis]
[DEBUG] Translation result is [ [JPP:forbiddenapis], 
[de.thetaphi:forbiddenapis] ]
[DEBUG] Resolving [de.thetaphi:forbiddenapis:1.3:jar]
[DEBUG] Trying to translate artifact [de.thetaphi:forbiddenapis]
[DEBUG] Artifact [de.thetaphi:forbiddenapis] was mapped to [JPP:forbiddenapis]
[DEBUG] Translation result is [ [JPP:forbiddenapis], 
[de.thetaphi:forbiddenapis] ]
[DEBUG] Artifact [de.thetaphi:forbiddenapis:1.3:jar] was resolved to 
/usr/share/java/forbiddenapis.jar
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Skipping Grandparent POM for Apache Lucene Core and Apache Solr
[INFO] This project has been banned from the build due to previous failures.
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] Grandparent POM for Apache Lucene Core and Apache Solr  SUCCESS [3.599s]
[INFO] Lucene parent POM ................................. FAILURE [0.005s]
[INFO] Lucene Core ....................................... SKIPPED
[INFO] Lucene codecs ..................................... SKIPPED
[INFO] Lucene Common Analyzers ........................... SKIPPED
[INFO] Lucene ICU Analysis Components .................... SKIPPED
[INFO] Lucene Kuromoji Japanese Morphological Analyzer ... SKIPPED
[INFO] Lucene Morfologik Polish Lemmatizer ............... SKIPPED
[INFO] Lucene Phonetic Filters ........................... SKIPPED
[INFO] Lucene Smart Chinese Analyzer ..................... SKIPPED
[INFO] Lucene Stempel Analyzer ........................... SKIPPED
[INFO] Lucene Analysis Modules aggregator POM ............ SKIPPED
[INFO] Lucene Memory ..................................... SKIPPED
[INFO] Lucene Queries .................................... SKIPPED
[INFO] Lucene Highlighter ................................ SKIPPED
[INFO] Lucene Sandbox .................................... SKIPPED
[INFO] Lucene QueryParsers ............................... SKIPPED
[INFO] Lucene Facets ..................................... SKIPPED
[INFO] Lucene Benchmark .................................. SKIPPED
[INFO] Lucene Classification ............................. SKIPPED
[INFO] Lucene Demo ....................................... SKIPPED
[INFO] Lucene Grouping ................................... SKIPPED
[INFO] Lucene Join ....................................... SKIPPED
[INFO] Lucene Miscellaneous .............................. SKIPPED
[INFO] Lucene Replicator ................................. SKIPPED
[INFO] Lucene Spatial .................................... SKIPPED
[INFO] Lucene Suggest .................................... SKIPPED
[INFO] Apache Solr parent POM ............................ SKIPPED
[INFO] Apache Solr Solrj ................................. SKIPPED
[INFO] Apache Solr Core .................................. SKIPPED
[INFO] Apache Solr Search Server ......................... SKIPPED
[INFO] Apache Solr Analysis Extras ....................... SKIPPED
[INFO] Apache Solr DataImportHandler ..................... SKIPPED
[INFO] Apache Solr DataImportHandler Extras .............. SKIPPED
[INFO] Apache Solr Content Extraction Library ............ SKIPPED
[INFO] Apache Solr Velocity .............................. SKIPPED
[INFO] Apache Solr Contrib aggregator POM ................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.893s
[INFO] Finished at: Mon Oct 28 19:26:34 CET 2013
[INFO] Final Memory: 63M/275M
[INFO] ------------------------------------------------------------------------
[ERROR] Could not find goal 'check' in plugin de.thetaphi:forbiddenapis:1.3 
among available goals -> [Help 1]
org.apache.maven.plugin.MojoNotFoundException: Could not find goal 'check' in 
plugin de.thetaphi:forbiddenapis:1.3 among available goals 
        at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getMojoDescriptor(DefaultMavenPluginManager.java:267)
        at org.apache.maven.plugin.DefaultBuildPluginManager.getMojoDescriptor(DefaultBuildPluginManager.java:185)
        at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateLifecycleMappings(DefaultLifecycleExecutionPlanCalculator.java:280)
        at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateMojoExecutions(DefaultLifecycleExecutionPlanCalculator.java:193)
        at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:112)
        at org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:129)
        at org.apache.maven.lifecycle.internal.BuilderCommon.resolveBuildPlan(BuilderCommon.java:92)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
[ERROR] 
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoNotFoundException

hi
any ideas?
thanks in advance
regards

Original issue reported on code.google.com by [email protected] on 28 Oct 2013 at 6:29

Add additional way to exclude code parts using annotations

This issue will implement a new mechanism to exclude specific classes or (this 
is new!) specific methods or parts of methods from being checked with 
ForbiddenAPIs.

The idea here is to use an annotation, that must have at least 
RetentionPolicy.CLASS or RetentionPolicy.RUNTIME. ForbiddenAPIs will not 
provide such an annotation, it can simply configured to look for any annotation 
type(s), configured as a list of Class parameters.

This allows to run forbidden-apis with ant like:

<forbiddenapis supressAnnotations="org.foo.bar.SuppressForbidden" .../>

(same in maven as a list of class properties).

You have to define the custom annotation (or multiples) as part of your own 
project, so we get no external dependencies. You can also misuse another 
annotation (LOL). The annotation must just be of RetentionPolicy.CLASS or 
RetentionPolicy.RUNTIME. It does not need to be documented. Just SOURCE-only 
annotations won't work (because no longer visible in class files).

You can then annotate classes with this annotation (which does the same like 
excluding the class file using the excludes="...." Ant/Maven config settings) 
or go down to methods or code lines. In fact depending on the type of your 
annotation, you can use it like SuppressWarnings. So annotate any method, code 
line, or parameter [not yet decided if this makes sense] you want t exclude 
from checking (or in Java 8 also types).

Forbidden-APIs will add an "example/default annotation" in its own JAR file, 
but you are not required to use it (especially if you don't want to have a 
compile-time dependency to forbiddenapis).

Original issue reported on code.google.com by uwe.h.schindler on 14 Sep 2014 at 5:08

Improve the Maven Mojo documentation

Currently no HTML pages with the Mojo documentation are generated.

This issue will add the help mojo (forbiddenapis:help), but also generate some 
documentation pages using the xdocs generated from the maven-plugin-plugin.

The work is ongoing, this is just a placeholder issue for many commits.

Original issue reported on code.google.com by uwe.h.schindler on 8 Aug 2014 at 12:49

Fix lookup of class references in checkType() / checkDescriptor to also inspect superclasses and interfaces

When adding support for Java 8 and invokeDynamic, there was still a TODO about 
checking supertypes and interfaces when looking at stuff like casts, array 
creation, annotation checks.

This should be fixed, to use the same semantics like for method calls.

Original issue reported on code.google.com by uwe.h.schindler on 16 Apr 2014 at 1:47

Support Java 8 class files

Currently the checker prints a warning (or fails the build), if you use Java 8 
to verify your classes. The problem is: It must read class files from rt.jar, 
which are in Java 8 format.

ASM 5.0 is not yet released, but the file format did not change at all (they 
just added new code attributes). So ASM 4.x could read the classes, but it 
checks the version header. The idea here is to patch the class if it is in 
version 52 (Java 8). It would just downgrade the signature to version 51.

The checker would still not support Java 8 "officially", but will not fail to 
work. No signature files for Java 8 will be provided until Java 8 is officially 
released.

Original issue reported on code.google.com by uwe.h.schindler on 27 Apr 2013 at 4:53

Sort error messages by line number

Currently error messages are reported in the order they appear in byte code. 
Unfortunaetly with synthetic methods like used for closures or access$X stuff, 
the methods may come later in byte code, so those synthetics are listed after 
other failures, although line number is lower.

The fix would be to buffer the error messages and sort them by line number 
before output. This would also allow to make them accessible in a more 
structured way from code.

Original issue reported on code.google.com by uwe.h.schindler on 27 Sep 2013 at 9:24

Dont fail if class mentioned in signatures dont exist

Hey there,

this can be completely closed as invalid. I just stumbled over a problem, when 
starting a new project that used an existing signatures file. This file 
included signatures from classes that were not referenced as dependency in the 
new project. Therefore the build failed (using mvn).

Bug or feature? You decide :-)

Maybe printing a warning message is sufficient then?

Original issue reported on code.google.com by [email protected] on 8 Aug 2014 at 10:56

• Merged into: #14

Apple-provided JDK 1.6 on MacOSX is not supported

The directory layout of the original Apple JDK shipped with MacOSX is totally 
different that the layout we know from all other operating systems (and Sun's 
Java 7 for Mac).

Because of this the detection of the Java Lib path / rt.jar for some checks 
does not work and the JDK version is reported as unsupported.

Original issue reported on code.google.com by uwe.h.schindler on 12 Feb 2013 at 10:08

some missing java5 signatures

Index: 
src/main/resources/de/thetaphi/forbiddenapis/signatures/jdk-unsafe-1.5.txt
===================================================================
--- 
src/main/resources/de/thetaphi/forbiddenapis/signatures/jdk-unsafe-1.5.txt  (revi
sion 232)
+++ 
src/main/resources/de/thetaphi/forbiddenapis/signatures/jdk-unsafe-1.5.txt  (work
ing copy)
@@ -46,6 +46,8 @@
 java.lang.String#toLowerCase()
 java.lang.String#toUpperCase()
 java.lang.String#format(java.lang.String,java.lang.Object[])
+java.io.PrintStream#format(java.lang.String,java.lang.Object[])
+java.io.PrintStream#printf(java.lang.String,java.lang.Object[])
 java.io.PrintWriter#format(java.lang.String,java.lang.Object[])
 java.io.PrintWriter#printf(java.lang.String,java.lang.Object[])
 java.nio.charset.Charset#displayName()
@@ -82,6 +84,12 @@
 java.util.Formatter#<init>(java.io.PrintStream)
 java.util.Formatter#<init>(java.lang.String)
 java.util.Formatter#<init>(java.lang.String,java.lang.String)
+java.util.Locale#getDisplayCountry()
+java.util.Locale#getDisplayLanguage()
+java.util.Locale#getDisplayName()
+java.util.Locale#getDisplayVariant()
+java.util.TimeZone#getDisplayName()
+java.util.TimeZone#getDisplayName(boolean,int)

 @defaultMessage Uses default locale or time zone
 java.util.Calendar#<init>()

Original issue reported on code.google.com by [email protected] on 25 Dec 2013 at 7:49

Forbidden class use does not work in field declarations and method declarations

If you use a forbidden class (the whole class is forbidden, not a single 
method/field) in a field declaration or method declaration, this is not 
reported.
In most cases the error is still detected, because at some point the field has 
to be initialized or the method needs to be called, but we should detect this 
failure.
This is linked to issue #8, because the same code used here is also used to 
detect the annotations used.

Original issue reported on code.google.com by uwe.h.schindler on 15 Apr 2014 at 10:18

Review changes caused by JIGSAW packaging and fix class loading and class traversal issues

See http://openjdk.java.net/jeps/220

In future, the bootclasspath of Java will no longer be rt.jar and the URLs 
returned by Class.getResource() will no longer be "jar:" URLs. We have to fix 
the code that does classpath traversal to respect this.

This also affects the code that creates the deprecated lists from rt.jar.

It is currently unknown if there will be a good way to enumerate all class 
files in a classpath...

Original issue reported on code.google.com by uwe.h.schindler on 31 Oct 2014 at 9:19

Enhance the target parameter to also support testTarget like maven-compiler-plugin

The maven-compiler-plugin allows the config setting "testTarget", too. If it is 
empty, it falls back to "target".

forbidden should do the same, so also the system property is respected.

Original issue reported on code.google.com by uwe.h.schindler on 25 Oct 2013 at 9:10

Bring better error message if compiler target is not set in Maven

People get a error message that bundled signatures are not found. This is mostly caused by the fact that they forgt ot define the compiler target, so forbiddenapis cannot choose the right version of unsafe or deprecated signatures.

We should add a warning just before the bundled signatures are loaded, so they get the info that they hshould really define the compiler target (ideally through Maven property globally, so it applies also to compiler plugin).

Only print warning if Ant fileset of classes to scan is empty (like Maven)

If no classes are in the given fileset, the Ant task should simply print a 
warning instead of failing the build.

This allows multi-module builds to succeed that share one forbidden-apis target.

Original issue reported on code.google.com by uwe.h.schindler on 14 Sep 2014 at 7:56

Add documentation for Ant task

There is no automatic way to create documentation for an Ant task from javadocs 
(at least none that can be used from Maven Central).

This task should be used to provide a HTML file like Ant's own documentation 
(in same format). It must be updated manually, unfortunately.

Original issue reported on code.google.com by uwe.h.schindler on 14 Sep 2014 at 10:16

Forbidden @java.lang.Deprecated is not always detected

If you put java.lang.Deprecated on the forbidden apis list, it is not always 
correctly detected. The reason for this is, that the Java compiler translates 
it into the deprecated code attribute and may not always put it as a real 
annotation.

As discussed on issue #44, we should "emulate" a java.lang.Deprecated ASM 
annotation visitor event, if the attribute is found (and filter duplicates). By 
that also code not making explicit use of @Deprecated annotation (just uses the 
@deprecated javadoc tag), will be detected correctly as having the attribute.

Original issue reported on code.google.com by uwe.h.schindler on 24 Dec 2014 at 12:24

Add an option to ignore unresolvable signatures

As explained in issue #10, I would like to propose a new feature for the Maven 
plugin, namely an option to ignore unresolvable signatures, i.e. signatures 
referring to classes that are not found in the dependencies of the Maven 
project.

The use case is to enforce a forbidden-api check for a custom library (not APIs 
from the JRE) on an entire multi-module Maven project (including modules that 
are added later) where some of the modules don't have a dependency on that 
library. If there was an option to ignore unresolvable signatures, then this 
use case can simply be implemented by configuring the execution of the 
forbidden-api in the parent POM. With the current Maven plugin this doesn't 
work because it would fail on the modules that don't have the custom library as 
dependency. The only way would be to configure the plugin individually in each 
module that has the dependency, but this solution is not practical and it's not 
possible to enforce the check on modules that are added later.

Original issue reported on code.google.com by [email protected] on 13 Oct 2013 at 2:41

Attachments:

• failOnUnresolvableSignatures.patch

Support validating test classes in Maven Mojo

The current MavenMojo class can only validate classes from the build/classes 
dir, not the test dir. It might be possible to do this with the same Mojo, but 
the problem here is the DependencyResolutionScope, which cannot be changed at 
runtime.
I think we must add a second Mojo (ideally all Mojos using the same default 
base class, only providing access to defaults and classpath)

Original issue reported on code.google.com by uwe.h.schindler on 12 Feb 2013 at 8:25

Forbidden package access rule

I was also looking for an option to detect any access to a "forbidden" package 
or package structure, as in:

@defaultMessage Hands off from these packages.
com.foo.**
com.boo.**

The use case scenario is actually quite specific -- we have a project structure 
which is shaded/ obfuscated during the build, but during development all 
packages are visible. It'd be nice to capture those forbidden package calls 
even before obfuscation/ ITs take place.

Should be trivial to implement -- you don't need to even know what is in those 
packages, just scan all class literals. 

Parsing and distinguishing these rules from other rules may require changes in 
ruleset syntax though.

Original issue reported on code.google.com by [email protected] on 4 Nov 2014 at 11:32

"Check for forbidden API calls failed: java.lang.ClassNotFoundException"

What steps will reproduce the problem?
1. Add forbiddenapis 1.7 plugin to junixsocket pom 
(https://github.com/kohlschuetter/junixsocket)
2. Run "mvn clean install"
3. Get error message "[ERROR] Failed to execute goal 
de.thetaphi:forbiddenapis:1.7:check (default) on project junixsocket-demo: 
Check for forbidden API calls failed: java.lang.ClassNotFoundException: Class 
'com.mysql.jdbc.SocketFactory' not found on classpath -> [Help 1]"

What is the expected output? What do you see instead?
The execution should succeed (or at least show code errors found by 
forbiddenapis)

What version of the product are you using? On what operating system?
1.7 on OS X.

Please provide any additional information below.
forbiddenapis fails the build because some of the inspected classes refer other 
classes (com.mysql.jdbc.SocketFactory in this case, provided by 
"mysql-connector-java") that are not available in the "compile" scope, but in 
"runtime" only.

Suggested fix:
In CheckMojo, use runtimeClasspath instead of compileClasspath. Patch provided.

Original issue reported on code.google.com by ckkohl79 on 2 Dec 2014 at 7:38

Attachments:

• PATCH-runtimeClasspath.diff

Add unsafe signatures for Java 8, review Java 7

Currently Java 7 and Java 8 unsafe signatures are just copies of Java 6.

We should check especially Java 8 for new method signatures that use default 
charset, default locale, and default timezone. Java 7 is unlikely that new ones 
are introduced, but Java 8 has many new ones (because of introduction of 
closures).

Original issue reported on code.google.com by uwe.h.schindler on 9 Nov 2013 at 11:29

Support for checking single file instead of whole directory

Based on input parameters 
(https://code.google.com/p/forbidden-apis/wiki/CliUsage) I see that I can 
provide directory with source code and all files fill be examined. However I 
think it would be nice to add support for forbidden-apis to 
https://github.com/TouK/sputnik and for this I need to be able to scan single 
or more selected files instead of whole directory.

Thanks,
Damian

Original issue reported on code.google.com by [email protected] on 30 Jan 2015 at 10:00

Deprecated signatures of Java 8 fail to load on Java 9

This was found after changing Lucene to Java 8: 
https://issues.apache.org/jira/browse/LUCENE-6070

What happens:

-check-forbidden-all:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.8
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.8

BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:515: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:86: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:101: The 
following error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/common-build.xml:2293:
 Parsing signatures failed: No method found with following signature: 
java.util.jar.Pack200$Packer#addPropertyChangeListener(java.beans.PropertyChange
Listener)

This is a really new thing:

The method 
{{java.util.jar.Pack200$Packer#addPropertyChangeListener(java.beans.PropertyChan
geListener)}} part of the JDK 8 deprecation list. But this method was actually 
removed in Java 9 completely (the first deprecation ever that was actually 
removed!). This method was deprecated in Java 8 for the first time, with the 
following text:

"Deprecated.  The dependency on PropertyChangeListener creates a significant 
impediment to future modularization of the Java platform. This method will be 
removed in a future release. Applications that need to monitor progress of the 
packer can poll the value of the PROGRESS property instead."

The solution in forbidden-apis is to automatically disable 
failOnUnresolvableSignatures for those "deprecated" signatures, because they 
are likely to disappear in later Java versions.

Unfortunately for ANT builds there is no workaround at the moment, so this 
should go in version 1.6.2. On the other hand, disabling the above in Maven 
does not help, too, because it only prevents signatures from failing if the 
class was not found.

This issue should fix the following:
- Make failOnUnresolvableSignatures behave correctly when method or field is 
nor found
- Add @ignoreUnresolvable to signatures file checking and add this setting to 
the deprecated lists. This setting overrides the global setting.

Original issue reported on code.google.com by uwe.h.schindler on 22 Nov 2014 at 10:47

Update to ASM 5.0 final

ASM 5.0 is out, because Java 8 was released. The API changed a little bit. On 
MethodVisitors with version=ASM5, we need to override a different 
visitMethodIns variant (the old one is also deprecated).

Original issue reported on code.google.com by uwe.h.schindler on 19 Mar 2014 at 12:10

Option to skip the execution of the plugin

Please provide a skip option similar to:

http://mojo.codehaus.org/findbugs-maven-plugin/check-mojo.html#skip
http://mojo.codehaus.org/animal-sniffer-maven-plugin/check-mojo.html#skip
http://maven.apache.org/plugins/maven-checkstyle-plugin/checkstyle-mojo.html#ski
p
http://maven.apache.org/plugins/maven-pmd-plugin/check-mojo.html#skip

@Parameter(property="forbiddenapis.skip", defaultValue="false")
private boolean skip;

That way one can enable the plugin by default and selectively not execute it 
via:

mvn clean install -Dforbiddenapis.skip=true

or a profile:

<profile>
    <id>fast_build</id>
    <properties>
        <forbiddenapis.skip>true</forbiddenapis.skip>
    </properties>
</profile>

mvn clean install -P fast_build

Original issue reported on code.google.com by [email protected] on 7 Jul 2014 at 7:51

Add unsafe signatures for Java 9/10/11/12/13

Once Java 9 comes out...

Additional bad methods in commons-io

A few default-charset using methods in commons-io (FileUtils: added in 1.3) 
were missing. Additionally there was a missing detection for a 
CopyUtils(byte[],Writer).

Actually at some point the entire CopyUtils was deprecated (use IOUtils 
instead), so we should ban the whole file at least in versions where its 
deprecated... for another issue :)

Original issue reported on code.google.com by [email protected] on 1 Jul 2013 at 9:04

Regression: forbidden-apis 1.5 fails on non-runtime annotations (e.g. java.lang.Synthetic) which are not in classpath

Simon Willnauer tried to use forbidden 1.5 with ElasticSearch. Sometimes the 
compiler generates "virtual" annotations (java.lang.Synthetic) or annotations 
that are not visible at runtime. Those annotations should not be checked, 
because they might not exist on classpath (e.g. Guava's @NotNull).

This has to be fixed and 1.5.1 needs to be released ASAP.

Original issue reported on code.google.com by uwe.h.schindler on 17 Apr 2014 at 1:02

"jdk-system-out" bundled signatures does not work with Maven, because the java-target version is also appended, but the resource is unversioned

This does not work:

<properties>
  <!-- 
   It is recommended to set the compiler version globally,
   as the compiler plugin and the forbidden API checker both
   use this version
  -->
  <maven.compiler.target>1.6</maven.compiler.target>
</properties>

<!-- ... -->

<bundledSignature>jdk-system-out</bundledSignature>

It tries to load jdk-system-out-1.6, which does not exist. Versions should only 
be appended for "jdk-*" (this works correct) and if the resources are versioned 
(which is not the case for jdk-system-out).

Original issue reported on code.google.com by uwe.h.schindler on 9 Feb 2013 at 5:48

Commons IO by dependencies

It would be nice if the commons-io-unsafe bundle would take the version from 
the dependencies, so you don't have to care about it, when upgrading.

Original issue reported on code.google.com by [email protected] on 22 Nov 2013 at 8:45

allowed api check

Thanks for the great plugin!

Maybe you could add a way to invert the plugin's checking into "allowed api 
check".

Would be useful for:

https://developers.google.com/appengine/docs/java/jrewhitelist
https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation

Either one could use a different execution or one could have both allowed and 
forbidden apis configured.

Original issue reported on code.google.com by [email protected] on 12 Apr 2013 at 4:02

Improve memory usage

We should improve memory usage for large projects. Recently, Lucene's build 
crashed with OOM because too many classes were loaded. This was mainly caused 
by the task being run top-level, but forbidden should still not hold everything 
in memory.

The following improvements are easy:
- For related classes, we don't need to hold the ClassReader in memory (holding 
the byte array). Those classes are only parsed and signature lists are created. 
We should only extract superclasses and interfaces and throw the classreader 
away
- We may add lazy loading on classes to scan. This could be done by a type of 
"ClassLoader" that does a lookup on the Ant/Maven FileSet. The class is only 
parsed one time and classreader is thrown away. After parsing the class we just 
keep the sigantures for later lookups of related classes available.

Original issue reported on code.google.com by uwe.h.schindler on 10 Nov 2013 at 11:07

Detect references to invokeDynamic using method handles to forbidden methods

Currently the following Java 8 call does not get detected as forbidden call:

  Arrays.sort(someArray, Float::compare);

if the forbidden API signatures contains:

  java.lang.Float#compare(float,float)

The autoboxing invoved here is not the problem, the problem is more the Java 7 
feature of an invokeDynamic to a dynamic call site using a method handle to a 
static or virtual method which is on the forbidden list.

In short: we need detection for this crazy new Java 8 syntax:

  Class::method

using the new Java 7 MethodHandle, exposed by this ASM 4.0 class: 
http://asm.ow2.org/asm40/javadoc/user/org/objectweb/asm/Handle.html

The MethodVisitor has to detect invokeDynamic using a handle to our forbidden 
method.

Original issue reported on code.google.com by uwe.h.schindler on 26 Sep 2013 at 1:30

Add a possibility to invoke on command line via main() task

it should be possible to run the tool via:

java -jar forbiddenapis.jar

Original issue reported on code.google.com by uwe.h.schindler on 9 Feb 2013 at 7:01

Maven plugin should log warning if target version is not set

Using the maven plugin of forbidden-apis and not setting either the property 
"maven.compiler.target" or the plugin parameter "targetVersion" will lead to a 
build failure because the plugin can not find the bundled resources for the 
current java version. Logging a warning if the target version is null could 
lead the user to this misconfiguration and avoid some time of research.

Original issue reported on code.google.com by [email protected] on 23 Jun 2014 at 9:49

Add Java 8 deprecated + unsafe signatures

Since build 106, Java 8 is future complete. Time to add signatures for 
deprecation and unsafe.

For now the unsafe ones will be a clone of Java 7's although there might be new 
ones! I should check the API for charset, locale, and timezone problems.

Original issue reported on code.google.com by uwe.h.schindler on 26 Oct 2013 at 8:12

Example Maven configuration doesnt work

Whatever I try, I get :
No API signatures found; use parameters 'signatures, 'bundledSignatures', and/or 'signaturesFiles' to define those! -> [Help 1]

Used: Maven 3.1.1 with java 7

Re-enable class-only, non-runtime annotation checking

Issue #27 (forbiddenapis 1.5.1 hotfix) disabled non-visible annotations 
completely, because they may not be on classpath.

This issue will add support back, but don't do deep checks - just compare the 
name to list of forbidden classes.

Original issue reported on code.google.com by uwe.h.schindler on 26 Dec 2014 at 2:56

Only bundled signatures and empty tag does not work

If you supply only bundled signatures (e.g. through attribute) and have no 
inner text, the check in the Ant task fails the build.

The reason is that there is no inner text, that otherwise prevented the build 
from failing. The logic must be changed to count the real signature loads.

Original issue reported on code.google.com by uwe.h.schindler on 9 Feb 2013 at 6:13

Add option to also ignore unresolvable signatures in Ant and CLI

In issue #14 support was added to Maven Mojo, so the build does not fail on 
unresolvable signatures. This was not added to Apache Ant, but it may be useful 
as workaround for issues like issue #41.

This is an easy change, just ad setter to Task and pass this to Checker ctor 
(currently always "true" is passed, to fail).

Original issue reported on code.google.com by uwe.h.schindler on 23 Nov 2014 at 12:01

fail on duplicate class definitions ("jar hell")

Here is a patch (sorry, no test yet, also: completely untested!).

Original issue reported on code.google.com by [email protected] on 3 Feb 2014 at 8:28

Attachments:

• jarhell.patch

Add support for signaturesFilelist and signaturesFile elements

You should be able to enforce specific signatures files, to *enforce* specific 
files. Filesets are too relaxed, because they simply ignore missing files, 
leading to no checks done.

This allows to do the following:

<forbiddenapis>
 <signaturesFile file="sign.txt"/>
 <siganturesFilelist dir="." files="file1.txt, file2.txt"/>
<forbiddenapis>

Original issue reported on code.google.com by uwe.h.schindler on 14 Sep 2014 at 9:31

Remove deprecated Mojo from version 1.0

The forbiddenapis:forbiddenapis Mojo should no longer be used. The mojo goes 
back to version 1.0, where we had no separate main classes / test classes Mojos.

This will release the deprecated placeholder (clone of forbiddenapis:check).

The next release 1.7 will be without this Mojo.

Original issue reported on code.google.com by uwe.h.schindler on 8 Aug 2014 at 12:51

Make it possible to ban annotations?

I am not sure if this is really necessary, its more of a curiousity/joke

What steps will reproduce the problem?
1. add this to signatures file:

org.junit.Test @ useless

What is the expected output? 

BUILD FAILED

What do you see instead?

[forbidden-apis] Scanned 29 (and 86 related) class file(s) for forbidden API 
invocations (in 0.07s), 0 error(s).

Original issue reported on code.google.com by [email protected] on 16 May 2013 at 5:47