<headius>
so I have this backtrace thing working but need to make a decision about how to handle these 9+ features while we still support 8
<headius>
I kinda started this process already with "modulator" that does module API stuff, but I'm wondering if that should be expanded into a java 9 compat library
<headius>
it might even make a good home for the nio Buffer helper that's dealing with those binary incompat issues
<headius>
I don't see many Java 9 to 8 backport libs
<headius>
I also have a WIP varhandle wrapper I will merge into this later
<enebo>
it is weird how little thought seemed to be put into 8->9 cross compat
<enebo>
even that platform detect code just picking Module as a test. Seems Java should provide something...or perhaps even better capabilities api
<enebo>
headius: but it all looks nice to me
<headius>
yeah capabilities API would be good
<headius>
they should add a major version enum that always contains next version
<enebo>
yeah both are probably useful for reasons
<headius>
so on 8 you could always do something like if JavaSpec.current() < JavaSpec.next()
<enebo>
but does this Java support Modules? Or in Java 11 is first jaotc I can trust
<headius>
oh for sure
<enebo>
both pretty reasonable progmatic questions
<headius>
better coarse-grained capabilities would be nice
<enebo>
Class.forName is pretty weak sauce but I guess it is not hard to know it is possible to check that way
<enebo>
It will not tell you if there are new methods on the type so versioning maybe is reasonable
<enebo>
unless we then need to use reflection to ask
<enebo>
which again seems like weak sauce
<enebo>
Those two tools probably is enough to make a framework for capabilities though
<headius>
I used that because it's at least something concrete I know will never be on 8
<headius>
and because we've had a bloody hell of a time trying to figure out spec version from java.specification.version
<enebo>
oh yeah it makes sense I am just thinking more obliquely about what is missing from Java itself
<headius>
this is also why the launcher changes I made look for the presence of jmods dir
<headius>
yeah
<headius>
it is unfortunate
<headius>
we probably have over a dozen different mechanisms for detecting current JDK version sprinkled throughout JRuby
<headius>
it's silly
<headius>
all used for different capabilities
<enebo>
and version checks may work good enough for Java based on how rigid it is but it still is one dimension away from whatever is checking on a version
<enebo>
e.g. is (Java9()) vs if (supportsModules())
<enebo>
but it is reasonable for Java in the sense things do not radically change a lot
<enebo>
with 6 month releases perhaps that won't hold in the future htough
<lopex>
isGoodEnough()
<lopex>
or better, isStartWorthy()
<lopex>
startup ?
<enebo>
lopex: you drink beer on friday's right?
<lopex>
yeah, mostly
<lopex>
and today is the day
<headius>
yeah I also did it this way because I want to support 9+, not just 9...and they keep changing the numbering scheme
<lopex>
but not untill 10mp here
<lopex>
*pm
<headius>
so what I have is really more like a capability check
<headius>
ok, I'm going to spin 1.0 of this and use it for the PR
<kares>
altough still a mutex should not fail mutex-ing
<headius>
kares: only failure on most recent red master was the test/unit thread unsafe thing I patched around
<kares>
recall eregon mentioned this one
<kares>
that there's some new mutex specs failing and being tagged
<kares>
if I recall right that was due not being interruptible
<headius>
oh other than my fix for that failed three things
<headius>
yeah those were suppose to have been tagged though
<headius>
that has not been addressed
<headius>
I wonder if a bad merge wiped out the tag or something
<headius>
enebo: backport9 is released and the branch updated...just waiting for propagation to confirm CI is green and I'll merge that stack walking to master
<headius>
it's functionally identical on 8 but on 9 it can limit depth if you use the two-arg form of Kernel#caller
<headius>
sad story is nobody uses that form
<headius>
ok, artifact should be propagated...gonna take lunch and let CI chew before I merge the stack walking stuff
<headius>
hahaha
<headius>
my sequel job always passes
<headius>
if JRuby fails to build it uses the rvm jruby
<lopex>
well, the question is how easy it will be for mri to switch to that oniguruma fork again
<headius>
they do things so oddly
<headius>
I'm not sure why they made onigmo to begin with if they were just going to make their own changes all the time
<lopex>
there's total mis cooperativeness
<headius>
wasn't onigmo basically supposed to be MRI's oniguruma?
<lopex>
and cross merging is insane
<lopex>
headius: nowadays ?
<lopex>
now
<lopex>
it diverged in insane ways
<lopex>
it supports no callouts etc
<lopex>
er, it does support callouts
<lopex>
sorry
<lopex>
so in a gist
<lopex>
onigmo was an early fork of oniguruma and it was adopted and being traced by mri
<headius>
ok so it wasn't done specifically for MRI
<headius>
yeah the cooperation thing is weird
<lopex>
and now, oniguruma was a separate fork that wasnt used by mri but has DIVERGED substantially
<headius>
in the past I might have thought it was a language barrier issue but the maintainers of onigmo speak japanese too
<lopex>
those two are now different projects even when you account only for the features
<lopex>
no idead
<headius>
yeah ok
<lopex>
but that's what I can tell from keeping an eye on them for past year or so
<lopex>
and that fact can make some troubles for us
<lopex>
especially those cross merges from mri/onigmo
<lopex>
those maddy the waters pretty well
<lopex>
er, is cross merge actually a thing in english tech slang ?
<lopex>
headius: those changes in mri are easy to update, like a day or so
<lopex>
and then we can update to unicode 111
<lopex>
11
<lopex>
but mri in it's instanity can switch back to oniguruma
<lopex>
and then we have a problem
<lopex>
like two months of work
<headius>
cross merge works for me
<headius>
as a phrase :-)
<lopex>
yeah
<lopex>
yeah, it's weird
<lopex>
just invented that for that thing they do
<lopex>
uncommon even in c comunity
<headius>
I think the conservative approach is all we really have here...MRI is rather nutty about introducing minor changes into the regex and the vast majority of them are never seen by users
<headius>
usually if someone reports some new feature we didn't add it's only a release away
<lopex>
but there was a perdiod like from 4 to 1 years ago where mri and onigmo happily interchanged the code with each other
<headius>
ugh my kingdom for fast-propagating maven artifacts
<lopex>
and it was a time of introducing quite of a few features
<headius>
this slows my dev process down more frequently than it should
<lopex>
headius: at least no one touches transcoding
<headius>
I suppose this is a side effect of us not wanting to have commits depend on snapshot dependencies
<headius>
but that's the right choice too
<headius>
lopex: hah yeah
<headius>
I have not checked if that inner loop has changed since I ported it
<lopex>
headius: and that thing you mentioned to me some time ago wrt that mac-utf8 failure
<headius>
still amazed that it works as well as it does
<lopex>
headius: I starred at the code for an hour
<headius>
hahah yeah
<lopex>
and havent come up with anything
<lopex>
it's still broken
<headius>
I had a ton of those moments while porting the transcoder loop
<lopex>
headius: you remember that ?
<headius>
stare at code for hours and then realize I had a - instead of a + in some character-width calculation
<headius>
mac-utf8 failure, I don't quite remember
<lopex>
headius: it's good until you have 1000 lines of those