[
https://issues.apache.org/jira/browse/FLINK-33949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wencong Liu updated FLINK-33949:
--------------------------------
Description:
Currently I'm trying to refactor some APIs annotated by @Public in [FLIP-382:
Unify the Provision of Diverse Metadata for Context-like APIs - Apache Flink -
Apache Software
Foundation|https://cwiki.apache.org/confluence/display/FLINK/FLIP-382%3A+Unify+the+Provision+of+Diverse+Metadata+for+Context-like+APIs].
When an abstract method is changed into a default method, the japicmp maven
plugin names this change METHOD_ABSTRACT_NOW_DEFAULT and considers it as source
incompatible and binary incompatible.
The reason maybe that if the abstract method becomes default, the logic in the
default method will be ignored by the previous implementations.
I create a test case in which a job is compiled with newly changed default
method and submitted to the previous version. There is no exception thrown.
Therefore, the METHOD_ABSTRACT_NOW_DEFAULT shouldn't be incompatible both for
source and binary. We could add the following settings to override the default
values for binary and source compatibility, such as:
{code:java}
<overrideCompatibilityChangeParameters>
<overrideCompatibilityChangeParameter>
<compatibilityChange>METHOD_ABSTRACT_NOW_DEFAULT</compatibilityChange>
<binaryCompatible>true</binaryCompatible>
<sourceCompatible>true</sourceCompatible>
</overrideCompatibilityChangeParameter>
</overrideCompatibilityChangeParameters> {code}
By the way, currently the master branch checks both source compatibility and
binary compatibility between minor versions. According to Flink's API
compatibility constraints, the master branch shouldn't check binary
compatibility. There is already jira FLINK-33009 to track it and we should fix
it as soon as possible.
was:
Currently I'm trying to refactor some APIs annotated by @Public in [FLIP-382:
Unify the Provision of Diverse Metadata for Context-like APIs - Apache Flink -
Apache Software
Foundation|https://cwiki.apache.org/confluence/display/FLINK/FLIP-382%3A+Unify+the+Provision+of+Diverse+Metadata+for+Context-like+APIs].
When an abstract method is changed into a default method, the japicmp maven
plugin names this change METHOD_ABSTRACT_NOW_DEFAULT and considers it as source
incompatible and binary incompatible.
The reason maybe that if the abstract method becomes default, the logic in the
default method will be ignored by the previous implementations.
I create a test case in which a job is compiled with newly changed default
method and submitted to the previous version. There is no exception thrown.
Therefore, the METHOD_ABSTRACT_NOW_DEFAULT shouldn't be incompatible both for
source and binary.
By the way, currently the master branch checks both source compatibility and
binary compatibility between minor versions. According to Flink's API
compatibility constraints, the master branch shouldn't check binary
compatibility. There is already jira FLINK-33009 to track it and we should fix
it as soon as possible.
> METHOD_ABSTRACT_NOW_DEFAULT should be both source compatible and binary
> compatible
> ----------------------------------------------------------------------------------
>
> Key: FLINK-33949
> URL: https://issues.apache.org/jira/browse/FLINK-33949
> Project: Flink
> Issue Type: Bug
> Components: Test Infrastructure
> Affects Versions: 1.19.0
> Reporter: Wencong Liu
> Priority: Major
> Fix For: 1.19.0
>
>
> Currently I'm trying to refactor some APIs annotated by @Public in
> [FLIP-382: Unify the Provision of Diverse Metadata for Context-like APIs -
> Apache Flink - Apache Software
> Foundation|https://cwiki.apache.org/confluence/display/FLINK/FLIP-382%3A+Unify+the+Provision+of+Diverse+Metadata+for+Context-like+APIs].
> When an abstract method is changed into a default method, the japicmp maven
> plugin names this change METHOD_ABSTRACT_NOW_DEFAULT and considers it as
> source incompatible and binary incompatible.
> The reason maybe that if the abstract method becomes default, the logic in
> the default method will be ignored by the previous implementations.
> I create a test case in which a job is compiled with newly changed default
> method and submitted to the previous version. There is no exception thrown.
> Therefore, the METHOD_ABSTRACT_NOW_DEFAULT shouldn't be incompatible both for
> source and binary. We could add the following settings to override the
> default values for binary and source compatibility, such as:
> {code:java}
> <overrideCompatibilityChangeParameters>
> <overrideCompatibilityChangeParameter>
> <compatibilityChange>METHOD_ABSTRACT_NOW_DEFAULT</compatibilityChange>
> <binaryCompatible>true</binaryCompatible>
> <sourceCompatible>true</sourceCompatible>
> </overrideCompatibilityChangeParameter>
> </overrideCompatibilityChangeParameters> {code}
> By the way, currently the master branch checks both source compatibility and
> binary compatibility between minor versions. According to Flink's API
> compatibility constraints, the master branch shouldn't check binary
> compatibility. There is already jira FLINK-33009 to track it and we should
> fix it as soon as possible.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
