[HN Gopher] Red Hat ported OpenJDK to 64-bit ARM: A community hi...
___________________________________________________________________
Red Hat ported OpenJDK to 64-bit ARM: A community history
Author : pabs3
Score : 126 points
Date : 2021-02-01 15:13 UTC (7 hours ago)
(HTM) web link (developers.redhat.com)
(TXT) w3m dump (developers.redhat.com)
| BenoitP wrote:
| Nice!
|
| I guess the next target is to do RISC-V. I think it only works
| with the interpreter at the moment.
| smspf wrote:
| This is nice and makes Red Hat look like an amazing OSS
| contributor, which I think they are. But truth be told, things
| were not that easy when it comes to RHEL and derivates on
| aarch64. As contractors working on getting stuff working on
| aarch64, I know we struggled quite a bit to get CentOS7 to get to
| the level Ubuntu was at the time on aarch64. And real progress
| (i.e. getting a fully working distro for our intents at the time)
| was only seen after money were thrown and a contract was signed.
|
| The bottleneck however paid off imo - Red Hat insisted on doing
| things slow and steady, so once things started landing in the
| distro, they just worked. Unlike other distros which touted
| aarch64 support early, but struggled to fix issues along the way.
|
| I remember working with OpenJDK and Opendaylight on aarch64. The
| crashes I've seen were terrifying. The JVM crashed so hard, our
| expert Java developer laughed 30 minutes straight looking at one
| trace. To this day I have no idea what was so funny, as he
| couldn't explain it in a simple manner and I lost interest.
|
| Anyway, thank you Red Hat developers for all the work (minus the
| systemd "architects", but that's a different story).
| nerpderp82 wrote:
| I love this writeup, esp around how the dev team architected the
| work to derisk the work before hardware was available and how the
| emulator/instruction interpreter actually sped up development
| velocity over using hardware directly.
| bitcharmer wrote:
| Java for ARM is really exciting. I'm wondering however how Java
| Memory Model implementation performs on ARM.
|
| JMM offers pretty strong guarantees via the fundamental happens-
| before relationships in program behaviour. It's relatively easy
| to implement on x86's strong TSO, but ARM is extremely
| problematic to offer the same guarantees on.
|
| Can't wait to run some concurrency benchmarks on this platform.
| monocasa wrote:
| PowerPC has pretty much the same memory model as the ARM
| variants, so it's a more or less solved problem thankfully.
| andrewshadura wrote:
| Imagine a Red Hat evil twin, developing an Arm64 port behind the
| closed doors, releasing it under SSPL, requiring a CLA and not
| accepting merge requests for a potentially paid feature, Windows
| on Arm64 support.
| INTPenis wrote:
| That's business as usual. Open source is breaking the norm of
| the corporate world and that is usually what makes a product
| like raspberry pi gain traction. Because it's accessible enough
| for regular people to play with for free.
|
| Countless manufacturers have made closed products and sold them
| for license money. Nothing new there.
| ryukafalz wrote:
| Thankfully they couldn't; OpenJDK is released under the GPL.
| Copyleft works, people!
| Alupis wrote:
| > Thankfully they couldn't; OpenJDK is released under the
| GPL. Copyleft works, people!
|
| Not quite.
|
| There are many commercial JDK/JVM offerings that are closed
| source and survive very well with their "secret sauce"
| (usually GC related), such as Azul's Zing JVM.
|
| Red Hat's customer base that used JavaEE containers (and just
| Java code in general) was large enough that Red Hat could
| have easily decided to implement and maintain their own JDK
| offering - but they didn't.
|
| Probably based on Red Hat's history of being a good open
| source "netizen", they chose to use the GPL code even though
| they did not have to.
|
| We're all better off because of Red Hat's contributions to
| OpenJDK (porting to 64 bit ARM included) - but that's not
| exactly "Copyleft works!".
| pjmlp wrote:
| Just like there are many commercial C and C++ offerings, so
| is the beauty of language standards and independent
| implementations.
| ece wrote:
| Redhat is a big contributor to OpenJDK, so there's really
| less of a "maybe not" than you think. Even Azul maintains
| an OpenJDK distribution, so copyleft is playing a part in
| keeping things more open and supported than not.
| Alupis wrote:
| The part OP missed, and perhaps you may be overlooking,
| is none of these companies are required to use OpenJDK
| (and the GPL'ed code) for some unavoidable business
| reason.
|
| They opted-into using it consciously.
|
| Red Hat because they embrace Open Source above all else
| (or at least did at the time), and Azul as opportunists
| during the decline of Oracle JDK as a way to get Java
| users into their ecosystem (and eventually make money).
|
| OpenJDK is wildly popular as the defacto reference
| implementation of Java, due to moves Oracle made a few
| years back (on purpose to push Java language development
| into a more community-driven approach).
|
| OpenJDK is good, but there are reasons people seek out
| custom implementations (massive heaps, pauseless GC,
| better tooling and monitoring, re-implemented IO, etc).
|
| All that is to say, contrary to OP's original assertion,
| it's not that Red Hat "couldn't" release some closed
| source JDK... they chose to embrace the GPL'ed code.
|
| The notion that "Copyleft Works!" is by compelling
| companies to open source their GPL'ed code. That's not
| what happened here.
| ece wrote:
| This is really a distinction without a difference, none
| of these companies choose to forego a OpenJDK
| distribution and all of them actually contribute to it.
| If it wasn't compelling to do these things, they wouldn't
| do it.
|
| FOSS and copyleft isn't about requiring anyone to do
| anything, it's about increasing user freedoms. Users and
| developers have more choice today in the Java ecosystem
| thanks to all of JDK distributions. I think it's you who
| has mistaken OPs comment to mean companies are being
| required to do something, when in fact everyone is
| benefiting by playing by the same copyleft rules.
| pron wrote:
| Just so that people understand, OpenJDK is the name of
| Oracle's implementation of Java, to which Red Hat, SAP,
| Intel, Azul, Google, Twitter and others contribute, but
| Oracle contributes ~90% of the work. "Oracle JDK" is
| Oracle's support subscription, but the source code to
| that software is OpenJDK. A couple of years ago Oracle
| completed open-sourcing the entire JDK, making the JDK
| fully free and open source for the first time in Java's
| history, and now it offers no proprietary features. It
| also started focusing more on, and shifting people's
| attention to, the OpenJDK brand.
|
| Because Oracle owns the OpenJDK code, only Oracle and
| companies that license the OpenJDK source code under a
| proprietary license from Oracle, like Azul, can release
| closed-source implementations of the JDK that are based
| on OpenJDK.
|
| (I work at Oracle on Java, i.e. OpenJDK)
| Alupis wrote:
| This isn't true anymore. OpenJDK source is all GPL,
| except for any special bits that Oracle retained for
| their own JDK offering.
|
| A little over a year ago, Oracle stepped back as the
| "standard" JDK and became just another JDK vendor.
|
| Anyone is free to take OpenJDK sources, compile and offer
| prebuilt binaries now.
| pron wrote:
| Yes, Oracle open sourced its entire JDK project, i.e.
| OpenJDK, but while anyone can offer builds under the
| GPL's license, Oracle and its licensees can publish
| builds under a proprietary license. Oracle hasn't stepped
| back from anything, and, in fact, has only increased its
| investment. OpenJDK _is_ the Oracle implementation. We
| 've just shifted branding focus to the OpenJDK brand
| rather than the "Oracle JDK" brand, which is now the name
| of a support subscription.
| Alupis wrote:
| We could be splitting hairs here - but Oracle has indeed
| stepped back from being the "official" offering.
|
| Each new LTS JDK release gets a "caretaker" which
| provides the "official" OpenJDK build for that release.
| Azul gets a turn, Oracle gets a turn, etc. This is a
| stark contrast to pre-JDK9 where Oracle was the only
| "official" build.
|
| Starting with JDK9, the licensing for an Oracle-provided
| JDK got a lot more murky, which seems to have been on
| purpose (to push Oracle into a support position instead
| of leader position). It cleared the way for Oracle to be
| "just another vendor offering paid support" along with
| IBM, Red Hat, AdoptOpenJDK, Azul, Amazon, etc.
|
| This transition was started around OpenJDK7, where Oracle
| made a lot of effort to make OpenJDK the "upstream" and
| "reference" implementation for all other JDK's and the
| language specification.
|
| While many OpenJDK contributors are on the payroll of
| Oracle, it wouldn't be fair to say they are steering the
| entire ship at this point, nor does anyone require a
| license agreement to offer OpenJDK binaries - with the
| exception of actually calling it "OpenJDK" (see agreement
| above for "sharing" LTS releases) - hence "AdoptOpenJDK"
| and "Zulu JDK", etc... all OpenJDK builds that don't call
| themselves OpenJDK.
|
| It was one of the more surprising things Oracle has done
| in years... and many applauded the changes.
| syrrim wrote:
| If others contribute to it, how can oracle license it to
| azul?
| pron wrote:
| Like other large open-source projects by Google,
| Microsoft and others, contributors sign a contributor's
| agreement that gives Oracle joint ownership. This means
| that, in addition to the GPL license, either you or
| Oracle can license that code as you or they please. This
| is a fairly standard practice.[1]
|
| [1]: https://en.wikipedia.org/wiki/Contributor_License_Ag
| reement
| geodel wrote:
| Yeah imagine of the evil of asking money from customers for
| work done or service provided. Never heard such thing in human
| history.
| andrewshadura wrote:
| No, the evil of pretending to be open source and pro
| community, but only really caring about $PSEUR.
| pjmlp wrote:
| If the community chooses MIT/BSD inspired licenses, they
| don't care about such companies coming into action.
| josephcsible wrote:
| How often does the community choose a non-copyleft
| license? What I always see is a company choosing a non-
| copyleft license.
| spijdar wrote:
| I'm a sample size of one, but I often pick a permissive
| BSD/MIT license for the personal software I develop, and
| at times will pick BSD-licensed over GPL-licensed
| software. I prefer the brevity and clarity of the shorter
| licenses, personally. I've also found that, sometimes, if
| there are two similar projects with a BSD vs GPL split,
| the BSD project tends to be more pragmatic and focused on
| the product/code more, while GPL projects err towards
| ideology, possibly at the cost of functionality. OpenSSH
| vs lsh as an example.
| pjmlp wrote:
| All the time, in the OpenBSD, NetBSD, FreeBSD ecosystems.
|
| In fact, being anti-GPL has become kind of fashionable,
| so there you have it.
___________________________________________________________________
(page generated 2021-02-01 23:01 UTC)