16:46 <byteit101[m]> I constantly get `Ignoring gem-wrappers-1.4.0 because its extensions are not built. Try: gem pristine gem-wrappers --version 1.4.0` in some environments. executable-hooks too, and occationally jruby-launcher. Do you know what causes this? This is across multiple machines and rvm installations

16:59 <headius> I have reported this issue but never managed to isolate it enough to get help from the Rubygems maintainers

17:03 <byteit101[m]> ah

17:04 <byteit101[m]> unrelated side note: https://javadoc.io/static/org.gridkit.jvmtool/hprof-heap/0.9.3/org/netbeans/lib/profiler/heap/Instance.html has the 'java_class' method that conflicts with jruby if you want to know of java libraries with jruby method names for future reference

17:08 <headius> Oh funky

17:08 <headius> Wonder why they used underscore case

17:16 <byteit101[m]> they don't, it's getJavaClass, but our rubyification expands it out to java_class

17:22 <headius> Oh gotcha

17:23 <headius> Do we allow it to overwrite that method? I know we guard some method names but can't remember which

17:27 <byteit101[m]> we do (handy for me I want the library's java_class, not our java_class)

17:28 <byteit101[m]> jruby-9.3.3.0 :024 > fth.instance.java_class.java_class

17:28 <byteit101[m]> jruby-9.3.3.0 :025 > fth.instance.java_class

17:28 <byteit101[m]> => #<Java::OrgNetbeansLibProfilerHeap::ClassDump:0x6f43c82>

17:28 <byteit101[m]> => #<Java::JavaLang::Class: org.netbeans.lib.profiler.heap.ClassDump>

17:28 <headius> Perhaps we should have some backup names for important things (this probably isn't one since we have moved away from the old JavaClass stuff)

17:30 <byteit101[m]> ruby_send :java_class?

17:31 <headius> Perhaps something more like JavaUtilities.java_class(xxx)

17:31 <byteit101[m]> Though you can still access it today:... (full message at <https://libera.ems.host/_matrix/media/r0/download/libera.chat/e22e799014eefc01d17cc5e2cd82785bc3f50ad1>)