<nirvdrum[m]> Congrats on the 9.3.4.0 release. FYI, the channel topic still refers to 9.3.3.0.
<headius> Ah yes
<headius> Thanks
<JasonLunn[m]> Good morning, all. FYI, I was moving faster than I was thinking yesterday, and didn't notice until this morning that I'd filed https://github.com/protocolbuffers/protobuf/issues/9668 on protobuf rather than JRuby. I closed the that issue and added the content there into a comment on https://github.com/jruby/jruby/issues/7154 instead.
<JasonLunn[m]> Apologies for the deck chair shuffling.
<headius> Yeah I was wondering about that but no worries. I'll be at my desk shortly and we'll figure out a good work around
<headius> Jason Lunn: I see the setBuiltin workaround got you past that point
<headius> I will push a fix today for review that reduces isBuiltin to only methods defined during JRuby core boot
<JasonLunn[m]> Yep - thanks for the think of that. I'm effectively unblocked.
<JasonLunn[m]> headius: did you see my follow up emails re: grpc?
<headius> it will continue to work with this change, and we'll see about deprecating isBuiltin and replacing with something more descriptive in JRuby X
<headius> oh shoot I did not... I will look today
<JasonLunn[m]> Still looking for good proxies for |JRuby| as a percentage of |Ruby|
<headius> $ jruby -X-C -r ./respond_to_java.jar -w -e 'Foo::Bar.new.respond_to? :foo'
<headius> Custom repond_to? got called!
<headius> 👍
<headius> Jason Lunn enebo: https://github.com/jruby/jruby/pull/7156
<JasonLunn[m]> Does it still matter whether or not definition of the respond_to? is a static method or not?
<headius> it does... I am still not clear how it was called as an instance method, since you'd have to have an instance of a RespondTo in hand, but if you want to define it this way it should be static
<headius> it could just be on the service as well, but perhaps in the real code there are other classes being set up there
<headius> ... on the service as a static method also
<headius> it can only be an instance method if you are setting up a Ruby class that is specifically bound to a Java class that extends RubyObject or RubyBasicObject etc
<headius> enebo: I will get those wip run fixes pushed shortly, just looking into a couple TCPSocket things that fail only in the full run
<headius> addbin
<headius> oops
<enebo[m]> addbin
<enebo[m]> ok
<JasonLunn[m]> RespondTo does extend RubyObject...
<headius> yes but you are not binding it as any Ruby class
<headius> so you were setting up instance methods from RespondTo as methods on Bar, which is not a RespondTo
<JasonLunn[m]> Maybe my example is just different enough from how protobuf does it that I'm tripping on this.
<JasonLunn[m]> Our RubyMessage class has always defined its method_missing using a non-static method
<JasonLunn[m]> so I thought I'd be able to define the respond_to? the same way
<headius> probably because you have a RubyMessage class in JAva
<headius> can you show me?
<JasonLunn[m]> But perhaps the Foo::Bar example is not close enough to the lib to replicate that
<headius> if you wanted to define "Bar" that way, you'd rename RespondTo to Bar and use its constructor as the allocator for the "Bar" Ruby class
<headius> then you could use instance methods
<headius> otherwise you are trying to use instance methods from the RespondTo class, and Bar is just being allocated as a RubyObject so it does not have those methods
<headius> public class RubyMessage extends RubyObject
<headius> I don't see where this class is being set up though
<headius> the others all have initialization code to set up the Ruby side
<JasonLunn[m]> Probably part of my problem in constructing a simple example. I'm probably missing an easier, simpler example where the BasicLibraryService of my example just loads an annotated class without defining an allocator
<JasonLunn[m]> but I couldn't figure out how to do that so I stole the allocator example I had on hand
<headius> MessageExts
<headius> oops
<headius> the RubyMessage class is being set up there with an allocator to construct RubyMessage instances
<headius> so whenever you have a RubyMessage instance in Ruby it is a RubyMessage in Java and so the instance methods are appropriate
<headius> your example did not allocate RespondTo instances for Bar, so the instance methods could not be present on Bar
<headius> not sure why this one piece of initialization is not homed with the class it defines, but that's it
<headius> perhaps just to mimic the C code
<JasonLunn[m]> Cool, I think I grok it better now.
<headius> you can bind methods even if you don't set up a special class and allocator, but since they will not live on RubyObject they need to be static
<headius> it's just binding function pointers into a method table, but when it eventually dispatches against the object they need to be there, or they need to be static and pass the object in
<enebo[m]> cool
<enebo[m]> ship it
<headius> looks like it completed, merging
<byteit101[m]> enebo: had a chance to test jrubyfx master with 9.3.4?
<enebo[m]> byteit101: I have not no
<byteit101[m]> hoping to release 2.0 this evening. Works on my computer, but I'd like to ensure it works on others too :-)
<enebo[m]> Let me see if my laptop has an fx jdk.
<enebo[m]> byteit101: is there a section of where to get fx-enabled JVM for the project
<enebo[m]> I remember you get get it with zulu?
<byteit101[m]> I though I wrote something about that...
<byteit101[m]> oh I put it in the blog post
<byteit101[m]> yes, I'll copy that note to the readme
<byteit101[m]> good call
<enebo[m]> cool. I am getting a jdk with it now
<enebo[m]> any ideas?
<byteit101[m]> you set java home?
<enebo[m]> echo $JAVA_HOME
<enebo[m]> /home/enebo/Applications/jdks/zulu18.28.13-ca-fx-jdk18.0.0-linux_x64
<byteit101[m]> did you set JFX_DIR to the mods folder?
<enebo[m]> nope
<enebo[m]> I can try that
<byteit101[m]> shouldn't be necessary, but this sounds like that one issue again
<enebo[m]> Is there something with jmods at play here?
<byteit101[m]> could be
<enebo[m]> ok java -list-modules shows the javafx jmods
<enebo[m]> no such file to load -- jfxrt.jar
<enebo[m]> I printed out the exception cause
<byteit101[m]> hmm, works with 17
<byteit101[m]> for me
<enebo[m]> you had me add JFX_DIR so that might be part of this particular error
<byteit101[m]> unsure
<byteit101[m]> 17 doesn't have jfxrt.jar either
<enebo[m]> heheh
<enebo[m]> hahah
<enebo[m]> # require 'jfxrt.jar'
<enebo[m]> # require 'jfxrt.jar'
<enebo[m]> ```# require 'jfxrt.jar'```
<enebo[m]> I commented it out and it built
<enebo[m]> oh I still have JFX_DIR set somehow
<byteit101[m]> If you unset PATH_TO_FX and JFX_DIR does it work with it not commented out?
<enebo[m]> I just removed that env and I get an error now
<enebo[m]> and if I remove the require I get the same error
<byteit101[m]> same or different?
<enebo[m]> ok I am back to original error
<enebo[m]> I for undefined method '[]' for nil if I tried to print $!
<byteit101[m]> ?
<enebo[m]> yeah I have no idea what that is ```puts $!``` where error message is caught will cause that
<byteit101[m]> some java classes have weird errors when printed
<byteit101[m]> it's what makes javafx unique™
<enebo[m]> ok I think the issue is since it worked once part_imports get replaced by imports which picked up my changes
<byteit101[m]> could be, though that's the other way around (part_imports is the template for imports)
<enebo[m]> no such file to load -- org/bouncycastle/bcutil-jdk15to18/1.68/bcutil-jdk15to18-1.68.jar (LoadError)
<byteit101[m]> that... is... what???!?!?!
<byteit101[m]> i don't think jrubyfx references bouncycastle
<enebo[m]> This might have something to do with jruby itself but I am pretty confused by this
<enebo[m]> Doing a full rebuild using a newer JVM of JRuby to see if that changes it
<enebo[m]> So I am thinking that extra failed load is unrelated
<enebo[m]> That is something with jruby-openssl loading I believe
<enebo[m]> I was just printing out all errors
<enebo[m]> If I comment out all the jar loading code I can run a sample localling (e.g. jruby -Ilib samples/jrubyfx/analog_clock)
<byteit101[m]> if ENV['JFX_DIR'] or
<byteit101[m]> jre[:version].to_f < 1.8 or
<byteit101[m]> (jre[:version].to_f == 1.8 and jre[:release] == 'ea' and jre[:build].to_i < 75)
<byteit101[m]> ^ you are getting past that conditional?
<byteit101[m]> but commenting out the body works?
<enebo[m]> Well I also commented that out but I am looking at it now
<byteit101[m]> jruby 9.3 doesn't support 1.7, right? if so I could remove lines 24-33 as that is for java 7
<enebo[m]> JRUBY_OPTS="-d -Xbacktrace.style=raw" ~/work/jruby-9.3/bin/jruby -e 'p ENV_JAVA["java.runtime.version"]; jre = ENV_JAVA["java.runtime.version"].match %r{^(?<version>(?<major>\d+)\.(?<minor>\d+))\.(?<patch>\d+)(_\d+)?-?(?<release>ea|u\d)?(-?b(?<build>\d+))?}; p jre'
<enebo[m]> "18+37"
<enebo[m]> nil
<byteit101[m]> Ah!
<enebo[m]> So jre is nil
<enebo[m]> jre[:version] boom
<byteit101[m]> zulu 17 is ""17.0.2+8-LTS"" what's 18's string?
<enebo[m]> java -version
<enebo[m]> OpenJDK Runtime Environment Zulu18.28+13-CA (build 18+37)
<enebo[m]> openjdk version "18" 2022-03-22
<enebo[m]> OpenJDK 64-Bit Server VM Zulu18.28+13-CA (build 18+37, mixed mode, sharing)
<enebo[m]> but the java.runtime.version is "18+37"
<byteit101[m]> ew, ok
<byteit101[m]> jruby 9.3 is java 8+ right?
<enebo[m]> so I think bullet-proofing this would be to say if you cannot parse this then assume it will just be >9
<enebo[m]> It is
<byteit101[m]> cmomitting che.. .angholdon
<byteit101[m]> good lord i think my keybaord is screwy
<enebo[m]> I wonder if we could look for something which indicates it uses modules as a property value and not do this version checking
<byteit101[m]> mean to say: "committing change... hold on"
<byteit101[m]> pushed, give it a pull and reinstall
<enebo[m]> jruby -e 'begin; java.lang.module.ModuleFinder; rescue NameError; puts "NO MODULES"; end'
<byteit101[m]> still works on zulu 17 and openjdk 8, but I dropped java 7 support, so jre is no more
<byteit101[m]> enebo: let me know if the changes I just pushed to master work for zulu 18
<enebo[m]> byteit101: works on zulu18
<byteit101[m]> yay!
<enebo[m]> Good thing you got me to try this. Also I guess it is fine to remove java 7 support :)
<byteit101[m]> yes indeed!
<byteit101[m]> do all the samples/contrib run for you?
<enebo[m]> heh
<enebo[m]> what is your other gem?
<enebo[m]> NameError: uninitialized constant FXCollections
<byteit101[m]> I'm most curious about contrib/fxmltableview as it uses the ivar support added in 9.3.4, the table should have one column centered
<byteit101[m]> there is no other jrubyfx-fxmlloader gem anymore in 2.0 :-)
<enebo[m]> ~/work/jruby-9.3/bin/jruby samples/contrib/collections_demo.rb
<enebo[m]> NameError: uninitialized constant FXCollections
<byteit101[m]> oh, is it found in imports.rb?
<byteit101[m]> oh I see the problem
<byteit101[m]> I must complain about that error, which I've seen before. "no method X, did you mean X"
<enebo[m]> Ruby decided to bundle did_you_mean gem and so we do also but there might be a way to turn it off when jrubyfx starts
<byteit101[m]> sorry, "no method Y, did you mean X" is helpful, but when X==Y, something is wrong
<byteit101[m]> what os are you on? linux or mac?
<enebo[m]> fedora core linux
<byteit101[m]> ok, I think I'll have to investigate that later, as that sample works fine for me
<enebo[m]> everything else did run
<byteit101[m]> oh good!
<enebo[m]> the binding examples do not exit but that might be as expected
<byteit101[m]> correct
<enebo[m]> analog_clock works
<byteit101[m]> well, maybe the release will be saturday instead of today, as service and tableview both work for me
<enebo[m]> tree_view.rb has the same issue for me with no updateItem super class method
<byteit101[m]> did the arity change in 18?
<enebo[m]> of what in particular?
<byteit101[m]> updateItem
<byteit101[m]> I seem to recall the X not found, did you mean X being an arity error
<enebo[m]> isn't this all about version of fx itself or is fx also 18
<byteit101[m]> latter
<byteit101[m]> updateItem is protected
<byteit101[m]> will have to look in more detail after work
<enebo[m]> ok
<byteit101[m]> huh
<byteit101[m]> so jfx 18 must have changed stuff
<byteit101[m]> got the same errors when I use jfx18
<byteit101[m]> Oh, this error is interesting, may be a jruby bug. Does jruby look up the entire class chain for protected methods?
<headius> For normal Java integration we only bind public methods generally
<byteit101[m]> then how did this work before?
<byteit101[m]> just trying to call a protected method from a ruby class extending a java class
<headius> Have you been running this on a Java 9+ VM?