On Thu, 27 Oct 2022 at 20:14, Matthias Bläsing <mblaes...@doppel-helix.eu> wrote: > Am Donnerstag, dem 27.10.2022 um 20:32 +0200 schrieb Michael Bien: > > 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
I'm not sure that's correct from the JVM perspective. The Object method should still be generated as a bridge? It should be backwards compatible but it's not forwards compatible? Anything compiled against 15 should run on 16, but anything compiled against 16 won't run on 15? I still think it's probably a good idea to revert in this particular case though. Best wishes, Neil --------------------------------------------------------------------- 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
