
Flight Recorder becomes part of OpenJDK - jsiepkes
http://openjdk.java.net/jeps/328
======
clhodapp
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.

~~~
wpietri
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?

~~~
szemet
Yes. Flying is just a faster way of transportation than (the traditional)
running and in between we had Ruby on Rails...

~~~
DannyB2
Flight Recorder sounds better than either Snail Recorder or Fright Recorder.

------
kodablah
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).

0 -
[https://www.azul.com/downloads/zulu/](https://www.azul.com/downloads/zulu/) 1
- [https://adoptopenjdk.net/](https://adoptopenjdk.net/)

~~~
voltagex_
Because my organisation will shit bricks if they see me running something "not
official" in production.

Oracle is "safe" if you're upper management.

~~~
jacques_chester
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.

~~~
voltagex_
That's a good point, thanks.

~~~
karianna
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 :-).

~~~
jacques_chester
Interesting. I feel silly that it never occurred to me to pop the hood to see
how AdoptOpenJDK was doing things and it strikes me as pretty solid.

For comparsion, here's the repo where we keep our builder for OpenJDK:
[https://github.com/cloudfoundry/java-buildpack-dependency-
bu...](https://github.com/cloudfoundry/java-buildpack-dependency-builder)

I also found:
[https://github.com/ojdkbuild/ojdkbuild](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.

~~~
karianna
The goal was to emulate what
[https://github.com/ojdkbuild/ojdkbuild](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!

~~~
jacques_chester
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.

~~~
karianna
We're talking to MS (looking promising) and Amazon (also) promising. Still
need to reach out to the Google folks directly, thanks for the reminder!

------
resoluteteeth
Didn't they just start suing people for using it without paying two years ago?
What was the point of that if they were just going to open source it?

~~~
KMag
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.

~~~
DannyB2
All it means is that Oracle will do the right thing after exhausting all other
options.

------
kevinconaway
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.

~~~
tmd83
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.

~~~
karianna
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

------
RandomBK
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.

~~~
needusername
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.

~~~
RandomBK
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)?

~~~
needusername
I am not aware of any such plans. There is a supported API starting with Java
9 [http://hirt.se/blog/?p=870](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.

------
tmd83
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.

~~~
karianna
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!

~~~
tmd83
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.

~~~
karianna
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).

------
muxator
I used to remove it from my base Java containers, in order not to risk a legal
litigation from Oracle (just in case).

One row less in my Dockerfiles.

~~~
dnomad
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.

~~~
theshrike79
To be honest, Oracle has a history of being extremely litigous and their
licensing structure is arcane at best.

The best option is just to stay away from Oracle Java and Oracle Mysql stuff
unless you've vetted their use with lawyers on both sides.

