That upgrade from Java 8 to 11 you've been putting off? UK fintech types at Revolut 'quite happy' after a year in production Andrzej Grzesik, principal engineer at UK neobank Revolut, spoke at the recent QCon London, - back in the days when in-person tech conferences were a thing - about the company's shift to Java 11, which it has now been running for over a year. Revolut was launched in July 2015 and now has 2,200 employees, over 10 million retail …
"JDK 11 is licensed differently than JDK 8, with Oracle requiring a commercial licence for its distribution. "We went away from Oracle JDK. There is a licence that is very complicated. I find it tiresome," said Grzesik."
"tiresome" - Delicately put.
Everyone I've spoken to is moving or has moved to OpenJDK; and obviously I have not spoken to everyone, I have other things to do.
But, IMHO, whoever came up with the idea to commercialise JDK11, actually came up with the "Mass Exodus" initiative.
I spoke to everyone you missed. They're also moving to OpenJDK.
We found significant differences between Oracle JDK8 and OpenJDK8. By contrast we found no differences at all between them when testing with JDK11. I see no advantage whatsoever to Oracle's offering at this point.
I still have some Java 8 apps I developed for personal use (weird, specific data analysis stuff). I wanted to move to Java 11 just to learn it a bit, but Netbeans for Java 11 gave me all sorts of headaches. I decided to postpone the update until it is unavoidable or I retire, whatever happens first.
There is a few moving to Amazon Coretto as well, but as thats based on OpenJDK, it probably adds up to the same thing.
We've only encountered one issue so far, and thats one app that uses JavaFX. Were just going to re-write it as what it does is pretty simple. Everything else just.. works...
I find it horrifyingly fascinating to observe people choose the least stable platform and the guarantee of having to change and upgrade everything every three years as the platform to use for banking applications - you know, the kind of thing that needs to work every second of every day, Monday to Sunday, without fail and without being hacked.
Way to go to ensure chaos and customer dissatisfaction. Was there absolutely no other choice that can be upgraded without a complete refactoring every thousand days ?
Rather misunderstanding the longevity and consistency of Java, there.
This is a language and VM that has been around for nearly twenty four years, with remarkably little breakage. Libraries and the core VM have been compatible for the majority of that time, with breaking changes only occurring when the current 'state of the art' has advanced so much that the old way of doing it can no longer be supported.
It speaks volumes that they were willing to upgrade everything - if breakage was a serious concern, it would have been easy to keeps parts of the system wrapped in containers running older VMs.
They're a bank, you can pry Java from the banks' cold, dead hands. Java is the new COBOL.
Also, to some extent there is something cyclical. If most developers for banks are using Java and you are looking for developers with experience in banking you're more likely to choose Java as your language.
Methinks banks senior management today have a lot more to worry about than their bonuses ..... whenever a novel corona virus has their command and control model shredded and lying in tatters before a worldwide population.
Fearing for their lives is not an unreasonable expectation.
This is a big part of why we're putting everything in containers now. By containerizing a Java application you deliver a self-contained unit of computing that has been thoroughly tested with the version of Java (or whatever) that it ships with. And you can upgrade one unit without disrupting the others.
The version of JRE that you're using is a serious problem, but containerizing it only solves the trivial cases.
In the case of the real world non-trivial Java applications we deal with (aka enormous multi-threaded monoliths with literally hundreds of dependencies), it's actually impossible to get *all* the dependencies to work on same JRE... Splitting that lot up into different processes (laughably called "Microservices") is often not pretty - and involves some serious effort and (usually) a big hit in performance.
Maybe in a few years time the dust will settle, everyone will have caught up and it'll be as easy as porting a bit of C/C++... YMMV ;)
NO!
Java is the best example of a runtime where containerization do NOT make sense!! Nothing is easier than running your application with different versions of JDK on a server. No need for a lot of extra container layers, and added complexity between you and you application!
Good luck patching all of your jdk copies inside your containers, unless you mount them from the host OS, and then whats the point (see earlier paragraph).
While describing in this case a team hauling itself across the line, suggesting massive energy, noise, and ground shaking effort, the image is of lightweight tram rail more likely to carry a modified bus as its heaviest load!
While, of course, I am trying to out-nerd the discussions raised where images of Star Trek have been used in conjunction with Star Wars references it seems to me that the Reg needs to re-nerd itself.
Surely IT I've not reached so far into this millennium where IT people are not fussed about this sort of thing. Next someone will be saying all the Dr Who retcons are completely OK.… yikes.
Keep the articles coming, I need something to both read and complain about while working from home !
While describing in this case a team hauling itself across the line, suggesting massive energy, noise, and ground shaking effort, the image is of lightweight tram rail more likely to carry a modified bus as its heaviest load! .... Giovani Tapini
That be agile and stealthy, GT, ..... to have one so comprehensively mistaken for the other and something else. And very qubitish too ...... https://en.wikipedia.org/wiki/Qubit ....... where/when a this is also a that and together something else quite different too.
Java 11 doesn't support 32-bit Windows, doesn't have a JRE (you build your own JRE by playing a game of guess-the-modules with jpack), and a bunch of stuff was deprecated or removed entirely.
On top of that Oracle changed their licence / support terms and companies are scared and confused about that too. All these conspire for companies to stay put with Java 8 which is generally good enough. Or if they do move they move away from Oracle they move to the OpenJDK or Corretto to avoid potentially paying Oracle.
"Grzesik also praised the open source and free-to-use Java Flight Record and Mission Control"
Not sure if this is correct but looking at the Java Flight Record it seems to be a paid for service.
https://docs.oracle.com/javacomponents/jmc-5-4/jfr-runtime-guide/about.htm#JFRUH172
<quote>
Enabling Java Flight Recorder
By default, JFR is disabled in the JVM. To enable JFR, you must launch your Java application with the -XX:+FlightRecorder option. Because JFR is a commercial feature, available only in the commercial packages based on Java Platform, Standard Edition (Oracle Java SE Advanced and Oracle Java SE Suite), you also have to enable commercial features using the -XX:+UnlockCommercialFeatures options.
</quote>
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
