List of API Differences
When Revapi reports the found API problems it needs to pinpoint the element it is "talking about". Therefore it assigns a one-line representation to each API element to identify it. It tries to follow the conventions of Java syntax but needs to go beyond it to express additional information.
First, let’s go through some simple examples.
class com.example.MyClass
This somewhat obviously refers to a class called MyClass
in the com.example
package.
class com.example.MyGenericClass<T extends java.lang.Number>
This again refers to the class but you can see that Revapi also includes the type parameters in the class name. Note that the bounds of the type parameters are specified using fully qualified class names.
interface com.example.MyInterface
Here we see that different kinds of classes are distinguished. Revapi uses @interface
for annotation types, enum
for
enumerations, interface
for interfaces and class
for ordinary classes.
missing-class com.example.Whoops
What’s this? Here, Revapi tries to convey that the class in question wasn’t found anywhere on the classpath.
method java.lang.String com.example.MyClass::myMethod(int, long)
If you are familiar with the method reference syntax in Java 8, you may guess that the above refers to a method called
myMethod
declared in the com.example.MyClass
class that returns a java.lang.String
and accepts an int
as its
first argument and a long
as its second argument. As with classes, the type mentioned in the method identifier may
include the type parameters. The method identifier also includes the throws
declaration if present on the method.
parameter java.lang.String com.example.MyClass::myMethod(int, ===long===)
If Revapi needs to "talk" about a single parameter of a method, it encloses the parameter in ===
. The above therefore
identifies the second parameter of the method myMethod
.
field com.example.MyClass.myField
Quite intuitively, the above identifies the field called myField
in the class com.example.MyClass
.
method void com.example.MySuperClass::superMethod() @ com.example.MyClass
This is again a little bit cryptic. The above identifies the method superMethod
declared in com.example.MySuperClass
as seen in com.example.MyClass
. In another words, Revapi distinguishes between a declared method and inherited method.
This is because a public method in a private class can be made "accessible" in the API if the private class is inherited
by some public class in the API.
- Types
class the.fully.qualified.class.name.including.Any<Type extends Params>
where class
can be class
, interface
, enum
or @interface
depending on the kind of class in question, or in case
the type is missing in the API:
missing-class fully.qualified.class.name.including.Any<Type extends Params>
- Methods
-
Declared method:
method ReturnType fully.qualified.class.name.of.the.declaring.class::methodName(All, The, Params) throws Any, Exceptions
Inherited method:
method ReturnType fully.qualified.class.name.of.the.declaring.class::methodName(All, The, Params) throws Any, Exceptions @ the.class.that.inherits.the.Method
Revapi distinguishes between declared and inherited methods because a public method in a private class can be made "accessible" in the API if the private class is inherited by some public class in the API.
- Method Parameters
-
This is where the syntax differs most from java. The
===
highlight the parameter in question among the others. Note also that the parameter names are not available because more often than not they’re not available in the bytecode.
Parameter on a declared method:
parameter ReturnType class.name.of.declaring.class::methodName(===ParameterType===, Other, Params)
Parameter on an inherited method:
parameter ReturnType class.name.of.declaring.class::methodName(===ParameterType===, Other, Params) @ class.name.of.inheriting.class
Because method parameter is tied to the method, the distinction between a declared and inherited method is exhibited in the identifier of the method parameter, too.
- Fields
-
Declared field:
field fully.qualified.class.name.of.declaring.class.fieldName
Inherited field:
field fully.qualified.class.name.of.declaring.class.fieldName @ class.that.inherits.the.Field
As with methods, the distinction between a declared and inherited field is quite important.
Match Parameters
In addition to a human-readable representation of the element outlined above, the differences can also be matched by their additional parameters. Each of the below differences lists the parameters that can be matched against.
For example the java.class.noLongerImplementsInterface
difference defines the match parameter interface
. This can
be used when matching the difference for example in the revapi.ignore
extension:
{
"regex": true,
"code": "java\\.class\\.noLongerImplementsInterface",
"old": "class my\\..*",
"interface": "my\\.Interface"
}
The above will instruct Revapi to not report the removal of my.Interface
from the list of implemented interfaces on
any class in the my
package (or any other subpackage).
All types of differences report the archives that the element come from using these match parametes:
|
The name of the archive where the old element comes from, if any |
|
The name of the archive where the new element comes from, if any |
|
The role of the old archive. Can be either |
|
The same as |
All types of differences report the elementKind
parameter that can have 1 of the following values:
|
The element is an ordinary class |
|
The element is an interface |
|
The element is an enum class |
|
The element is an annotation class |
|
The element is a constructor |
|
The element is an enum constant |
|
The element is a field |
|
The method is a method |
|
The element is a method parameter |
|
The element is an annotation of another element |
Additionally, if the analyzer is configured to report example use chains for given difference (see the java extension
configuration), there will be 1 or 2 more parameters with the example use chains present:
exampleUseChainInOldApi
and/or exampleUseChainInNewApi
.
Detected Differences
All the differences detected by the extension are defined in the Code enumeration. Below, you can find a short discussion of each type of the difference.
Missing API Class - java.missing.oldClass
, java.missing.newClass
Binary severity |
potentially breaking |
Source severity |
potentially breaking |
Semantic severity |
NA |
By default, Revapi will report any type that should belong to the API but cannot be found neither in the API libraries themselves or in the supporting libraries. It can also be configured to ignore such missing classes or to abort the API check altogether. If it is configured to report them (which is the default), one of the above codes will be emitted depending on whether the missing class is found in the old version of the API or the new one.
The missing class behavior can be configured by the revapi.java.missing-classes
configuration property with the
possible values of ignore
, report
and error
, e.g.:
{
"extension": "revapi.java",
"configuration": {
"missing-classes" : "ignore"
}
}
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
See Match Parameters for the common match parameters |
Element No Longer Deprecated - java.element.noLongerDeprecated
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
NA |
An element (class, method or field) is marked as deprecated in the old version of the API but not in the new version. This represents no danger in terms of API breakage and is reported only because it is useful to know for the library users to know about such cases.
Match parameters | |
---|---|
|
exactly |
See Match Parameters for the common match parameters |
Element Now Deprecated - java.element.nowDeprecated
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
NA |
An element (class, method or field) is marked as deprecated in the new version of the API but not in the old version. This represents no danger in terms of API breakage and is reported only because it is useful to know for the library users to know about such cases.
Match parameters | |
---|---|
|
exactly |
See Match Parameters for the common match parameters |
Class Visibility Increased - java.class.visibilityIncreased
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
NA |
The class is more visible in the new version of the API than it used to be in the old version. This is no API breakage and is reported for completeness sake. The visibility is ordered as follows: private < package private < protected < public.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
The visibility of the type as it was in the old version. |
|
The visibility of the type in the new version. |
See Match Parameters for the common match parameters |
Class Visibility Reduced - java.class.visibilityReduced
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
Reducing the visibility of an API class is a breaking change. It means that classes that could inherit or use the class might no longer be able to. Thus a library user might face compilation errors at compile time or linkage errors at runtime when trying to use the new version of the library.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
The visibility of the type as it was in the old version. |
|
The visibility of the type in the new version. |
See Match Parameters for the common match parameters |
Class Kind Changed - java.class.kindChanged
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
There are 4 kinds of java classes: class, interface, annotation type, enum. This difference is reported when a class changes from one to the other. This is of course incompatible change and will break the library users at both compile time and at runtime.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
The kind of the type as it was in the old version. |
|
The kind of the type in the new version. |
See Match Parameters for the common match parameters |
Class No Longer Final - java.class.noLongerFinal
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
NA |
A class that used to be final is now not. This is no API breakage and is reported for completeness sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
The sorted modifiers on the class in the old version. |
|
The sorted modifiers on the class in the new version. |
See Match Parameters for the common match parameters |
Modifiers are sorted according to the
Java style guidelines in the
following order: public protected private abstract static final transient volatile default synchronized native
strictfp .
|
Class Now Final - java.class.nowFinal
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
A class became final in the new version of the library. This is a breaking change because any library user that extended the class will no longer be compatible with the new version of the library, in which the class cannot be extended.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
The sorted modifiers on the class in the old version. |
|
The sorted modifiers on the class in the new version. |
See Match Parameters for the common match parameters |
See Class No Longer Final - java.class.noLongerFinal for the ordering of the modifiers.
|
Class No Longer Abstract - java.class.noLongerAbstract
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
NA |
A class that used to be abstract is now not. This is no API breakage and is reported for completeness sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
The sorted modifiers on the class in the old version. |
|
The sorted modifiers on the class in the new version. |
See Match Parameters for the common match parameters |
See Class No Longer Final - java.class.noLongerFinal for the ordering of the modifiers.
|
Class Now Abstract - java.class.nowAbstract
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
A concrete class became abstract in the new version of the library. This is a breaking change because it is no longer possible to create instances of such class.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
The sorted modifiers on the class in the old version. |
|
The sorted modifiers on the class in the new version. |
See Match Parameters for the common match parameters |
See Class No Longer Final - java.class.noLongerFinal for the ordering of the modifiers.
|
Class Added - java.class.added
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
NA |
A new class appeared in the new version of the API. This is a non-breaking change reported for completeness sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
See Match Parameters for the common match parameters |
Class Removed - java.class.removed
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
A class present in the old version of the library is no longer present. This is of course a breaking change because the users of the API will no longer be able to use that class in any capacity.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
See Match Parameters for the common match parameters |
External Class Exposed In API - java.class.externalClassExposedInAPI
Binary severity |
non-breaking |
Source severity |
non-breaking |
Semantic severity |
potentially breaking |
This is reported for classes from dependencies that are exposed in the API (for example as a return value). This is generally discouraged practice because it makes updating the dependency version a more complex task (you want a bugfix but you don’t want the changed API to leak to your users).
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
See Match Parameters for the common match parameters |
External Class No Longer Exposed In API - java.class.externalClassNoLongerExposedInAPI
Binary severity |
non-breaking |
Source severity |
non-breaking |
Semantic severity |
NA |
An opposite of External Class Exposed In API - java.class.externalClassExposedInAPI
. This is non-breaking, because the class is still accessible on the
classpath so users that used to rely on it can still access it. The class is just no longer exposed in the API (which
will usually cause other differences to be reported, too).
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
See Match Parameters for the common match parameters |
Class No Longer Implements Interface - java.class.noLongerImplementsInterface
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
This is a breaking change because it is no longer possible to cast the class to the no longer implemented interface.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
The fully qualified name of the interface that is no longer implemented. |
See Match Parameters for the common match parameters |
Class Now Implements Interface - java.class.nowImplementsInterface
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
NA |
No API breakage reported for the completeness sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
The fully qualified name of the interface that is now implemented. |
See Match Parameters for the common match parameters |
Final Class Inherits From New Class - java.class.finalClassInheritsFromNewClass
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
NA |
A final class inherits from a new class. This represents no API breakage and is reported for completeness sake. Inheriting from a new class may introduce new methods or fields to the class but cannot remove any (method changes are reported separately).
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
The fully qualified name of the new super class. |
See Match Parameters for the common match parameters |
Non-final Class Inherits From New Class - java.class.nonFinalClassInheritsFromNewClass
Binary severity |
potentially breaking |
Source severity |
potentially breaking |
Semantic severity |
NA |
While this change is usually OK, it might cause trouble to the users of the API if the newly inherited class contains final methods. If the users of the library happen to define methods of the same name in the class that inherits from the checked one, they will get compilation or linkage errors.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
The fully qualified name of the new super class. |
See Match Parameters for the common match parameters |
Class Now Checked Exception - java.class.nowCheckedException
Binary severity |
non breaking |
Source severity |
breaking |
Semantic severity |
NA |
A class newly inherits from java.lang.Exception. This is a source incompatibility because such exceptions need to be declared in the throws declarations of the methods.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
See Match Parameters for the common match parameters |
Class No Longer Inherits From Class - java.class.noLongerInheritsFromClass
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
The checked class no longer inherits from a super class that it used to. This means that it can no longer be cast to that super class nor can the methods declared in the super class be called using the instance of the checked class.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
The fully qualified name of the superclass that is no longer inherited. |
See Match Parameters for the common match parameters |
Default Serialization of Class Changed - java.class.defaultSerializationChanged
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
breaking |
This is reported on serializable classes that don’t explicitly define a serialVersionUID
field and that have changed
with regards to serializability. Note that this doesn’t accept the same configuration properties as the
java.field.serialVersionUIDChanged
or java.field.serialVersionUIDUnchanged
because for classes without
the serialVersionUID
the default JVM method of computing the serial version is always used.
This check is not perfect. It will not detect a serializability change of a class if a type of one of its fields changes its serialization format. This imperfection is shared with java serialization itself though. |
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
|
the value of the computed serial version UID in the old version (as decimal number) |
|
the value of the computed serial version UID in the new version (as decimal number) |
See Match Parameters for the common match parameters |
Class Is Non-Public Part of API - java.class.nonPublicPartOfAPI
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
breaking |
While this is non-breaking from the pure API compatibility point of view, it is a very strange design decision. This means that a class that is not publicly accessible (i.e. is private or package private) is used in a public capacity (i.e. return type of a method, type of a method parameter, type of an accessible field, implemented interface).
By default, Revapi even outputs the "usage chain" from some public API element to the non-public class.
The check is done only on a new version of the API. It serves little purpose to report this on the old which has already
been released, while the new one might still not be out in the wild. It does make sense though to accept that some parts
of the API use non-public classes, because such API has already existed. Therefore, you can configure Revapi to only
report new violations but let the old ones be. The default behavior is to always report non-public class in the API even
if it existed in the old version (the reportUnchanged
attribute below defaults to true
) but you can override it as
such:
<revapi.java>
<checks>
<nonPublicPartOfAPI>
<reportUnchanged>false</reportUnchanged>
</nonPublicPartOfAPI>
</checks>
</revapi.java>
or
{
"extension": "revapi.java",
"configuration": {
"checks": {
"nonPublicPartOfAPI": {
"reportUnchanged": false
}
}
}
}
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
See Match Parameters for the common match parameters |
This is NOT reported on a non-accessible class that is used solely as a super class of another API classes or that is only implemented by other API classes. An implementation of a private interface or inheriting from a non-public super class is a valid design decision. |
Type Parameters of The Super Type Changed - java.class.superTypeTypeParametersChanged
Binary severity |
potentially breaking |
Source severity |
potentially breaking |
Semantic severity |
NA |
The checked class inherits from a generic class. The type parameters used on the generic super class changed between old and new version. Because of type erasure, this might not cause any binary incompatibility (but it can) and it can potentially break the compilation, too.
This is generally a quite dangerous thing to do, because it can change the erased signatures of the methods or fields inherited from the super class (which would be the cause of the binary and source incompatibilities).
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
The old signature of the super type. |
|
The new signature of the super type. |
See Match Parameters for the common match parameters |
Annotation Added - java.annotation.added
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
potentially breaking |
An element is newly annotated by given annotation. This poses no risk during compilation or at linkage time but may cause semantic differences between the versions because of the way the annotations can be used (code generation, processing, reflection, etc.).
Match parameters | |
---|---|
|
The fully qualified name of the annotation type, preceded by |
See Match Parameters for the common match parameters |
Annotation Removed - java.annotation.removed
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
potentially breaking |
An element is no longer annotated by given annotation. This poses no risk during compilation or at linkage time but may cause semantic differences between the versions because of the way the annotations can be used (code generation, processing, reflection, etc.).
Match parameters | |
---|---|
|
The fully qualified name of the annotation type, preceded by |
See Match Parameters for the common match parameters |
Annotation Attribute Value Changed - java.annotation.attributeValueChanged
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
potentially breaking |
An attribute of some annotation on some element changed its value. This poses no risk during compilation or at linkage time but may cause semantic differences between the versions because of the way the annotations can be used (code generation, processing, reflection, etc.).
Match parameters | |
---|---|
|
The name of the attribute that changed value |
|
The fully qualified name of the annotation type, preceded by |
|
The old value of the attribute. |
|
The new value of the attribute. |
See Match Parameters for the common match parameters |
Annotation Attribute Added - java.annotation.attributeAdded
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
potentially breaking |
An annotation on some element newly specifies an explicit value of an attribute. This poses no risk during compilation or at linkage time but may cause semantic differences between the versions because of the way the annotations can be used (code generation, processing, reflection, etc.).
Match parameters | |
---|---|
|
The name of the attribute that was added |
|
The fully qualified name of the annotation type, preceded by |
|
The value of the attribute. |
See Match Parameters for the common match parameters |
Annotation Attribute Removed - java.annotation.attributeRemoved
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
potentially breaking |
An annotation on some element no longer specifies an explicit value of an attribute. This poses no risk during compilation or at linkage time but may cause semantic differences between the versions because of the way the annotations can be used (code generation, processing, reflection, etc.).
Match parameters | |
---|---|
|
The name of the attribute that was removed, |
|
The value of the attribute that was removed, |
|
The fully qualified name of the annotation type, preceded by |
See Match Parameters for the common match parameters |
Annotation No Longer Inherited - java.annotation.noLongerInherited
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
potentially breaking |
An annotation type used to be annotated with the @Inherited
annotation but is no more. This poses no risk during
compilation or at linkage time but may cause semantic differences between the versions because of the way the
annotations can be used (code generation, processing, reflection, etc.).
Match parameters | |
---|---|
|
exactly |
See Match Parameters for the common match parameters |
Annotation Now Inherited - java.annotation.nowInherited
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
potentially breaking |
An annotation type is now annotated with the @Inherited
annotation. This poses no risk during
compilation or at linkage time but may cause semantic differences between the versions because of the way the
annotations can be used (code generation, processing, reflection, etc.).
Match parameters | |
---|---|
|
exactly |
See Match Parameters for the common match parameters |
Static Field Added - java.field.addedStaticField
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
NA |
No API breakage, provided for completeness sake. Note that this si reported only for publicly accessible fields.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
See Match Parameters for the common match parameters |
Field Added - java.field.added
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
NA |
No API breakage, provided for completeness sake. Note that this si reported only for publicly accessible fields.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
See Match Parameters for the common match parameters |
Field Removed - java.field.removed
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
The field was removed from the class. This is an API breakage because the field can no longer be accessed. Note that this si reported only for publicly accessible fields.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
See Match Parameters for the common match parameters |
Constant Field Removed
Code |
java.field.removedWithConstant |
Binary severity |
non-breaking |
Source severity |
breaking |
Semantic severity |
potentially breaking |
The field with a constant value was removed from the class. This is source incompatible because the field can no longer be accessed. It is binary compatible though because the field is actually never used because all its uses are inlined. Note that this si reported only for publicly accessible fields.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
See Match Parameters for the common match parameters |
Field Moved To Superclass - java.field.movedToSuperclass
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
NA |
The field was moved to a super class. From the point of view of the field user this represents no noticeable change.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
|
The class the field used to be declared in. |
|
The class the field is now declared in. |
See Match Parameters for the common match parameters |
Inherited Field Now Declared On Class - java.field.inheritedNowDeclared
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
NA |
A field that was previously inherited is now declared on the class. From the point of view of the field user this represents no noticeable change. If the field was also removed from the super class, it will be reported separately.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
|
The class the field used to be declared in. |
|
The class the field is now declared in. |
See Match Parameters for the common match parameters |
Constant Field Removed - java.field.removed
Binary severity |
non breaking |
Source severity |
breaking |
Semantic severity |
potentially breaking |
An accessible static final field (i.e. a constant) was removed from the class. This breaks compilation but actually causes no problem at runtime (i.e. when the new API is swapped for the old API without recompiling the users of the API). This is because the constants are inlined during compilation. Because the value is no longer declared or used in the API but the user of the API still can operate with the value, this is also reported as potentially breaking the semantics.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
See Match Parameters for the common match parameters |
Constant Field Changed Value - java.field.constantValueChanged
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
breaking |
A constant field changed its value. At compilation time, the new value is used, but at runtime (i.e. when the new API is swapped for the old API without recompiling the users of the API) the users of the API will still use the old value, because the constant values are inlined. This is therefore reported as breaking the semantics.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
|
The old value of the constant field. |
|
The new value of the constant field. |
See Match Parameters for the common match parameters |
Field Now Constant - java.field.nowConstant
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
potentially breaking |
This is no API breakage but has consequences for the user code. As a constant, the field will now be inlined in the user code, which is something that didn’t happen before. You may want to re-evaluate that decision.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
|
The constant value of the field. |
See Match Parameters for the common match parameters |
Field No Longer Constant - java.field.noLongerConstant
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
breaking |
When compiling an API user against the new version of the API, the value of the field is taken. When swapping the new version of the API for the old version of the API without recompiling the old value coming from the inlined constant value from the old version of the API is used. I.e. the code works and therefore this is neither a source nor binary incompatibility, but it is marked as a semantic incompatibility, because the behavior described above is most probably NOT what the API author had in mind when making the change.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
|
The constant value the field used to have. |
See Match Parameters for the common match parameters |
Field Now Final - java.field.nowFinal
Binary severity |
potentially breaking |
Source severity |
potentially breaking |
Semantic severity |
NA |
A field that could previously be assigned to is now final and cannot be changed. This is therefore both source and binary incompatibility.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
See Match Parameters for the common match parameters |
Field No Longer Final - java.field.noLongerFinal
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
NA |
This is no API breakage and is reported for completeness' sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
See Match Parameters for the common match parameters |
Field No Longer Static - java.field.noLongerStatic
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
A static field has become an instance field. Accessing the field is no longer possible through its class and therefore this is both source and binary incompatibility.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
See Match Parameters for the common match parameters |
Field Now Static - java.field.nowStatic
Binary severity |
breaking |
Source severity |
non breaking |
Semantic severity |
NA |
According to the Java specification, the Java runtime will throw IncompatibleClassChangeError
when an instance field
has become static and the new version of API is used against the user code compiled against the old version of API.
When recompiling the user code against the new version, everything works fine.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
See Match Parameters for the common match parameters |
Field Type Changed - java.field.typeChanged
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
The field has a different type than it used to in the old version of the API. This is incompatible change.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
|
The fully qualified name of the old field type. |
|
The fully qualified name of the new field type. |
See Match Parameters for the common match parameters |
Field serialVersionUID
Unchanged - java.field.serialVersionUIDUnchanged
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
potentially breaking |
This is reported on the serialVersionUID
fields of classes that didn’t change between the versions even though the
default UIDs would be different for the two versions of the the class. While this doesn’t break the compilation nor does
it break binary compatibility, it possibly may cause semantic problems because serialization may misbehave. This
depends on if and how the readObject
and writeObject
methods on the class are implemented, which is beyond the scope
of this check.
The behavior of this check can be configured using the revapi.java.checks.serialVersionUID.changeDetection
configuration attribute. The default value of this attribute is structural
meaning that the difference is reported
only for classes that somehow change structurally between versions (i.e. a field is added/deleted or its type changed).
When specifying jvm
as the change detection algorithm the default serialVersionUID is computed for both old and new
version of the class. This is more "sensitive" than the structural change because it also considers any changes to
methods or static fields of the class (but it nevertheless is the algorithm that the JVM itself uses for computing the
default serialization UID of a class).
Example of the configuration in both XML and JSON:
<revapi.java>
<checks>
<serialVersionUID>
<changeDetection>structural</changeDetection>
</serialVersionUID>
</checks>
</revapi.java>
or
{
"extension": "revapi.java",
"configuration": {
"checks": {
"serialVersionUID": {
"changeDetection": "jvm"
}
}
}
}
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
|
the value of the serial version UID field (as decimal number) |
See Match Parameters for the common match parameters |
Field serialVersionUID
Changed - java.field.serialVersionUIDChanged
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
breaking |
This is reported as a breaking change because it is assumed that if a class is serializable it actually is
serialized and deserialized. Changing the value of the serialVersionUID
static field causes the new class to no longer
be able to deserialize objects that were serialized using the old version of the class.
This check can be configured the same way as [_field_serialversionuid_unchanged__java_field_serialversionuidunchanged].
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
|
the value of the serial version UID field in the old version (as decimal number) |
|
the value of the serial version UID field in the new version (as decimal number) |
See Match Parameters for the common match parameters |
Field Visibility Increased - java.field.visibilityIncreased
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
NA |
No API breakage, reported for completeness' sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
|
The visibility of the type as it was in the old version. |
|
The visibility of the type in the new version. |
See Match Parameters for the common match parameters |
Field Visibility Reduced - java.field.visibilityReduced
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
Field’s visibility was reduced, which means that code that used to be able to access it might no longer be able to.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
|
The visibility of the type as it was in the old version. |
|
The visibility of the type in the new version. |
See Match Parameters for the common match parameters |
Enum Constant Order Changed - java.field.enumConstantOrderChanged
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
potentially breaking |
The constants of an enumeration were re-ordered. This can lead to problems in user code that uses the Enum.ordinal()
method to determine the order of an enum constant and relies on a specific value.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the field |
|
The old ordinal number of the enum value. |
|
The new ordinal number of the enum value. |
See Match Parameters for the common match parameters |
Default Value Added To Method - java.method.defaultValueAdded
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
NA |
This is only relevant on annotation types, of which the attributes are represented by method declarations. Declaring a default value to an annotation attribute is not an API breakage and is only reported for completeness' sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the default value of the annotation attribute represented by the method |
See Match Parameters for the common match parameters |
Method’s Default Value Changed - java.method.defaultValueChanged
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
potentially breaking |
This is only relevant on annotation types, of which the attributes are represented by method declarations. Changing a default value is both source and binary compatible but might cause a semantic incompatibility (depending on how the annotation is used). Elements annotated using this annotation that didn’t provide an explicit value for this attribute will suddenly be understood to have the new default value of the attribute when used with the new version of the API. This might or might not be a problem.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the old default value of the annotation attribute represented by the method |
|
the new default value of the annotation attribute represented by the method |
See Match Parameters for the common match parameters |
Default Value Removed From Method - java.method.defaultValueRemoved
Binary severity |
non breaking |
Source severity |
breaking |
Semantic severity |
breaking |
An annotation attribute no longer declares a default value. This is source incompatible change because elements annotated without explicitly specifying the value for the attribute will no longer compile. This also breaks semantics because annotation processor that relies on the new version of the annotation type will break with a user library that was compiled against the old version of the API (and therefore didn’t have to declare the default value of the attribute).
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the removed default value of the annotation attribute represented by the method |
See Match Parameters for the common match parameters |
Method Added To Interface - java.method.addedToInterface
Binary severity |
non breaking |
Source severity |
breaking |
Semantic severity |
potentially breaking |
This is a source-incompatible change because all implementations that were written against the old version of the interface will not have the implementation of the new method and therefore will not compile.
On contrary, this is binary compatible, because no code that used the old version of the interface could have called the method through the interface. The linker doesn’t check for missing method implementations so the linkage also goes without a problem.
There might be semantic problems though. It might break in situations where the interface serves the purpose of an SPI -
a library declares an SPI interface to be implemented by users and then
uses these SPI implementations inside the library. If the new version of the library assumes that the SPI
implementations provide the impl of the new method and it is provided with the SPI implementation of the old version
of the interface, things will break with NoSuchMethodError
when the caller tries to call the SPI method backed by the
old SPI implementation.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
See Match Parameters for the common match parameters |
Default Method Added To Interface - java.method.defaultMethodAddedToInterface
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
NA |
This represents no API breakage and is included for completeness' sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
See Match Parameters for the common match parameters |
Static Method Added To Interface - java.method.staticMethodAddedToInterface
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
NA |
This represents no API breakage and is included for completeness' sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
See Match Parameters for the common match parameters |
Method With No Default Value Added To Annotation Type - java.method.attributeWithNoDefaultAddedToAnnotationType
Binary severity |
non breaking |
Source severity |
breaking |
Semantic severity |
breaking |
While technically a variant of Method Added To Interface, this is similar in consequences to Default Value Removed From Method. This is not binary incompatible, there can be no code compiled against the previous version of the API that would try to access or use the new attribute in any way. This is source incompatible though, because any code that declares annotations according to the old version of the API will fail to compile against the new version of the API because it will not define explicit value for the new attribute. This also breaks semantics because any element annotated without such attribute won’t be possible to process using a processor that depends on the new version of the API and therefore assumes an explicit value for the annotation attribute.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
See Match Parameters for the common match parameters |
Method With Default Value Added To Annotation Type - java.method.attributeWithDefaultAddedToAnnotationType
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
NA |
This does not break compatibility and is reported for completeness' sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
See Match Parameters for the common match parameters |
Abstract Method Added - java.method.abstractMethodAdded
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
Abstract method added to a class. All the code compiled against the old version of the API will not provide a concrete implementation of it and will therefore break.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
See Match Parameters for the common match parameters |
Method Added - java.method.added
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
NA |
A new concrete method added to a concrete class. This is always safe.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
See Match Parameters for the common match parameters |
Final Method Added To Non-final Class - java.method.finalMethodAddedToNonFinalClass
Binary severity |
potentially breaking |
Source severity |
potentially breaking |
Semantic severity |
NA |
This will break user code if the a subclass of the checked class declared a method that happens to have a same signature as the newly introduced final method.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
See Match Parameters for the common match parameters |
Inherited Method Moved To Class - java.method.inheritedMovedToClass
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
NA |
A method that was inherited in the old version is now declared in the class (or interface). This is a compatible change. Note that if the super class is part of the API, the removal of the method from that class will be reported separately.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the class that the method was originally declared in |
|
the class that now declares the method |
See Match Parameters for the common match parameters |
Method Removed - java.method.removed
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
Removing a method from a class is an incompatible change.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
See Match Parameters for the common match parameters |
Method Moved To Superclass - java.method.movedToSuperClass
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
NA |
A method that was declared in the class in the old version is now declared in one of its super types. If such move should represent a compatibility breakage it is reported differently. Otherwise this is a compatible change and is reported for completeness' sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the class that the method was originally declared in |
|
the class that now declares the method |
See Match Parameters for the common match parameters |
Attribute Removed From Annotation Type - java.method.attributeRemovedFromAnnotationType
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
This is identical to Method Removed but specialized for annotation types.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
See Match Parameters for the common match parameters |
Method No Longer Final - java.method.noLongerFinal
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
NA |
No API breakage, reported for completeness' sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the modifiers on the method in the old version |
|
the modifiers on the method in the new version |
See Match Parameters for the common match parameters |
Method Now Final - java.method.nowFinal
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
Any subclasses that overrode the method will break both at compile time and at runtime.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the modifiers on the method in the old version |
|
the modifiers on the method in the new version |
See Match Parameters for the common match parameters |
Method Now Final In Final Class - java.method.nowFinalInFinalClass
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
NA |
The class is final and cannot be subclassed. Therefore making its method final makes no difference.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the modifiers on the method in the old version |
|
the modifiers on the method in the new version |
See Match Parameters for the common match parameters |
Method No Longer Static - java.method.noLongerStatic
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
When a method becomes a member method, it no longer can be called from the static context. This breaks both binary and source compatibility.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the modifiers on the method in the old version |
|
the modifiers on the method in the new version |
See Match Parameters for the common match parameters |
Method Now Static - java.method.nowStatic
Binary severity |
breaking |
Source severity |
non breaking |
Semantic severity |
NA |
A static method can be called in the same way as member method, so on the source level, this change is compatible. It is not binary compatible though because static methods are called using a different bytecode instruction.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the modifiers on the method in the old version |
|
the modifiers on the method in the new version |
See Match Parameters for the common match parameters |
Method Now Abstract - java.method.nowAbstract
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
If a method becomes abstract, all the inheriting classes will have to implement it even though they didn’t have to before.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the modifiers on the method in the old version |
|
the modifiers on the method in the new version |
See Match Parameters for the common match parameters |
Method No Longer Abstract - java.method.noLongerAbstract
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
NA |
This is a compatible change reported for the completeness' sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the modifiers on the method in the old version |
|
the modifiers on the method in the new version |
See Match Parameters for the common match parameters |
Method Visibility Increased - java.method.visibilityIncreased
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
NA |
No API breakage, reported for completeness' sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
The visibility of the type as it was in the old version. |
|
The visibility of the type in the new version. |
See Match Parameters for the common match parameters |
Method Visibility Reduced - java.method.visibilityIncreased
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
A method might no longer be visible to code that used to call it. This is a breaking change.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
The visibility of the type as it was in the old version. |
|
The visibility of the type in the new version. |
See Match Parameters for the common match parameters |
Method Return Type Changed - java.method.returnTypeChanged
Binary severity |
breaking |
Source severity |
potentially breaking |
Semantic severity |
NA |
While changing the return type always breaks at runtime (i.e. when swapping the new API for the old API without recompiling the user code), it might be OK at compile time due to implicit conversions of primitive types.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the old return type |
|
the new return type |
See Match Parameters for the common match parameters |
Method Return Type Changed Covariantly - java.method.returnTypeChangedCovariantly
Binary severity |
breaking |
Source severity |
non breaking |
Semantic severity |
NA |
Covariant return types represent no problem on source level because the new return type can always be cast to the old
return type and therefore the users of the old version of the API can work with the new type. This a binary
incompatibility though because the method signature changes and users of the old version of the API would get nasty
NoSuchMethodError
errors at link time.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the old return type |
|
the new return type |
See Match Parameters for the common match parameters |
Type Parameters of The Return Type Changed - java.method.returnTypeTypeParametersChanged
Binary severity |
non breaking |
Source severity |
breaking |
Semantic severity |
NA |
If the return type of the method is a generic type and its type parameters change between old and new version of the API it is a source incompatible change. It is binary compatible because of type erasure.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the old return type |
|
the new return type |
See Match Parameters for the common match parameters |
Number of Method Parameters Changed - java.method.numberOfParametersChanged
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
Obviously, this is a breaking change - you can no longer call the method with the same parameters.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
See Match Parameters for the common match parameters |
Method Parameter Type Changed - java.method.parameterTypeChanged
Binary severity |
breaking |
Source severity |
potentially breaking |
Semantic severity |
NA |
This is a binary incompatibility but may be source compatible if the changed types are primitive and the new one is strictly bigger than the old one and the old one is implicitly convertible to it.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the index of the method parameter |
|
the old type of the parameter |
|
the new type of the parameter |
See Match Parameters for the common match parameters |
This difference is not reported when overloads matching is turned off. |
Method Parameter Type Parameter Changed - java.method.parameterTypeParameterChanged
Binary severity |
non breaking |
Source severity |
potentially breaking |
Semantic severity |
NA |
This problem is reported on method parameters with a generic type if one or more of the type parameters of the generic type changed. This is binary compatible because of the type erasure but it can break source compatibility.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the index of the method parameter |
|
the old type of the parameter |
|
the new type of the parameter |
See Match Parameters for the common match parameters |
This difference is not reported when overloads matching is turned off. |
Method Now Throws a Checked Exception - java.method.exception.checkedAdded
Binary severity |
non breaking |
Source severity |
breaking |
Semantic severity |
NA |
A method now throws a checked exception. This binary compatible but is not source compatible because the code using the new version of the method will have to be modified to handle the checked exception.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the fully qualified name of the added exception type |
See Match Parameters for the common match parameters |
Method Now Throws a Runtime Exception - java.method.exception.runtimeAdded
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
potentially breaking |
This is both source and binary compatible but represents a danger for the semantics of the user code that might want to catch the newly thrown exception.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the fully qualified name of the added exception type |
See Match Parameters for the common match parameters |
Method No Longer Throws a Checked Exception - java.method.exception.checkedRemoved
Binary severity |
non breaking |
Source severity |
breaking |
Semantic severity |
NA |
A method no longer throws a checked exception. This binary compatible but is not source compatible because the code using the new version of the method fail to compile - the checked exception can no longer be thrown from the method and therefore the catch clauses for it will be invalid.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the fully qualified name of the removed exception type |
See Match Parameters for the common match parameters |
Method No Longer Throws a Runtime Exception - java.method.exception.checkedRemoved
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
NA |
This is a compatible change added for completeness' sake.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the fully qualified name of the removed exception type |
See Match Parameters for the common match parameters |
Method Now Default - java.method.nowDefault
Binary severity |
equivalent |
Source severity |
equivalent |
Semantic severity |
NA |
The method is now a default method. This is completely transparent.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the modifiers on the method in the old version |
|
the modifiers on the method in the new version |
See Match Parameters for the common match parameters |
Method No Longer Default - java.method.noLongerDefault
Binary severity |
breaking |
Source severity |
breaking |
Semantic severity |
NA |
The method is no longer default. This means that any implementations of the inteface with the method will now have to supply an implementation for it.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
the name of the method added |
|
the modifiers on the method in the old version |
|
the modifiers on the method in the new version |
See Match Parameters for the common match parameters |
Element Now Parameterized - java.generics.elementNowParameterized
Binary severity |
non breaking |
Source severity |
non breaking |
Semantic severity |
potentially breaking |
In and of itself, this is a compatible change but may cause semantic confusion if the user code compiled against the old
API wasn’t honoring the new semantics introduced with the generic type parameter (e.g. old code was using raw List
and
the new version of the API parameterized the list to List<E>
. The old code used to insert variety of types into the
list but the new version of the API suggests it is not possible. Everything will still work correctly, but new user code
might start assuming uniform types in the list).
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
Optionally |
|
|
the name of the method if it is the newly parameterized element |
See Match Parameters for the common match parameters |
Formal Type Parameter Added - java.generics.formalTypeParameterAdded
Binary severity |
non breaking |
Source severity |
breaking |
Semantic severity |
NA |
This is not a binary incompatibility due to type erasure but it is a source incompatible change. Classes declared against the old version of the API will no longer compile with the new version because they will be missing the definition of the formal type parameter.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
Optionally |
|
|
the name of the method if it is the newly parameterized element |
See Match Parameters for the common match parameters |
Formal Type Parameter Removed - java.generics.formalTypeParameterRemoved
Binary severity |
non breaking |
Source severity |
breaking |
Semantic severity |
NA |
This is not a binary incompatibility due to type erasure but it is a source incompatible change. Classes declared against the old version of the API will no longer compile with the new version because they will be declaring a type parameter that is no longer required.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
Optionally |
|
|
the name of the method if it is the newly parameterized element |
See Match Parameters for the common match parameters |
Formal Type Parameter Changed - java.generics.formalTypeParameterChanged
Binary severity |
non breaking |
Source severity |
breaking |
Semantic severity |
NA |
The constraints on the formal type parameter have changed. This is again source incompatible because the user code declared against the old version of the API will use wrong constraints.
Match parameters | |
---|---|
|
the package of the class |
|
the fully-qualified name of the class |
|
the simple name of the class |
|
The old type parameter that changed. |
|
The new type parameter. |
Optionally |
|
|
the name of the method if it is the newly parameterized element |
See Match Parameters for the common match parameters |