[ji] continued cleanup of JavaClass and friends#7164
Closed
kares wants to merge 30 commits intojruby:jruby-9.3from
Closed
[ji] continued cleanup of JavaClass and friends#7164kares wants to merge 30 commits intojruby:jruby-9.3from
kares wants to merge 30 commits intojruby:jruby-9.3from
Conversation
this is a source of confusion when some APIs return a Java proxy while others wrap into a JavaObject (e.g. == checks fail but inspect shows seemingly the same object) for JavaArray JRuby has the same API with its ArrayJavaProxy
kares
force-pushed
the
ji-java-class-cleanup_9.3
branch
from
c1c782c to
b5eec49
Compare
kares
commented
Apr 5, 2022
| } | ||
|
|
||
| if (ctor == null) { | ||
| JavaObject jo = (JavaObject) initialize.call(context, self, clazz, "new", args); |
Member
Author
There was a problem hiding this comment.
@byteit101 not sure how well this branch or the whole method actually is covered with tests.
using JRuby's Java integration related suites I wasn't able to hit this ctor == null branch ...
and the many TODOs left around just confused me, the change should be backwards compatible but still could use your 👀
Member
There was a problem hiding this comment.
This is possible to hit, but only with nonstandard and untested configurations. See the java class configurator, ruby ctor boolean.
this class while being a ghost of Java::JavaConstructor also had other responsibilities - used as a Java wrapper
byteit101
reviewed
Apr 5, 2022
while internal ones (some of which are public but deprecated) stay at the Impl sub-class
JavaClass was revamped and deprecated (on Ruby side) in 9.3 the JavaClass constant still works as in 9.3 (= java.lang.Class)
kares
force-pushed
the
ji-java-class-cleanup_9.3
branch
from
c6b80b4 to
a81003f
Compare
kares
force-pushed
the
ji-java-class-cleanup_9.3
branch
from
a81003f to
cda2544
Compare
enebo
reviewed
Apr 14, 2022
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
WiP - proof of concept (testing against 9.3 due CI - expected to re-target against master - 9.4)
The motivation here is to cleanup Java Integration, avoid the duality of wrapping Java objects as to reduce user confusion when e.g. facing
JavaObjectvs a Java proxy, also shipping new features becomes easier ...This is a follow-up on the work done in 9.3 to eliminate
JavaClass: #6513It takes things few steps further, namely:
JavaObjectandJavaArraywrapper (they still exist and point toJavaProxy/ArrayJavaProxy)JavaObject.wrapbut even that is going to function to some extent as a lot of the existing 'unwrapping' methods still hande the deprecated typeJavaClassand friends was already deprecated in 9.3 we can now remove the Ruby impl methodsJavaConstructoris smt still use internally (had 2 responsibilities) - thus stayed non-deprecatedsynchronized { }was adjusted to yield the actual value we're synchronizing (previously yieldednil)JavaSupportvsJavaSupportImplmethods are now split between the 2 -runtime.getJavaSupport()in an ext so have clearly the methods user usable thereJavaSupportImpl(the methods are deprecated inJavaSupport)JavaClassAPI is now moved elsewhere (the class is now deprecated), we still use some of it's API internally but the most crucial ones have been moved and can be used by the user e.g.JavaUtil.getJavaClass