On 27.10.22 22:51, Ernie Rael wrote:
The code is like:
if (mi.getSpecificationVersion().compareTo(
new SpecificationVersion("9.26")) >= 0) // >= NB-16
see, I don't understand why this wouldn't work. There is nothing
ambiguous here. The call site should be still compatible for this
kind of usage.
anyway... revert is pending. Learned something new.
Wondering what you've learned.
Users will find ways to break things ;)
The compiler will link against the generic version (which only accepts
SpecificationVersion) of the method if you build against NB 16rc1. So if
you want it to be backwards compatible you have to link against NB 15 or
whatever your minimum target version is just to be sure.
You should do that anyway btw. Build against your minimum requirement.
Test on all deployment scenarios. This is the only safe way to be sure
you are compatible.
javac has the -release flag which solves basically the same issue just
on the JDK level (and is much safer than the -source/-target combo). it
has a bunch of ct.sym files in the JDK which are essentially signature
deltas which allows applications to link to old JDK APIs safely just by
changing the number behind -release. In the old days you had to write
code on JDK X if you deployed on JDK X to be safe. The release flag
allows to write code on JDK X+N safely while targeting anything between
X and X+N.
NB doesn't have that but since its in maven central it has a similar
effect if you build against the correct artifacts ;)
Thats also the reason why I don't think this actually breaks
compatibility in a bad away. But since its such trivial change and
fairly unrelated to the original change in the PR (as I mentioned in the
discussion there), its not really worth spending much time on. Lets
revert it or not - whatever causes less friction. (Would be good to keep
it since its a cleanup though)
I'm still confused. I always thought generics were syntactic sugar,
nah they do influence method signatures, add bridge methods you never
wrote etc. Its more than just compile time checks.
Matthias showed the javap results for this particular case in the other
mail.
-mbien
and they became Object at runtime. I can kind of rationalize why it's
failing, but it's more than just generics.
Anyway, I'll build delivery and try it, if (I hope when) the revert
gets merged.
-ernie
---------------------------------------------------------------------
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
