<enebo[m]>
we can support this but I guess with how we do things this would be a jnr-constants and jnr-posix add for syscall + constant values
<enebo[m]>
The feature says it can return nil if unsupported (and the syscall is only valid for linux I think) so I will just make it return nil for now
<headius>
I assume this is so you can pass it out to other thread related native calls?
<headius>
Can't we just call the pthread function that gives you thread ID?
<enebo[m]>
I believe this is meant to be for debugging where you want to know actual thread which is busy
<enebo[m]>
we have other ways of figuring this out but a generic Ruby library may still want this
<enebo[m]>
Looks like Process in Java 9 does have a way
<enebo[m]>
So I think we said we plan on 9+ for 9.4?
<enebo[m]>
I have been building with 8 but
<headius>
If we want to make that leap I think 11 is the proper base
<enebo[m]>
yeah 11 is LTS
<enebo[m]>
What do you think?
<headius>
I'm game to make the move, there's a bunch of stuff in 9 through 11 we can start taking advantage of
<headius>
And I did my rails verification under 17 so we're looking pretty good
<headius>
I wonder if it's too late to make this change though
<headius>
We have been saying 9.4 would support Java 8
<enebo[m]>
meh
<enebo[m]>
I like to meet expectations but I don't think anyone can reasonably expect this now even if we did say it a few months ago
<enebo[m]>
9.3 still is alive too
<byteit101[m]>
:-(
<byteit101[m]>
I like not having to deal with module issues with 8 and jrubyfx
<enebo[m]>
lol...that feedback was fast
<byteit101[m]>
I think we need a good way to deal with add-includes etc before dropping 8
<enebo[m]>
This issue will come to a head this year or next year for you
<byteit101[m]>
I know, but I remember reading that this would still be on 8 and I've planned as such
<headius>
add-opens?
<byteit101[m]>
*that
<enebo[m]>
We do actually support jrubyfx 9+ already but it is just a pain to add-opens right?
<byteit101[m]>
correct
<headius>
I want to do more research to see if there's any way we can add opens at runtime, but the best we have right now is the Java options dotfiles
<byteit101[m]>
My command line for testing jrubyfx on 9+: ruby -J--add-opens=java.base/sun.nio.ch=org.jruby.dist -J--add-opens=javafx.graphics/com.sun.javafx.application=org.jruby.dist -J--add-opens=javafx.graphics/javafx.stage=org.jruby.dist -J--add-opens=javafx.graphics/javafx.concurrent=org.jruby.dist -J--add-opens=javafx.controls/javafx.scene.control=org.jruby.dist -I lib samples/contrib/fxmltableview/FXMLTableView.rb
<enebo[m]>
headius: do we have a link on the new dot files for this?
<enebo[m]>
this should all be possible to put into a dot file
<enebo[m]>
byteit101: look at bin/.jruby.module_opts
<enebo[m]>
I don't recall how this works with user apps loading them but there is some hierarchy of file loads
<enebo[m]>
It seems like doing this at runtime would somewhat defeat module unless the code up to that point did not interact across module boundaries
<byteit101[m]>
but I've had to do this for maven libs with maven_require, and other not-just-ruby libraries
<byteit101[m]>
which is a royal pain when I have a good IRB session going and have to re-create it
<enebo[m]>
so other than the ergonomics in how to specify this you will still be forced to specify this in some form once 8 is gone
<enebo[m]>
I am just having a discussion now and not really pushing back that we have to use 9
<enebo[m]>
err 11
<enebo[m]>
I was just thinking we have been talking about no longer requiring 8 for a long time but we have been worried about losing people. The Java world who still is on 8 tends to be people who never update their apps which means our newer versions probably are not really going to be used by them
<enebo[m]>
your use case is something I do sympathize with. desktop/cli apps just seems like it is outside the motivation of the module system
<enebo[m]>
with that said unless we can improve the ergonomics to pick up some app-specific config I am not sure how much further we could really take this
<byteit101[m]>
these days 9/10 of the time it's me loading a new library in IRB, getting things set up, then realizing I have to tear down and re-setup the IRB session with new flags
<enebo[m]>
yeah
<enebo[m]>
but if you package an app do we have a way of picking up a config without having to make people install jruby's install? I don't remember how this works. I think we have ~/.jruby.module_opts?
<byteit101[m]>
Not automatically, no. Hence why jrubyfx has that note in the install section
<byteit101[m]>
it would be cool if it picked up that section from all installed gems
<enebo[m]>
ok well perhaps based on not having this be simple enough we still have some work to do to lower the configuration needed
<byteit101[m]>
Only solves the gem case, not the maven lib case though
<byteit101[m]>
But yes, lower config and automatic config would be great
<enebo[m]>
maven lib could be solved via gem for loading an artifact
<enebo[m]>
if you load the .jar raw you need to manually load it but if you use ruby-maven (I honestly don't remember how these work) it could plug into whatever we did for gems themselves
<enebo[m]>
Anyways, I will back off the suggestion for now since we are super super close to being in a releasable state without moving and we want to release soon
<enebo[m]>
The benefit to moving now would be point releases could cut out and depend on newer APIs without anything weird to opt into them
<enebo[m]>
but Ruby 9.3 will be out in 1.5 months so :)
<enebo[m]>
JRuby X/next/moar perhaps will jump up to 17 and we will have a better solution for modules
<enebo[m]>
I can use JMX to get native thread id as well and that works with Java 8 but it is wonky because I think I need to parse a string apart in an undocumented field