Supporting illumos (related to JEP-362)

Peter Firmstone peter.firmstone at
Wed Oct 9 04:15:03 UTC 2019

+1 for gcc.



On 7/10/2019 7:21 PM, Magnus Ihse Bursie wrote:
> On 2019-10-04 16:02, Peter Tribble wrote:
>> The illumos project is a continuation of the OpenSolaris project. It
>> has an active community, has a number of distributions, and a number
>> of commercial companies use it as the basis for their products.
>> Currently, illumos uses the Solaris port of OpenJDK, which mostly
>> works because Solaris and illumos share a common heritage.
>> The recent JEP 362 ( impacts
>> illumos, as OpenJDK currently classes us as a Solaris port.
>> Prompted by JEP 362, we would like to see the creation of an illumos
>> porting project, distinct from the Solaris port. There's still work to
>> be done on defining that project and establishing its context - more
>> below.
>> One difference is that illumos ports tend to use gcc, rather than the
>> Studio compilers. This should make illumos much closer to the Linux
>> and BSD ports.
> From a pure build point of view, Solaris Studio has been one of the 
> major problems with the Solaris port. It has non-standard behavior, 
> lacking lots of essential functionality, and has continuously included 
> new compiler bugs in every release. Changing to gcc will certainly 
> help in that regard. But you must realize that a switch will not be 
> trivial -- there are numerous instances where the assumption "solaris 
> means solstudio" is made, often without the original author realizing 
> this. While the intention in the build system has always been that the 
> idea of "toolchain" and of "operating system" should be separate, in 
> practice we have a 1-to-1 relationship between toolchains and OSes, 
> and that makes it hard in practice to uphold this distinction, since 
> it becomes purely theoretical.
> If it will turn out that the community will step up to both support an 
> ongoing Solaris port (using solstudio), and also add a new Illumos 
> port (using gcc), the already-underdeveloped Solaris code will need to 
> be re-written flexible enough to accommodate two different compilers. 
> The only platform so far where we do this is on Linux where both gcc 
> and clang are supported (but in practice, only gcc is used), and they 
> are way more closely related than gcc and solstudio. This might turn 
> out to be a hard task, where the responsibility needs to be shared 
> between an ongoing solaris port and a new Illumos port.
> Of course, this only covers the build part. The *real* hurdle will of 
> course lie in keeping the actual code base up to date with the changes 
> going on in the rest of the JDK.
> /Magnus
>> Separating illumos from Solaris also has a precedent in the Go project,
>> where the recent Go 1.13 release recognized illumos as a separate (but
>> related) platform.
>> If others wish to see Solaris support within OpenJDK continue, we're
>> happy to work with that. It still makes sense to regard Solaris and
>> illumos as different platforms, as both the platform and toolchain
>> have diverged from their shared ancestry.
>> One possibility I can see would be for the community to support the
>> GCC toolchain for the Solaris port rather than Studio. That would be
>> very similar to an illumos port.
>> Likewise, illumos still supports the SPARC architecture. If SPARC
>> support was retained for other operating systems, we would be happy to
>> collaborate on that. Supporting SPARC is not something we could do on
>> our own, though, and it wouldn't be a primary focus for us.
>> At this point we're interested in what other proposals there might be
>> to respond to JEP 362, so that we can ensure that the illumos proposal
>> does not unnecessarily overlap or conflict with other work. I'm 
>> currently
>> driving this within illumos, and am happy to engage with others to 
>> ensure
>> a successful outcome.
>> Thank you!

More information about the jdk-dev mailing list