-
-
Notifications
You must be signed in to change notification settings - Fork 925
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
9k regression on indirect java_class.annotation(java_class) method #4432
Comments
believe this is a collision on setting up ruby aliases for Java methods. the first case works since it returns a |
... unfortunately there's no ordering for the methods thus we have to also deal with foo being aliased for isFoo while processing getFoo foo -> getFoo method shall always win, since foo? is there for isFoo in case both getFoo and isFoo are specified (this is quite unlikely) resolves jruby#4432
... unfortunately there's no ordering for the methods thus we have to also deal with foo being aliased for isFoo while processing getFoo foo -> getFoo method shall always win, since foo? is there for isFoo in case both getFoo and isFoo are specified the update should align nicely with expectations in jruby#3470 due compatibility we can not fix jruby#4432 isAnnotation() + getAnnotation(param) case is different since the get method isn't really a getter (and we're avoding a clash due jruby#3262)
currently we're nondeterministic and depend on reflected method order foo -> getFoo method shall always win, since foo? is there for isFoo in case both getFoo and isFoo are specified the update should align nicely with expectations in jruby#3470 due compatibility we can not fix jruby#4432 isAnnotation() + getAnnotation(param) case is different since the get method isn't a (real) getter (and we're avoding a clash due jruby#3262)
this lead me to realize there's still non-determinism with get/is aliases although this does not clasify for that. the previous 1.7 behaviour was unfortunate since it would lead to confusing cases such as #3262
this might sound weird but its better than 1.7 (believe alias-ing might just stay order dependent there). you should refactor your code to use interestingly the order of methods locally seems pretty deterministic (hard to get a failing test) but on travis-ci I was able to reproduce the issue with getFoo/isFoo Ruby aliasing (shall put that in another report). |
currently we're nondeterministic and depend on reflected method order foo -> getFoo method shall always win, since foo? is there for isFoo in case both getFoo and isFoo are specified the update should align nicely with expectations in jruby#3470 due compatibility we can not fix jruby#4432 isAnnotation() + getAnnotation(param) case is different since the get method isn't a (real) getter (and we're avoding a clash due jruby#3262)
currently we're nondeterministic and depend on reflected method order foo -> getFoo method shall always win, since foo? is there for isFoo in case both getFoo and isFoo are specified the update should align nicely with expectations in jruby#3470 due compatibility we can not fix jruby#4432 isAnnotation() + getAnnotation(param) case is different since the get method isn't a (real) getter (and we're avoding a clash due jruby#3262)
currently we're nondeterministic and depend on reflected method order foo -> getFoo method shall always win, since foo? is there for isFoo in case both getFoo and isFoo are specified the update should align nicely with expectations in jruby#3470 due compatibility we can not fix jruby#4432 isAnnotation() + getAnnotation(param) case is different since the get method isn't a (real) getter (and we're avoding a clash due jruby#3262)
currently we're nondeterministic and depend on reflected method order foo -> getFoo method shall always win, since foo? is there for isFoo in case both getFoo and isFoo are specified the update should align nicely with expectations in jruby#3470 due compatibility we can not fix jruby#4432 isAnnotation() + getAnnotation(param) case is different since the get method isn't a (real) getter (and we're avoding a clash due jruby#3262)
Environment
jruby 1.7.19 (1.9.3p551) 2015-01-29 20786bd on Java HotSpot(TM) 64-Bit Server VM 1.8.0_111-b14 +jit [linux-amd64]
and
jruby 9.1.6.0 (2.3.1) 2016-11-09 0150a76 Java HotSpot(TM) 64-Bit Server VM 25.111-b14 on 1.8.0_111-b14 +jit [linux-x86_64]
Expected Behavior
Actual Behavior
All 1.7 that i've used (since 1.7.3) works as the first, while all the 9.x series that I've tried do the latter. This looks like some funky proxy screw up, as directly referencing MyClass works on 1.7 and 9k:
The text was updated successfully, but these errors were encountered: