On 22/10/27 12:33 PM, Michael Bien wrote:
On 27.10.22 21:14, Matthias Bläsing wrote:
Hi,
Am Donnerstag, dem 27.10.2022 um 20:32 +0200 schrieb Michael Bien:
On 27.10.22 20:17, Neil C Smith wrote:
On Thu, 27 Oct 2022, 19:03 Ernie Rael, <err...@raelity.com> wrote:
This is very strange. If I build the plugin on 15 it runs on 15. If I
build it with 16-RC2 it will not install on 15. I noticed this a few
days ago, but wanted to wait for RC2 before mentioning it.
I'll try to narrow it down, wondering if anyone has some ideas
about this.
It'll be caused by https://github.com/apache/netbeans/pull/4678
Downside of adding generics. Still time to review, although I
assume the
reverse situation isn't affected?
i kept it in the second commit and didn't squash just in case we have a
situation like this.
https://github.com/apache/netbeans/pull/4678/commits/50086abd421200ce33bd4508580a80518f350f63
I am still a bit surprised that this causes issues. Since the class is
final which removes an entire can of worms of potential override
issues.
I would have expected the JVM to find the right method in unambiguous
cases like this.
from the JVMs perspective, you removed a method that takes an arbitrary
object and added a method that takes a SpecificationVersion. The
message to the outside is:
- before I was prepare to take any object and will do sane things with
it
- after I will only care about SpecificiationVersion instances
In the implementation the "before" promise is broken as the first
instruction is a checked cast, but it is the developer of the method
breaking other peoples assumptions, not the JVM.
I do get that, its just that it should only break if someone is
calling the method with something which isn't of type
SpecificationVersion. This would have failed at runtime before the
change. It would fail at compiletime after the change - improve the
situation.
SpecificationVersion does not extend anything and is final. So someone
would have to store it as Object somewhere and then call the
Comparable methods. I thought that would be unlikely.
The code is like:
if (mi.getSpecificationVersion().compareTo(
new SpecificationVersion("9.26")) >= 0) // >= NB-16
-ernie
-mbien
TL;DR: This is an API incompatible change and this was caught by
sigtest as the signature file was modified.
I suggest to revert that change as the underlying assumption about
compatible changes was wrong.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
