New candidate JEP: 362: Deprecate the Solaris and SPARC Ports

[Brian Goetz]

I think framing it as if it were about specific projects such as loom is misleading. The reality is that maintaining a port is a lot of work, because the platform moves forward and you have to keep up with those changes. The specific examples of Valhalla or loom are not all that relevant. What is relevant is whether a maintainer is being realistic About how much work it is. It would be terrible for a maintainer to step up and then quit because it was too much work — and worse for us to encourage someone to step up who is not serious about being there for the long haul. So we wanted to be clear what maintaining this port looks like.  (If it was no work at all somebody, maybe Oracle, would already be doing this. )

> 
> Wrt. to the upcoming projects, I don’t know about the
> effort they are causing, nor about their timeline.
> But I know that this is a continuous argument on the
> Oracle side not to do this-or-that. In several of our 
> RFEs it was argued that the change should not be
> made because of this or that project, and now, 
> up to 3 Java versions later, the projects are still not 
> targeted for Java 14.
> 
> Therefore I guess that these larger efforts must only be
> invested at a later point in time, so that supporting
> solaris/sparc until then is possible with medium effort,
> and dropping it when an expensive change must be 
> made can be reconsidered.  Maybe, at that point in time,
> someone else steps up, or helps out with the porting.
> (It might be SAP. If we know we need solaris/sparc, and
> we did the port of a feature for ppc/s390/aix, implementing
> a once-in-a-time effort for solaris/sparc might be feasible.)
> 
> Best regards,
>  Goetz
> 
>>