"I've forgotten why split was deemed too high-level?"

split is the same as using a regex, and apparently regexes drag in a lot.

Going to close this PR this week unless it gets updated. It's had pending review comments for over 10 days.

@adriaanm Sorry, broken nose, hospital, etc... Reading through the comments, I don't see stuff which would be applicable to the issue here. (I sympathize with the version which takes integers instead of a string, but that doesn't really fix the issues with the string-based one, does it?)

@soc, sorry to hear it! Hope it's healing well!

I'm still in favor of my oneliner as opposed to the convoluted status quo (before this PR).

@soc my condolences, too. I guess you have to be pretty careful how you give feedback on github, you never know how it will be received. I'd also suggest preferring one-line to involution or convolution. The one line does give different answers for "1.*" and "1.?". Maybe the 1.* is a typo for 1.8?

The thing is that if you want to make that one-liner work reliably, you end up with exactly the change which was rejected before.

So we have either

• Something easy which will break
• Something imperative, which works, but was already rejected
• Something which uses regexes and pulls in tons of dependencies

Here is something between a 1-liner, the 3-liner requested by @paulp and the original forty-niner I mean forty-liner.

https://gist.github.com/som-snytt/5725336

There's a shorter take that assumes major.minor, and a longer version that takes as many parts as you want to try to compare against whatever the actual version string is. I preserve the original strategy of taking the numeric prefix of the part for purposes of comparison, so "0_52" is 0, "5b" is 5, "b" is 0.

I think somewhere in the repo is version munging logic for the sbt build, or similar endeavor.

I don't want to imagine how many classes this creates for something as trivial as comparing a version number ...

Hey everyone, what are we doing?

scala> System.getProperty("java.specification.version")
res0: String = 1.6

def isScalaAtLeast(spec: String) = spec == "2.9"

A little spec humo(u)r.

So @soc would you like to take a shot at this based on java.specification.version, which makes it easy unless you're trying to future-proof against java 10.x.

scala> sys.props("java.specification.version") match { case s => (s.substring(0, 1).toInt, s.substring(2).toInt) }
res0: (Int, Int) = (1,6)

@soc: what's the status of this PR?

@gkossakowski Without @paulp 's help we can't figure out how to perform the calculation in acceptable time and space such that the code is maintainably write-once read-many! But maybe @soc will bounce back.

Maybe there's a scala.reflect.internal.util.ReflectionUtils.isJavaAtLeast method that could be made public.

Not sure about a good solution ... I'll close it and will reopen if I or someone else has a new idea.

Wait, isn't this just the temporary fix?
Ok, my suggestion is to merge it as-is (it is just adding a few version strings), until we figure out a nicer implementation.

I'll have a PR in a minute after I figure out how to submit against 2.10 under the new github interface, argh. The PR includes a junit test! ha! That's great. And corrects the scaladoc in this PR, which is backward. 🎱 I'm not sure I'm using 8ball correctly, but github suggested it. I kind of want my old github back.