Skip to content
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

NoMethodError when calling protected java method from subclass On java 9 #5284

Closed
yamam opened this issue Aug 20, 2018 · 10 comments
Closed

NoMethodError when calling protected java method from subclass On java 9 #5284

yamam opened this issue Aug 20, 2018 · 10 comments

Comments

@yamam
Copy link

@yamam yamam commented Aug 20, 2018

Environment

jruby 9.2.0.0 (2.5.0) 2018-05-24 81156a8 Java HotSpot(TM) 64-Bit Server VM 9.0.4+11 on 9.0.4+11 +jit [mswin32-x86_64]

test.rb

class MyHBox < javafx.scene.layout.HBox
    def layoutChildren
        super
    end
end

MyHBox.new.layoutChildren

Expected Behavior

No error occurs.

Actual Behavior

WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper$ReflectiveAccess to method sun.nio.ch.SelChImpl.getFD()
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper$ReflectiveAccess to field sun.nio.ch.FileChannelImpl.fd
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper$ReflectiveAccess to field java.io.FileDescriptor.fd
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper$ReflectiveAccess to field java.io.FileDescriptor.handle
NoMethodError: super: no superclass method `layoutChildren' for #<MyHBox:0x6d3c232f>
  layoutChildren at test.rb:3
          <main> at test.rb:8
@monkstone
Copy link
Contributor

@monkstone monkstone commented Aug 20, 2018

Hi I reported this earlier but closed the issue because it seems fixed on java 10 (and by now java 9 is history) #4851

@yamam
Copy link
Author

@yamam yamam commented Aug 20, 2018

This issue also occurs on java 10.0.2.

jruby 9.2.0.0 (2.5.0) 2018-05-24 81156a8 Java HotSpot(TM) 64-Bit Server VM 10.0.2+13 on 10.0.2+13 +jit [mswin32-x86_64]

WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper$ReflectiveAccess to method sun.nio.ch.SelChImpl.getFD()
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper$ReflectiveAccess to field sun.nio.ch.FileChannelImpl.fd
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper$ReflectiveAccess to field java.io.FileDescriptor.fd
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper$ReflectiveAccess to field java.io.FileDescriptor.handle
NoMethodError: super: no superclass method `layoutChildren' for #<MyHBox:0x76075d65>
  layoutChildren at test.rb:3
          <main> at test.rb:8
@yamam
Copy link
Author

@yamam yamam commented Aug 21, 2018

javafx is available on java 10.

If you run the script on jruby 9.1.16.0, no error occurs.

$ jruby-9.1.16.0/bin/jruby.exe test.rb
$
@kares
Copy link
Member

@kares kares commented Sep 12, 2018

let's mark this one as a 9.2 regression according to ^^^

@headius
Copy link
Member

@headius headius commented Sep 19, 2018

Bump to 9.2.2 since we've started pushing module stuff forward. We should be able to provide a script in 9.2.2 that generates a set of module flags needed by your JRuby app if any JPMS warnings are being displayed.

@brometeo
Copy link

@brometeo brometeo commented Jul 2, 2019

Hi.

Which is the state of this stuff?. In my enterprise we develop a rich application based on JRuby, both server and client. We are running against Java 8 and can't jump to Java 11 for enjoying its enhancements. I don't know why a regression like this go up unsolved milestone after milestone. Can you explain difficulties and development state? Thank you very much.

@kares
Copy link
Member

@kares kares commented Jul 3, 2019

simply because of priorities - the team does its best with the provided capacity to be able to deliver compatibility fixes and improvements (including better performance).

if its bothering you guys I am sure you tried looking into it, what seems to be the problem you need help with?
the issue here is likely that the super (protected) method does not get bound - due visibility issues doing reflection under modules.

@brometeo
Copy link

@brometeo brometeo commented Jul 3, 2019

Thank you for your explanation :)

I have no doubt about team doing its best. Only two lines for pointing our needs with this issue. If that changes its priority in any way, I don't know. Using Java 8 when Java 11 is out and running seems a little obsolete. Java 11 has garbage collection enhancements that contribute to better performance. Our application is memory hungry. Your work on general performance (memory and launch time) is very good. If a fix for this issue can be expected for 9.2.8.0 as proposed in the milestone, great. If not, I'd like to know why is passed ahead so many times. Not judging your decisions, only trying to influence them for world domination... ;)

Thank you again for all the good work. Apologies for any inconvenient commentaries.

Best regards.

@kares
Copy link
Member

@kares kares commented Jul 3, 2019

simply no one looked into it and not many were affected - complaining, well till now :)
will try to take a look, no promises. feel free to ping us again if you feel neglected ...
unfortunately, there's no easy 'straight-forward' fix so that is the reason why its being pushed.

Java 8 is still superb and stable (JRuby 9.2 works best with 8), its not at all obsolete.
I would not expect much improvement on GC - except maybe if you're using G1 (which you could use on Java 8 as well). have been recently tuning a heavy concurrent, and thus also memory hungry app, and G1 did not make much sense there ... you can get better results by analysing logs and fine tuning some GC details. although that is very application specific, but it definitely is worth considering if you're on the look for better numbers.

@headius
Copy link
Member

@headius headius commented Aug 10, 2019

I suspect this is fixed by my work on #5821, so long as the modules/packages in question have been opened up (so we can set them accessible). Note that issue had a subclass attempting to call a protected superclass method, which now works with my fix.

Take note also of #5823 and #5824 which will make it easier to incrementally "fix" your environment to open up the necessary packages.

@headius headius closed this Aug 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.