Hello,
Thank you all for your feedback. What I'm hearing here is that binary
compatibility is vital between releases but source compatibility can
be changed with proper documentation and notifications. This is good
to know. For this release, I do not see a compelling reason to break
source
On Mon, 20 Jun 2022 at 15:26, Gary Gregory wrote:
>
> It is OK with me because _binary_ compatibility is what matters most and
> that is maintained.
>
> If you are compiling your code against a new version of a library, then
> changing source files is fair game IMO.
I agree that binary
It is OK with me because _binary_ compatibility is what matters most and
that is maintained.
If you are compiling your code against a new version of a library, then
changing source files is fair game IMO.
Gary
On Sun, Jun 19, 2022, 10:50 Matt Juntunen wrote:
> Hello,
>
> The throw clauses in
Hello.
Le lun. 20 juin 2022 à 04:25, Matt Juntunen
a écrit :
>
> Is someone able to confirm that the
> METHOD_NO_LONGER_THROWS_CHECKED_EXCEPTION japicmp compatibility change
> is something we're ok with between releases? Note that this is a
> binary compatible change but not a source compatible
I think there used to be a page listing what changes were allowed when
changing major, minor and patch version numbers.
This may have been in the Wiki rather than the main website.
I could not find it just now, but have not spent much time looking for it.
If/when it is found, it probably needs to
Is someone able to confirm that the
METHOD_NO_LONGER_THROWS_CHECKED_EXCEPTION japicmp compatibility change
is something we're ok with between releases? Note that this is a
binary compatible change but not a source compatible one.
Regards,
Matt J
On Sun, Jun 19, 2022 at 10:50 AM Matt Juntunen
Hello,
The throw clauses in question are on protected methods. If a user had
overridden these and then thrown an exception, they may have to modify
their source in order to compile against 2.8. Is this ok from the
point of view of our backwards compatibility guarantees?
Regards,
Matt J
On Sun,
This change is incorrect, binary compatibility was NOT broken as the JLS
specifies that:
"Changes to the throws clause of methods or constructors do not break
compatibility with pre-existing binaries; these clauses are checked only at
compile time."
See
