It's weird to me that there seems to be a trend of using "flight" as a metaphor for the runtime of our code. We have "preflight checks" in CORS and now a "flight recorder" on the JVM. In their canonical usage, these are mundane, self-describing terms. If we like the wording from the aviation industry and want to appropriate it, we don't have to bring the word "flight" along for the ride. We could just as easily have "prerequest checks" and a "JVM Recorder"... and yet here we are.
Every thing we programmers make is ethereal, impalpable, formless. Metaphor is a huge aid in managing that. Why deny yourself tools that help you organize and communicate about our code?
It goes beyond the runtime: the way we describe work in progress as "in flight" is somewhat irritating. I've caught myself using this quite a lot recently: I first heard it used around 4 years ago. Since then it's somehow wheedled it's way into my daily lexicon. It's a habit I'm trying to break.
I find it strange that in the IT world we find ourselves constantly annoyed by the language we’ve collectively chosen to use and seek to find other ways to describe something that already has an agreed upon term. I wonder if other industries do this to themselves too.
Complaining about “in flight” or “cloud” or “serverless” even though everyone understands what those terms mean seems like bikeshedding at its worst.
I have always tried to talk in normal words all the time. It makes it much easier when I need to explain to a co-worker or the boss how something works or why it has to be done before we can take care of the visible problem.
I try not to make others feel stupid just because they don't know the keywords. Sure it would be easier and faster to talk but if I'm not understood it's meaningless.
On the other hand, if you use the term "JVM Recorder" while everyone else is using the correct name "Flight Recorder", you're now forcing everyone to use non-standard language just for your benefit.
Far too often I hear people argue "it's not in the cloud, it's on a server" which makes people think it's hosted on-prem on a server that we own and control and maintain, but it's not. It's on someone else's network, on someone else's server, a server that they own and control and perform the maintenance for. But that's a really long winded response, so luckily we agreed on a single word to represent that concept: cloud. Like it or not, words have meanings and those meanings have definitions. If someone isn't likely to understand the word, explain it using its definition. Don't just unilaterally switch to a completely different word.
My CEO might not know what "serverless" means, but once I explain it using its commonly accepted definition she can now read the commonly accepted word in a trade magazine and understand what they're talking about. Otherwise she'd never know to link the word to its definition. That's the basic concept of language.
I don't object to "run" but that might be a bad example because machines have been "running" for centuries and because "run" has a tremendous number of separate definitions already.
I don't actually object to the "Flight Recorder" either, I just find it to be a weird name that I probably wouldn't have picked, hence my comment on it.
>* It's weird to me that there seems to be a trend of using "flight" as a metaphor for the runtime of our code. We have "preflight checks" in CORS and now a "flight recorder" on the JVM.*
We're not "using 'flight' as a metaphor for the runtime of our code".
We just adopted wholesale the terms "preflight check" and "flight recorder".
And at least the former has been adopted in several other industries/contexts.
Not really. "Flight recorder" does something quite different than a "jogging tracker"; what a "JVM Recorder" does is a mystery (yes, yes, it records something) - the metaphor of a FDR helps.
So, now the inevitable question comes up again: Why use the OpenJDK downloaded/packaged by Oracle? I use Zulu builds [0] for everything, and the AdoptOpenJDK builds site has removed its not-for-production-use banner [1] (at least I don't see it anymore, not sure if intentional).
A number of companies will happily stand behind OpenJDK builds. I work for Pivotal, we build the JDKs and JREs that we ship to customers (and a lot of other languages too). Red Hat do too.
I'm the head Cat Herder (so to speak) for the AdoptOpenJDK OpenJDK binary build farm. The OpenJDK builds we are producing pass the regular OpenJDK tests, a series of system tests and the official TCK/JCK. The quality bar is high and once we've stabilised this process for Java 8,9,10, 11+ and all of the platforms (AIX, ARM 32/64, Windows, Mac, Linux, z390, zOS etc) then we'll be broadly advertising its service. Whether or not we earn the trust of enterprise, we'll have to see :-).
I also found: https://github.com/ojdkbuild/ojdkbuild while looking for Red Hat's build scripts. I didn't find those, but only because I am bad at searching. They'll be published somewhere.
The goal was to emulate what https://github.com/ojdkbuild/ojdkbuild started many years ago but take it alot further. Adopt will provide completely open transparent infrastructure as code (and infrastructure) for folks to build OpenJDK. We've got Red Hat, IBM, Oracle and SAP + various JUG's participating and I expect it'll become the common build farm for Java going forwards. People are also more than welcome to clone the whole thing and use it internally!
I'd try to find some friendly folks at Microsoft or Google -- I can imagine both being willing to donate some compute and storage, as they're looking for ways to attract Java workloads from AWS.
My best guess is that their plan A of getting a lot of money out of unauthorized users didn't pan out, so they switched to plan B: open-source it in order to make the ecosystem more attractive and discourage people from leaving the ecosystem.
Trying one thing, gathering data, and later deciding on another course of action isn't necessarily inconsistent.
While I still think YourKit is a better profiler and has a better UX, the ability to start/stop/dump metrics collection on a running system without enabling an agent or adding JVM args is a killer addition to JFR, one that I don't think YourKit will be able to complete with.
There's really no comparison between them is there? Regular profiler has their usage but don't they change the runtime characteristic a lot specially in tight loop and cpu bound situations? The biggest advantage of JFR are two folds running it in production, problems that are hard to reproduce and secondly not getting wrong data because the profile has changed the characteristic, forced de-optimization on the code and such.
Exactly this. FR will allow APM vendors (and individual teams) to build solutions on top of a continuous lightweight, always on profiler. It's actually a bit of a game changer for Java / JVM performance
It looks like the only major change today was a move from "Submitted" to "Candidate". This is a good step forward, but it's still far from standardization.
I don't think there is a plan to standardize it. They "just" move the code from the Oracle repo to the OpenJDK repo. I wouldn't assume J9 or Zing will adopt this.
Opps, I believe you are correct. I haven't reviewed the proposal in detail, but are they planning to standardize the event generation side of things? (the parts exposed to running Java applications)?
I am not aware of any such plans. There is a supported API starting with Java 9 http://hirt.se/blog/?p=870 but it is "JDK" (Open/Oracle JDK and derivates) specific and lives in the jdk.jfr module and package.
I am really to see this finally going in having hard about this in last JavaOne. My biggest hope is to see other build on top of this.
E.g. - frameworks, libraries, web-servers exposing their metric through this. Some building other ways to consume the metric from a running recorder. Right now you have to dump it in file and pull that to JMC. But imagine a monitoring tool pulling the data out of the recoding engine on the fly and provide storage, live visualization/analysis.
A lock free low overhead in-memory collector inside the JVM seems very useful even without considering some of the very useful metric that JFR have right now.
Disclaimer: I'm the CEO of jClarity - a Java/JVM APM vendor.
You'll see plenty of APM vendors building on top of this technology. For years we've all tried to build lightweight mechanisms to get vital metrics out of the JVM with regards to Object and Execution profiling and although some strong progress was being made (Honest Profiler, Async Profiler et al), none of them are as comprehensive as Flight Recorder (Oracle did have the advantage of owning Java there).
Our own plans will be to refactor our ML diagnostic engine on top of Flight Recorder data. We're really, really looking forward to this!
Thanks for confirming it. I expected this to be true but assumed I would only be sure when someone releases a product or blogs about an impending one.
I also assume freed from generating the basic metric and the lightweight recording infrastructure will free up resources for more extensive metric and analysis. It would also allow for more innovative exploration.
If I understand correctly it also provides some very helpful building block like high performance stacktrace and timing. I think fast reliable timing (the JVM is widely fractured in it's timer performance) would be helpful even for regular users like me.
You're totally correct. We (jClarity) will likely ditch our proprietary, hand rolled metrics gathering (which we built at great pain wince) in favour of FR. I'd be pretty surprised if all of the other vendors don't do something similar (Why NIH).
Do you know whether Flight Recorder will be a non-commercial feature in Oracle JDK 11 and later? The reason I'm asking is because AppCDS which was a commercial feature in Oracle JDK 8 and is a non-commercial feature in OpenJDK 10 will still be a commercial feature in OracleJDK 10.
Ironically there was never any real legal threat. The whole world freaked out over one totally fabricated story by a rag like The Register and everybody thought Flight Recorder was somehow going to let Oracle sue them. In reality the "commercial features" were free for developer machines, test environments and production environments for "evaluation purposes." It was much more of a CYA thing then some imminent legal apocalypse. That said having it be free in OpenJDK is great.
