-
-
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
improved method arities on become_java! #3779
Conversation
If you mean just applying the test cases provided by each issue's discussion, I can do that, sorry I didn't get to it earlier So far, 449 is not fixed, reduced test case provided by Byteit:
Still breaks with InstantiationException:
Would like to notice that it may be because I have the wrong files, I'm not 100% sure. I will test the rest of the cases, but as I reported on IRC, the issue 3206 also breaks, unexpectedly:
Problem is, as you saw on the test for 449, it should not break, the only key difference between this test and the other is that the test for 449 inherits an actual Java class I will test the other cases later on, but if these problems are of my build or new problems that arise with these changes, I'm worried. Of course, not to tick out the possibility that I may've done something wrong using Git, but all file checkings prove otherwise. |
#3206 missed a require but you might have noticed that you did a #449 is definitely not fixed - so I was wrong assuming its just the var-args, thanks for confirming that one! |
Yeah, I knew about the require statement, I must've assumed that I already imported it (I did all the tests in the same irb session) so that's my bad, sorry. I got a problem when instantiating the result of become_java on #3206 because it says "new" doesn't exist for that class. I know it's not from the issue itself, but it might be important for the others
In issue #1925 I cannot complete the tests because I don't know what I need to do to generate "proxied_java_object" #3206I can confirm it's not fixed, specified java signature is still not respected at runtime, provided test case yields same problem:
As opposed to intented signature #3454Also seems to remain unfixed, I used the same code provided in the example test case, exported it into a .jar, wrote the rb file and executed it (here you have the code for easy testing)
The last bit of the stack trace was not presented by the issue owner, I assume because it was not necessary to troubleshoot the problem. |
…ing) signatures previously all method arities ended up as var-args : `foo(IRubyObject[] args)` now for fixed arities we'll have correct number of args e.g. `foo(IRubyObject arg1)` ... we still generate var-args: `foo(IRubyObject[] args)` for all non-fixed arity sizes! resolves #3206 and likely #449 also #3366 (java_signature is now honored)
... one synchronized reify method is enough
OK, thanks I rebased and added some (minor) improvements.
never worked, and we likely do not need a #3206 notes on issue - its fixable by re-architecting |
…(closing #3454) ... much less confusing than for user classes to see the nearest reified class in the inheritance hierarchy (without explicitly doing `become_java!`)
added auto-reify behavior of Ruby classes when they're being converted to a |
just in time for 9.1 as this might be considered a "breaking" change at the binary (Java reflective) level.
the change is pretty much explained in the commit message: 2f363d0
most users, of Ruby user-types entering Java land, complained about the previous behaviour - so this is a welcoming change. Ruby fixed arities will now be much more intuitive on the Java side.
// cc @Lan5432
... if you're interested you could confirm whether this resolves some/all of the related issues :
support newInstance() with arguments #449