subbu has quit [Ping timeout: 240 seconds]
<puritylake[m]> Also enebo I’ll try work on the other format specifiers in sprintf, whatever ones are left
subbu has joined #jruby
FarazYashar[m] has joined #jruby
<FarazYashar[m]> Hi all, I have a question regarding jar compatibility with JVM updates
<FarazYashar[m]> I have an extension that was built with 9.2.7 with 1.6 as a target
<FarazYashar[m]> After upgrading to the latest JVM, it no longer works even though no 1.7+ features were used
<FarazYashar[m]> Is there rule of thumb to tell when JARs built with older JDK versions are no longer forward compatible?
<FarazYashar[m]> * Is there some rule of
<puritylake[m]> No idea why any PR I make so many CI’s fail but headius’ seem to run fine
<headius> 👨‍🎤
<puritylake[m]> Hmm I think I’m just blind and missing failing tests lol
<headius> Faraz Yashar: it complains about the bytecode version?
<puritylake[m]> Gonna be fixing those problems later, so much to do today
<puritylake[m]> Also been attempting to contribute to CPython, got one PR merged, two more to go
<puritylake[m]> Next is CRuby
subbu has quit [Ping timeout: 240 seconds]
subbu has joined #jruby
<FarazYashar[m]> <headius> "Faraz Yashar: it complains about..." <- @headius So I have a gem I built an extension for with 1.6 as source/target when running Jruby 1.7 a loooong time ago. Requiring that JAR in 9.2 doesn't seem to work: I don't see any error, just that the module function I expect to be exposed isn't. Recompiling with 1.8 as a source/target fixed that issue... but now I'm having issues with 9.3.
<headius> Yeah the bytecode version issue can't be avoided, they have started to drop old releases
<headius> What issues are you having with 9.3?
<FarazYashar[m]> The exact same thing
<FarazYashar[m]> But even rebuilding with higher source/target doesn't make a difference
<enebo[m]> headius: did we change/remove how we load extensions at all for 9.3?
<enebo[m]> Like the magic load from top of jar file thing
<headius> fny: it still says unsupported bytecode version?
<FarazYashar[m]> It never says anything
<FarazYashar[m]> Even from 1.7 to 9.2 it silently fails
<FarazYashar[m]> I just see NoMethodError: undefined method `xor!' for Xorcist:Module
<FarazYashar[m]> Now I have 9.2 working with 1.8
<FarazYashar[m]> If I rebuild on 9.3 same error
<headius> Loading extensions has changed a little
<FarazYashar[m]> Yup
<enebo[m]> This service loading I thought was no longer supported but I cannot remember
<headius> Yeah the automatic load was flaky so now need to require/load the jar and then tell JRuby what extension to load
<headius> I see your bug report now
<headius> Yeah add on line there...
<FarazYashar[m]> <3
<headius> Like that
<headius> require jar first then load the ext with a line like that
<headius> We used to automatically load based on the path to the jar file but it was error-prone and you could only have one extension in a given jar
<FarazYashar[m]> So I do I need the service at all?
<headius> No you can just make whatever calls from Java to boot it
<FarazYashar[m]> Is there a default namespace that's used?
<headius> Ahh you have no package... That is ok for now but Java will complain on newer versions
<headius> So just "Xorcist" should work
<FarazYashar[m]> Nope... looks like I need moar ceremony
<FarazYashar[m]> NameError: Java class Xorcist not found
<headius> Hmm
ahorek[m] has joined #jruby
<headius> Oh I see
<headius> There's another interface to implement similar to the service
<headius> I'll find an example
<headius> This load_ext expects this other interface
<headius> Basically the same code you have in the service
<FarazYashar[m]> Doesn't work
<FarazYashar[m]> Is the library interface supported in 9.1-9.2 or this a 9.3+ feature
<headius> It's been around forever
<headius> Not positive about load_ext though
<FarazYashar[m]> load_ext is new
<headius> If load_ext doesn't work then the service logic works... Sorry we didn't make this transition as seamless as we could have
<ahorek[m]> JRuby::Util.load_ext is 9.2.something+
<ahorek[m]> org.xorcist.jruby.XorcistLibrary.new.load is for older versions if you still care
<FarazYashar[m]> `NameError: Java class org.xorcist.jruby.XorcistLibrary not found`
<ahorek[m]> hmm, what java version?
<ahorek[m]> xorcist.jar does exist?
<FarazYashar[m]> yup
<FarazYashar[m]> jruby 9.3.0.0 (2.6.8) 2021-09-17 85c20e780f OpenJDK 64-Bit Server VM 18.0.2+0 on 18.0.2+0 +jit [darwin-aarch64]
<headius> You would need to move them into that package before you compile, otherwise Java::Default::XorcistLibrary
<FarazYashar[m]> that's what i thought
<ahorek[m]> could you enable GHA?
<FarazYashar[m]> GHA?
<FarazYashar[m]> ahorek
<FarazYashar[m]> What black magic is this?
<FarazYashar[m]> I must be doing something wrong in the build... because I already tried that with v8 and even rebuilt everything as a package
<FarazYashar[m]> oh wait
<FarazYashar[m]> Okay so... I still can't get this to work locally, which is crazy
<ahorek[m]> yeah, it looks like the jar library isn't loaded for some reason...
<FarazYashar[m]> Oh wait you did more
<ahorek[m]> or you're testing something else :)
<ahorek[m]> btw I've changed BasicLibraryService to Library which is preferable I think, both should work basically the same way, but you have to load the library explicitly via load_ext
<puritylake[m]> Ok on further inspection of the failing checks some seem to not be related to my code changes
<puritylake[m]> Mainly build failures by the looks of things
<puritylake[m]> Ok I've found a problem with array.sort!
<puritylake[m]> Ok I have found a slight problem with Array#sort! and specifically Arrays.sort, the block isn't run the same amount of times as Ruby
<puritylake[m]> I might try recreate CRuby’s sort implementation
subbu has quit [Quit: Leaving]
drbobbeaty_ has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby