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

[ji] deterministic Java bean-style method aliases #4435

Merged
merged 2 commits into from Jan 17, 2017

Conversation

Projects
None yet
1 participant
@kares
Member

kares commented Jan 11, 2017

discovered during the investigation of #4432 (this addresses a different issue)

turns out the priority logic for setting up Java methods into Ruby land did not handle potential alias-ing conflicts for getters (same priority).

this test would periodically fail (more on travis-ci than locally always using the same JVM installation) ... JRuby already dealt with the non-determinstic case get/is issue before while generating wrappers: #3470

here we're making sure we always do the same setup for (unusual) cases with multiple getters for the same property e.g. getFoo() and isFoo() :

  • foo is aliased to getFoo() (current state is that this is not always true and might point to isFoo())
  • foo alias would point to isFoo() only if the getFoo() is not present
[ji] deal with conflicting get/is Java method alias (for real)
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 #3470

due compatibility we can not fix #4432
isAnnotation() + getAnnotation(param) case is different since the get
method isn't a (real) getter (and we're avoding a clash due #3262)

@kares kares merged commit 11c23a9 into jruby:master Jan 17, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment