JRuby 9.4.3.0 soon!

[Charles Oliver Nutter]

We are hoping to kick out JRuby 9.4.3.0 very soon! Tomorrow I'll start
reviewing targeted bugs, but I can certainly use some help figuring
out what else we want in this release. If you have a pet bug you would
like to try to get fixed or a few minutes to spare to help us fix the
others, reply here or stop by the Matrix channel!

Let's make this a good one!

[Mohit Sindhwani]

Thanks for the hard work always, Charles and Enebo!

Looking forward to this.

Best regards,
Mohit.

[david]

El martes 23 de mayo, Charles Oliver Nutter escribió:

#7220 is marked for resolving in 9.3.11.0. It applies to other classes, like
some themes on Windows. I don't know if there is a plan for this.

Thanks.

--
David

[Charles Oliver Nutter]

On Wed, May 24, 2023 at 2:04 AM david <brom...@gmail.com> wrote:
> #7220 is marked for resolving in 9.3.11.0. It applies to other classes, like
> some themes on Windows. I don't know if there is a plan for this.

There's no planned resolution because this is a tricky issue to solve.
The workaround of using `--add-opens` is pretty good, and ultimately
some form of that will probably be necessary given Java 17 locking
down modules completely.

I do believe we should take another look at this, but it would not
happen in a JRuby 9.3.x release most likely. We do have an opportunity
with the new "real" subclass work that Patrick P (byteit101) did to
dispatch these super calls to the actual protected superclass method,
similar to how we use core rewriting to allow initialize to call the
superclass's constructor. Such dispatches would get routed directly to
the Java superclass method rather than through Ruby method dispatch in
the cases where we see there's a Java method available to call (even
if it is not bound in Ruby). The other option would be to start
binding all these methods but mark them with appropriate visibility
(e.g. Ruby protected for Java protected) and handle dispatching via
super and Ruby method lookup by using invokedynamic to call the right
method from the right source (the "real" subclass).

I'll see if I can get Patrick to jump in on this issue and will update
it with what I said above.