xardion has quit [Remote host closed the connection]
xardion has joined #jruby
olleolleolle[m] has quit [Quit: Idle kick: User has been idle for 30 days.]
alsemyonov[m] has quit [Quit: Idle kick: User has been idle for 30 days.]
<headius[m]>
lopex: we have a couple other hacky mappings I think but most of those are from before we matched encoding logic as closely
subbu is now known as subbu|lunch
subbu|lunch is now known as subbu
<headius[m]>
jeremyevans: I never intended A.B to work when I added constants a decade ago...I'm not sure why it does
<headius[m]>
I think this is piggybacking off support for static field accessors and probably not working on 11 because the constant field doesn't allow write
<headius[m]>
aha
<headius[m]>
so when logic for constants on interfaces was added it did not skip adding the field accessors for constants, as classes do
<headius[m]>
so I guess the next question is whether we fix this or not
<headius[m]>
I traced it back and it's original behavior introduced in 2008 when we had a contrib do a large rework of Java integration
<headius[m]>
or at least it existed in that commit...but may have been adapted or transplanted from even earlier code
<headius[m]>
so this was never intended behavior but we didn't notice it until now, when the accessibility check caused it to not work on Java 9+
<headius[m]>
kares: this is a "fun" one
<jeremyevans>
headius[m]: That's pretty long. I didn't trace the bug in Sequel, but I'm guessing it is something I introduced years ago
<headius[m]>
all the fixes are easy...the question is which fixes are appropriate
<headius[m]>
given that this has been around for ten years i'm disinclined to break it
<headius[m]>
I was actually wondering yesterday why we don't bind the accessors as well
<jeremyevans>
headius[m]: Would you recommend switching from Java 8 to Java 11 at this point. I think most of my tests have passed it, but some give illegal access warnings. I'm not sure if the benefits of Java 11 outweigh that
<headius[m]>
the illegal access warnings are just warnings but there's no way to turn them off
<jeremyevans>
headius[m]: This is in regards to switching the Java version that JRuby uses in the OpenBSD port
<headius[m]>
we have been adding tweaks to launchers and using other logic to get rid of the warnings
<headius[m]>
we still recommend 8 for now
<headius[m]>
because of the module warnings
<headius[m]>
that's not really tenable for much longer though
<jeremyevans>
headius[m]: OK. I'll keep that for now. I'm sure you'll announce when you recommend switching from 8 to 11
<headius[m]>
unfortunate thing is that we have only had a long-term supported Java with modules since September 2018
<headius[m]>
and only had modules at all for a year before that
<headius[m]>
it's still pretty young
<headius[m]>
enebo: your opinion is requested
<headius[m]>
I kindly request the privilege of entertaining your learned opinion on this issue
<headius[m]>
technically you introduce it because you committed bdortch's code
<headius[m]>
I believe this would fix jeremyevans issue...then we can debate whether interface constants should have accessors or not
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius[m]>
Actually || might not be enough of a change? Public fields on a non-public interface would also be inaccessible
<headius[m]>
I'm not sure if that case would get this far though...we have a hodge-podge of access checks leading up to this
subbu|afk is now known as subbu
<enebo[m]>
headius: yeah I think || seems reasonable. Part of me thinks we talked about that and in 9+ no module non-public field is accessible or something like that but if it says true then why not?
<enebo[m]>
It certainly is putting a restriction on 8 we don't need
<enebo[m]>
Although it comes back to actual semantics I suppose
<enebo[m]>
We probabyl want consistent access to the same classes if possible for consistency
<enebo[m]>
or fields in this case
<headius[m]>
So I can go ahead with the || change and I'll test whether non-public interface is a problem
<headius[m]>
the other question is whether the accessor should be removed since it was never intended to be there (but has been for 10 years)
<headius[m]>
jeremyevans: 😆
<headius[m]>
so you've had this in there for almost ten years too
<headius[m]>
I'm torn on this because . is the Java way to access a constant so having the accessors bound would allow for a bit less syntax conversion
<headius[m]>
the accessor won't optimize the same way as a constant but with indy and method inlining it may not be far off
<enebo[m]>
JAVA BEANS FTW
<headius[m]>
if we do keep it the other question is if we should make class constants act the same way
<headius[m]>
🤷
<enebo[m]>
how long has it been broken? Forever on 9+ right?
<enebo[m]>
Bean properties are from another century of Java
<enebo[m]>
I am usually not a proponent of breaking things but if we have had a single report of this in the 3-4 years 9 has existed then maybe everyone is on 8 or not many other people knew about this
<enebo[m]>
Sept 2017 am I high
<enebo[m]>
It was pre-released for a loong time before that though or have I went through a time vortex
<headius[m]>
since you made that accessibility change
<enebo[m]>
shoot
<enebo[m]>
well I think we should add a warn and deprecate for 9.3 then
<enebo[m]>
-v can catch it
<headius[m]>
mmm that's an option
<enebo[m]>
Then at least it won't break anything
<headius[m]>
warn on access?
<headius[m]>
not on bind I assume
<headius[m]>
yeah silly that would warn all the time for anything accessing these interfaces
<enebo[m]>
yeah on access since we will bind without use
<enebo[m]>
It could even suggest :: if it happens to be valid
<enebo[m]>
but that would be putting more work into that warning
<enebo[m]>
afk for 10
<headius[m]>
hmm this is hard to test because my one-off test classes are not locked up inside a module
<headius[m]>
I need a JDK-level non-public interface with public static fields
<headius[m]>
so it doesn't appear we'll even set up a non-public class in a module anyway
<headius[m]>
I think || is a good enough change for now then
<enebo[m]>
yeah seems fine
<headius[m]>
enebo: warn once, warn only verbose, or what?
<headius[m]>
if we only warn in verbose mode I doubt anyone will see it before 9.3
<enebo[m]>
warn only verbose
<enebo[m]>
I think it would suck if you depended on this in a library and you suddenly started seeing the text
<enebo[m]>
It is somewhat the duty of people to run -v occasionally to see if anything is changing (or at least I think that is a defensible decision)
<headius[m]>
hmmm yeah I guess so
<enebo[m]>
It does feel a little academic since we only know of a single use but there could be others?
<enebo[m]>
I am a little angry when I see mandatory warnings (cite: Java 9+ module system)
<headius[m]>
true
<headius[m]>
this is another reason we need better release notes
<headius[m]>
so at least someone could see in an upcoming 9.2.x that we deprecated this behavior
<enebo[m]>
yeah I am all for putting this in the notes too
<enebo[m]>
afk for many hours! :P
<headius[m]>
nooooooo I'm not done with you
<jeremyevans>
IMO verbose warning deprecation is about as valuable as no deprecation, unless it is just an earlier warning and you plan on adding a non-verbose warning later
<headius[m]>
Yeah that's where I stand
<headius[m]>
Warnings can be turned completely off also if that is a major problem
<headius[m]>
-w 0 I think?
drbobbeaty has joined #jruby
<headius[m]>
well I merged it as a verbose warning for now