bind (abstract) methods when implementing interface #3809
Merged
+287
−27
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
there are two ways Ruby interface implementations are being generated :
Iface.impl { |name, *args| }
both of these add
method_missing
to the Ruby class which leads to issues when there's a naming clash in the hierarchy (e.g.Kernel#test
withjava.util.function.Predicate#test
). these are resolved by binding implemented interface methods on the implementing Ruby class - always executing the desired user provided bits (except where he wouldImplClass.class_eval { def test ... }
the method of course).on the Java (codegen) side, under Java 8, this further revealed that static methods were unnecessarily being generated and that interface's default methods are always being overridden ...
Iface.impl
the behaviour of implementing all methods (including defaults) was kept.impl(:foo, :bar)
already allows for implementing method names to be specified and an additionalimpl(false)
to generate just the minimum abstract method(s) required is introduced. new code also warns onimpl(:foo)
when"foo"
is not actually an interface method.java.util.function.Function#compose
) to work correctly.all-in-all these changes should be welcoming by JI users - it might break compatibility in very corner cases but its usually for the best to review those.
resolves #3475