New candidate JEP: 362: Deprecate the Solaris and SPARC Ports (original) (raw)
Florian Weimer fw at deneb.enyo.de
Wed Nov 6 18🔞09 UTC 2019
- Previous message: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports
- Next message: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
- John Paul Adrian Glaubitz:
On 11/4/19 12:34 PM, Andrew Haley wrote:
I feel like that OpenJDK is starting to develop into a direction of low portability again. When I started working on OpenJDK, I had hoped to be able to help make OpenJDK and Java more portable. But I feel there is no real interest in the OpenJDK community to make Java available on a wide variety of platforms besides x86, ARM, POWER and S390x.
Right. It's not about whether people are interested in the port but whether they are prepared to invest in it. From the AArch64 port point of view, I know just how much investment that is. I already mentioned this in a private reply to someone else: I think one of the problems with OpenJDK in this regard is that the core developers are testing their changes on the platforms supported by Oracle only. I very often see mails with the subject "RFR-NNNNNN: Build broken on $ARCH after JDK-XXXXXXX" which is something I don't see that often in other projects like Rust or GCC. Sure, they also have regressions that affect certain architectures only, but in OpenJDK this happens much more frequently from what I have observed.
It happens regularly with glibc (mostly with Hurd and s390x) and GCC (AIX boostrap failures anyone?). It is simply the result of a tiered building and testing strategy.
I don't know what the numbers look like for OpenJDK, but building glibc on all targets costs between 10and10 and 10and20 in the public cloud. That's just building, no code execution tests have actually run at that point. That means that commits have to be tested in batches, usually after they land in the main development repository.
In my opinion, it would be more efficient if everyone tested their changes on all supported architectures. This way potential regressions are detected much earlier and will most likely not reach get committed to the main repository.
Sure, but that means that if you want to keep the SPARC port alive, you will have to provide porter boxes, builders and testers.
The community has set up a variety of machines in the GCC compile farm to make this possible:
https://gcc.gnu.org/wiki/CompileFarm Any open source developer can request an account there and test their changes on various different platforms.
Aren't all SPARC compile farm machines offline?
That's not the experience I made. Usually GCC developers make their changes across all architectures and test them. It's not that code for m68k is touched by the m68k maintainer only, for example.
GCC is rather successful with their model, in my opinion, which can be seen from the large number of supported targets which even includes very obscure and old ones like PDP-11 and VAX.
GCC faces pretty much the same issues as OpenJDK. As you well know, the m68k target (and a couple of others) will likely be removed along with the removal of the cc0 support due to its maintenance cost, same rationale as with OpenJDK.
- Previous message: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports
- Next message: New candidate JEP: 362: Deprecate the Solaris and SPARC Ports
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]