Good Morning!

Ugh! That's a bit early @dharrigan!

I'm a light sleeper. Been up longer.

I enjoy this time, since it's peaceful 🙂

Morning

Until I wake up that is 😉

Morning everyone 🙂

Morning

morning, I still run JDK8.

not the oracle variant. I tried the OpenJDK J9 version but that wasn't compatible with Jira and/or Confluence.

måning!

morning

morning 👋

We’re still on JDK 8 in production, but have been running JDK 8 and 11 in dev for a while… We have an active branch which has ported stuff to use adopt openjdk11. Our app could technically switch over today; but our database still requires JDK 8; though they’re supposedly going to support 11 in the next release which I believe is due to be released this quarter. The DB not being on 8 is the main reason we’ve not switched yet; as it’ll require provisioning two different base images for our servers which isn’t really a big deal; it would just be wasted effort. Also we have a backend service which I’ve run in dev on 11 but it hasn’t been tested in CI on 11 yet… I don’t expect any issues there, but would like to either matrix build it on 8 and 11 or solely 11; before we switch prod over.

Morn’ using openjdk 8 ourselves…

openjdk8 here too. Should move over to 11

The JDK upgrade path has been annoying as hell recently. "We'll just remove packages that have been in the standard library for 15 years that everybody is using. What could go wrong?".

I like to be on the very lastest JDK I can because the GC improvements tend to be pretty significant, but Oracle, it must be said, are less conscientious stewards than Sun were, and, having recently explored their cloud product, this doesn't seem to be a culture problem constrained only to the JDK.

they were sun.* packages which have always been labelled as "do not use" unless there are some others

@otfrom I am thinking about some XML stuff that was a problem, but I don't have the details to mind right now. Definitely not sun.* though.

@otfrom javax.xml.bind

You can do some stuff with flags here but we ended up in a right old mess with some of them. If you want to be able to run against different JDKs, then you need flags on the new ones to include stuff that has been removed, but then the old one complains that it doesn't understand the flag, so you need another flag to tell it to ignore flags it doesn't understand.

I think the JDK has really improved

Yes, there was a bit of pain moving from 8 to 11, but it had many many many months of forewarning and upgrade paths

The result is the ability now to have a leaner, meaner JVM, with less bloat and a far far better cadenance in release cycles

something that I believe has reinvigorated the platform

We found very little problems moving from 8 to 11 on our platform, and we have quite a number of µservices.

@dharrigan I am possibly a bit spoilt honestly. I've been working with the JVM since 99, and Java 1.1. Relative to many other popular platforms (cough nodejs cough), the JVM upgrade paths, even today tend to be pretty painless, but back in the day Sun were famously fastidious about backwards compatibility. This did mean that apis tended to be slight "accretive", but isn't that what we are being told to do by our lord and saviour (prase be to Hickey). It's not that it's impossible to go through the process, but I do wonder how many people are running on older JVMs because they tried to run on a recent one and saw it crap out horribly. This really never used to be a "thing" in Java land. You'd have new stuff when you upgraded, but you could bet the farm that the old stuff would work without having to go diving through obscure docs to find the flags you need (or, if you are later to the party, stackoverflow).

Now would probably be a good time for an "OK Boomer" gif 😉

I'd also add that I can't remember ever seeing, "Doesn't work on <insert latest JDK version here>", bugs in github or equivalent until around version 8. Now they seem to appear everywhere on every beta release.

What's ok boomer?

@dharrigan Do you even internet bro? 😉

I can't keep up with all the young'uns thesedays

(is (= "ok boomer" (reverse "things millenials are killing")))

if you have to ask…

i remember encountering a tweet from a gen X-er whose feelings were hurt b/c his kid ok boomer'd him

"why don't you come up to those girls and talk to them?" "maybe it worked for you in the 50s dad, but we don't do human interaction like that these days"

drama XD

@lady3janepl My wife's cousin was complaining about exactly this. Every time he asks his kids to do something they respond with, "OK Boomer". I laughed more than I should have.

Hmm....

https://media.giphy.com/media/3oEjHAUOqG3lSS0f1C/giphy.gif

By the way folks, since I am already here shatting chit... If anybody is interested, I am doing a thing...

https://www.eventbrite.co.uk/e/london-ctos-panel-tickets-86478119383

I am not that interesting really, but if anybody from here does come, and mentions you are a #clojure-uk person, i'll buy you a drink after.

Also, the other guys are nice 😉

Are you the one holding the pencil/pen/arm-about-to-drop-off or the one smiling blankly at what I think is a MBP?

@dharrigan Weirdly, I think that is a stock image. I don't do the promotions as you can probably tell from my lukewarm description above 😉

In any case, the four of us did one of these before (we have a kind of Pythonesque troop going), and it was fun. Very Q&A and lots of discussion about things like building startups, funding challenges, and being responsible as a "buck stops with me" technical strategist. I get the feeling that most people here are pretty experienced anyway, but if you do find any of these things interesting, come and see the show 🙂

One of the annoyances about upgrading from JDK8 for us was the complete change of GC logging in 9. It wouldn't even startup with the GC logging options we've had in place for years. Like Wes said, hard to have a set of options that works across both 8 and 11

I need to access the file seperator; is it idiomatic to just use .File/seperator ? Is there a clojurier way to do it?

Not that I’m aware of.

That’s idiomatic

I have this vague, wishy-washy memory of some file IO apis accepting forward slash separators even on windows in order to avoid having to do weird interpolation with a separator constant like this, but I don't know if I just dreamt of this amazing utopia.

I think a lot of the Java APIs now at least let you specify the path segments as a vararg style thing so you don't have to muck about.

Yeah that’s a good point there is java.nio.file.Path and libraries like datoteka that wrap it from clojure, though I had some minor grumbles with datoteka. Also ( "foo" "bar" "baz") which will give you a .File back and can construct the path in platform dependent way with varargs, and it ships with clojure core, but if for some reason you need the separator itself use the above.

Personally I’d opt for unless you need nio, or are working with the java FileSystem abstraction.

datoteka’s lack of support for the FileSystem abstraction is my main grievance with it. It always creates java.nio.file.Path s in the local (default) file system. Which seems to make moot the main reason for wanting Path’s rather than File’s.

its for something a bit mucky like

(defn fileshortname
  "returns only the last section of the filename"
  [f]
  (if (instance? File f)
    (.getName ^File f)
    (let [s (str f)]
      (if-let [idx (string/last-index-of s File/separator)]
        (subs s (inc idx))
        s))))

so I'm parsing rather than generating

https://raynes.github.io/fs/me.raynes.fs.html#var-base-name ?

@ben.hammond According to "Learning Java, 4th edition", I did not dream my utopia, and the the File constructor does accept paths with both forward slashes and backslashes on Windows (though only forward slashes on other platforms). In any case it shouldn't matter in your example here because you are implicitly assuming that the path you are parsing was generated on the platform that is doing the parsing (by using File/seperator). With this in mind, why not just call ".getName", if it's a file, and if it's a string, construct a file from the string and then call .getName. (.getName (File. (str f))) is maybe a little clearer than all of the string parsing stuff. I haven't tested it, but I can't think why it wouldn't work.