On 28.10.22 18:14, Ernie Rael wrote:
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,
you build with all safeties off. To maintain compatibility that way you
would need a lot more testing since the compiler can't help you with
safety. Search for "ByteBuffer NoSuchMethodError" for a taste.
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.
nobody is surprised. If you would have read the PR you would have seen
that the signature change was discussed before integration and rightly
considered harmless. I also left the small refactoring in a separate
commit, without squashing the PR so that in the event someone of us
overlooked something it would be trivial to revert.
Tired me yesterday actually kept reading that an existing plugin failed
to run on 16rc1, that is why I said i was wondering why a JVM would not
find that method anymore - which doesn't make any sense in retrospect.
I'm actually amazed that
"don't think this actually breaks compatibility in a bad away"
seems to be a prevailing direction.
well yes, because compatibility is maintained. Existing code will keep
running. New code can enjoy type safety since runtime CCEs are now
compiler errors. Its unlikely here, but generics can sometimes reveal bugs.
And since the type is now known it is also better usable in streams,
which is how I noticed that the generics were missing in the first place.
false alarm :)
-mbien
---------------------------------------------------------------------
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
