On 22/10/28 2:27 AM, Neil C Smith wrote:
On Thu, 27 Oct 2022 at 21:35, Matthias Bläsing
<mblaes...@doppel-helix.eu.invalid> wrote:
Am Donnerstag, dem 27.10.2022 um 20:51 +0100 schrieb Neil C Smith:
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.
you are right and my reasoning was wrong. I looked at the generated
code with javap and there I see:
Thanks for confirming! It was my thought in reviewing the original
PR, but there are so many question marks in the paragraph above
because generics never cease to confuse me! :-)
This got me thinking whether there's a workaround for Ernie to force
the bridge method to be called.
Maybe using raw references? - (at least doing this with String and
testing with javap seems to work) -
Comparable specVersion = mi.getSpecificationVersion();
Comparable reqVersion = new SpecificationVersion("9.26");
if (specVersion.compareTo(reqVersion)) >= 0) { // etc etc
It's still a bad idea to compile against a later platform and expect
it to work on an earlier one, but that might just work in this case.
This practice (what you call a bad idea) has been working for 20 years
with this plugin, and it's not a small plugin. To avoid
misunderstanding, I'm not saying that the current plugin runs on a NB
6.x. I do use module versioning as needed. The current bits run on 12.0
to current. Well, It's been over a year since I tested on 12, and I wish
I could count on the fact that there's been no bug report; but that's
another story.
Given that sigtest failed, I'm surprised that there's so much surprise
that there's an issue. I'm actually amazed that
"don't think this actually breaks compatibility in a bad away"
seems to be a prevailing direction.
I've mentioned before that the plugin bits that ran on NB-8.x ran on
versions going back to NB-7.x. And there was extensive use of
"specVer.compareTo(reqVer)", speak of the devil, so that the plugin
would interoperate well with newer features. And note that with
awareness of new features, the plugin **must** be compiled on a new
release (or use reflection a lot more than the amount the plugin does).
I do not want to have a different source and different binary for each
release. And I certainly don't trust the plugin portal to manage versions.
-ernie
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
