JAPI-COMPLIANCE-CHECKER(1)

πŸ“¦
version 2.4 Β· 3 versions
, in debian bookworm, debian trixie, ubuntu noble, ubuntu questing

πŸ¦‹ JAPI-COMPLIANCE-CHECKER πŸ¦‹

hiii bestie πŸ’– you just cracked open the manual page for japi-compliance-checker, and yes it lives in the User Commands corner of the man-page universe (section 1, iykyk). it's a whole glow-up guard for your Java library, no cap. sit down, grab a strawberry drink πŸ“, and let's get into it.


🌸 NAME 🌸

japi-compliance-checker β€” check backward compatibility of a Java library API. that's it. that's the whole first impression. iconic.


✨ DESCRIPTION ✨

πŸ’… NAME:

Java API Compliance Checker (japi-compliance-checker) β€” Check backward compatibility of a Java library API

πŸŽ€ DESCRIPTION:

Java API Compliance Checker (JAPICC) is a tool for checking backward binary/source compatibility of a Java library API. The tool checks class declarations of old and new versions and analyzes changes that may break compatibility: removed class members, added abstract methods, etc.

Break of the binary compatibility may result in crash or incorrect behavior of existing clients built with an old library version if they run with a new one. Break of the source compatibility may result in recompilation errors with a new library version.

The tool is intended for developers of software libraries and maintainers of operating systems who are interested in ensuring backward compatibility, i.e. allow old clients to run or to be recompiled with newer library versions.

This tool is free software: you can redistribute it and/or modify it under the terms of the GNU LGPL.

fr fr, this is a "don't break your users" tool and it takes that job very seriously πŸ’…

🌈 USAGE:

japi-compliance-checker [options]

πŸ“ EXAMPLE (1):

japi-compliance-checker OLD.jar NEW.jar

πŸ“ EXAMPLE (2):

japi-compliance-checker OLD.jmod NEW.jmod

πŸ“ EXAMPLE (3):

japi-compliance-checker -lib NAME -old OLD.xml -new NEW.xml

OLD.xml and NEW.xml are XML-descriptors:

<version>

1.0

</version>

<archives>

/path1/to/JAR(s) OR JMOD(s)/ /path2/to/JAR(s) OR JMOD(s)/ ...

</archives>

πŸ’– INFORMATION OPTIONS: πŸ’–

  • -h | -help β€” print this help. the classic "what do I even do here" button 🫢
  • -v | -version β€” print version information.
  • -dumpversion β€” print the tool version (2.4) and don't do anything else. she says her age and then leaves. periodt.

🌟 GENERAL OPTIONS: 🌟

  • -l | -library NAME β€” library name (without version).
  • -old | -d1 PATH β€” descriptor of the 1st (old) library version. it may be one of the following:
    1. Java archive (*.jar or *.jmod)
    2. XML-descriptor (VERSION.xml file):
<version>

1.0

</version>

<archives>

/path1/to/JAR(s) OR JMOD(s)/ /path2/to/JAR(s) OR JMOD(s)/

...

</archives>

...
  1. API dump generated by -dump option

If you are using *.jar or *.jmod as a descriptor then you should specify version numbers with -v1 and -v2 options too. If version numbers are not specified then the tool will try to detect them automatically.

  • -new | -d2 PATH β€” descriptor of the 2nd (new) library version.

πŸ”₯ EXTRA OPTIONS: πŸ”₯

  • -client | -app PATH β€” this option allows to specify the client Java archive that should be checked for portability to the new library version.
  • -binary | -bin β€” show "Binary" compatibility problems only. Generate report to bin_compat_report.html.
  • -source | -src β€” show "Source" compatibility problems only. Generate report to src_compat_report.html.
  • -v1 | -version1 NUM β€” specify 1st API version outside the descriptor. This option is needed if you have prefered an alternative descriptor type (see -d1 option).

In general case you should specify it in the XML descriptor:

<version>

VERSION

</version>
  • -v2 | -version2 NUM β€” specify 2nd library version outside the descriptor.
  • -vnum NUM β€” specify the library version in the generated API dump.
  • -s | -strict β€” treat all API compatibility warnings as problems. no chill mode 😀
  • -keep-internal β€” do not skip checking of these packages:
    • *impl*
    • *internal*
    • *examples*
  • -skip-internal-packages PATTERN β€” do not check packages matched by the regular expression.
  • -skip-internal-types PATTERN β€” do not check types (classes and interfaces) matched by the regular expression. It's matched against full qualified type names (e.g. 'org.xyz.Name<T>'). It has to match any part of type name.
  • -dump | -dump-api PATH β€” dump library API to gzipped TXT format file. You can transfer it anywhere and pass instead of the descriptor. Also it may be used for debugging the tool. PATH is the path to the Java archive or XML descriptor of the library.
  • -check-annotations β€” check for changes in annotations like in any other interfaces.
  • -check-packages PATTERN β€” check packages matched by the regular expression. Other packages will not be checked.
  • -classes-list PATH β€” this option allows to specify a file with a list of classes that should be checked, other classes will not be checked.
  • -annotations-list PATH β€” specifies a file with a list of annotations. The tool will check only classes annotated by the annotations from the list. Other classes will not be checked.
  • -skip-annotations-list PATH β€” skip checking of classes annotated by the annotations in the list.
  • -skip-deprecated β€” skip analysis of deprecated methods and classes. goodbye old yeller πŸ’€
  • -skip-classes PATH β€” list of classes that should not be checked.
  • -skip-packages PATH β€” list of packages that should not be checked.
  • -non-impl PATH β€” list of interfaces that should not be implemented by users.
  • -non-impl-all β€” all interfaces should not be implemented by users.
  • -short β€” do not list added/removed methods.
  • -dump-path PATH β€” specify a *.dump file path where to generate an API dump. Default:
api_dumps/LIB_NAME/VERSION/API.dump
  • -report-path PATH β€” path to compatibility report. Default:
compat_reports/LIB_NAME/V1_to_V2/compat_report.html
  • -bin-report-path PATH β€” path to "Binary" compatibility report. Default:
compat_reports/LIB_NAME/V1_to_V2/bin_compat_report.html
  • -src-report-path PATH β€” path to "Source" compatibility report. Default:
compat_reports/LIB_NAME/V1_to_V2/src_compat_report.html
  • -quick β€” quick analysis. Disabled:
    • analysis of method parameter names
    • analysis of class field values
    • analysis of usage of added abstract methods
    • distinction of deprecated methods and classes
  • -sort β€” enable sorting of data in API dumps.
  • -show-access β€” show access level of non-public methods listed in the report.
  • -hide-templates β€” hide template parameters in the report.
  • -hide-packages β€” no description given, she's keeping it mysterious πŸ™ˆ
  • -minimal β€” do nothing. literally the "not me, not today" option 😭
  • -show-packages β€” show package names in the report.
  • -limit-affected LIMIT β€” the maximum number of affected methods listed under the description of the changed type in the report.
  • -compact β€” try to simplify formatting and reduce size of the report (for a big set of changes).
  • -added-annotations β€” apply filters by annotations only to new version of the library.
  • -removed-annotations β€” apply filters by annotations only to old version of the library.
  • -count-methods PATH β€” count total public methods in the API dump.
  • -dep1 PATH
  • -dep2 PATH β€” path to the API dump of the required dependency archive. It will be used to resolve overwritten methods and more.
  • -old-style β€” generate old-style report.

🧚 OTHER OPTIONS: 🧚

  • -test β€” run internal tests. Create two incompatible versions of a sample library and run the tool to check them for compatibility. This option allows to check if the tool works correctly in the current environment.
  • -debug β€” debugging mode. Print debug info on the screen. Save intermediate analysis stages in the debug directory:
debug/LIB_NAME/VER/

Also consider using -dump option for debugging the tool.

  • -title NAME β€” change library name in the report title to NAME. By default will be displayed a name specified by -l option.
  • -jdk-path PATH β€” path to the JDK install tree (e.g. /usr/lib/jvm/java-7-openjdk-amd64).
  • -external-css PATH β€” generate CSS styles file to PATH. This helps to save space when generating thousands of reports.
  • -external-js PATH β€” generate JS script file to PATH.

πŸ‘‘ REPORT: πŸ‘‘

compatibility report will be generated to:

compat_reports/LIB_NAME/V1_to_V2/compat_report.html

⭐ EXIT CODES: ⭐

  • 0 β€” Compatible. The tool has run without any errors.
  • non-zero β€” Incompatible or the tool has run with errors.
so like, 0 is the "we ate and left no crumbs" ending, and non-zero is the "we need to talk" ending πŸ’€

🌈 MORE INFO: 🌈


🫢 AUTHOR 🫢

Written by Andrey Ponomarenko.


Copyright Β© 2018 Andrey Ponomarenko's ABI Laboratory License: LGPLv2.1+ <http://www.gnu.org/licenses/> This program is free software: you can redistribute it and/or modify it.


okay bestie, that's the whole page πŸŽ€ and now the cute little sign-off that lives at the very bottom, the one that's like the page's little name tag: it's the Java API Compliance Checker, dated November 2022, and yeah it's still the JAPI-COMPLIANCE-CHECKER(1) girlie you know and love πŸ’–πŸ¦‹βœ¨

πŸ“¦ where this page comes from