To close the loop here, not much difference;
include Java would trigger require 'java' if it had not already been loaded, but in all recent JRuby versions it's already there. The difference comes in where you actually include; whatever module you include Java into will gain some peculiar side effects of our module/package logic that lives in the Java module.
Recommendation is to avoid
include Java now, and use require 'java' only as future-proofing in case we don't load it by default some day.
I gave them an example piece of code, I guess I also need to generate an example app 🙄
hopefully this is enough
Friendly reminder for folks still here... we will continue to monitor, but Gitter has not been maintained and notifications are unreliable (I don't get them at all). We've moved our official chat room to Matrix, since it's active, FOSS, and bridges very well to IRC. You can join us via https://matrix.to/#/#jruby:matrix.org
There is a Gitter bridge for Matrix, but it has never worked well enough for us to enable it. Hopefully that will change in the future, but you'll get a quicker response if you use IRC (Freenode, #jruby) or Matrix.
That is all...carry on!
it's bothersome that this fix won't go into earlier versions but I'd like to start reducing that patch set
@headius I looked at matrix. What client do you use?
oh I'll answer there
Hi @headius, We are migrating our db from Mysql to Oracle and I'm trying to use activerecord-jdbc-adapter-52.1 and getting argument error similar to the one given here (jruby/activerecord-jdbc-adapter#955) while establishing the connection with adpater as "jdbc". Any workaround for oracle adapters? Appreciate your help.
@randiaz95 Hi there! most of us were off for xmas, but we also don't use this channel much anymore. We've moved our official chat to Matrix at https://matrix.to/#/#jruby:matrix.org
activerecord-oracle_enhanced-adapter
I think @annabackiyam_twitter also stopped by the Matrix channel, so if we could move discussion there that would be great too
It is possible for to ROR project to integrate into java.
Sorry to bother again, but still no answer about the PR torquebox/jruby-maven-plugins#106. Is there really no one arrond to check. The issue it tries to fix means no more jruby-plugin for latests version of jruby
@nzakaluk @abelsromero @JV81608177_twitter Sorry nobody responded but we have largely moved our chat to Matrix. If you still have questions or issues, you can join us there or on Freenode IRC #jruby that is proxied to Matrix: jruby.org/chat
that autolink may not work so here's another: https://www.jruby.org/chat
if it can help: rubygems.org seems broken, http://rubygems-proxy.torquebox.org/releases/ can replace it (temporarly i guess)
And yeah like @chemturion said please join Matrix, as we are not really monitoring this very often anymore
I think I have a definitive proof of JRuby's Thread.current object changing in the middle of a process run... Like, local block-level variables remain the same, everything works as expected, but Thread.current is completely different (different ruby object instance, different object_id, different thread-local contents, etc) at the end of the method compared to the value at the beginning of the same method. This completely breaks my mental model of how computers work. Anybody else seen or experience anything like that?
P.S. In case it is relevant:
- The thread where it happens is a jruby running within jetty, specifically a jruby-rack-worker thread
Specific scenario where I'm observing (I was not able to reproduce it outside of our application):
- 4 jruby rack workers are started using
jruby.worker.script=SharedTogo::Workers.start_all! - Each logs its thread_id at the beginning, then goes into an infinite loop, periodically checking a
Concurrent::AtomicBooleanshutdown flag - An
at_exitblock is used to set theshutdownflag totrue - When the workers notice the flag, they exit the loop and log their thread id - at this point it is completely different and the worker has lost its thread-local variables
Oh, and one more weird factoid:
Thread.list at the end of the method contains a single value in each thread - the new thread object for each thread. Meaning in each of 4 worker threads Thread.list == [Thread.current]
Another useful tidbit (I think): Java thread name and thread id remains the same all throughout this mess.
