RFC: backport of JDK-8210863: Remove Xrandr include files from JDK sources

[Andrew John Hughes]

On 30/07/2019 15:59, Mario Torre wrote:

snip...

>>>>
>>>
>>> What is the motivation for this? JDK-8213944 would seem to be evidence
>>> that the removal risks breakage and OpenJDK 8u is an older JDK which may
>>> still need to be built on systems without Xrandr.
>>
>> If an older distribution doesn't support xrandr (which I doubt since
>> this extensions is quite old) then it would not work anyway, as
>> there's no implementation in this patch, just the header files.
>>

True, but it will build. There are a multitude of areas in the code
which will happily compile, but not actually work at runtime due to
missing libraries. It's not something I'm particularly keen on either,
but that's the way it is. I've spent time, mainly in IcedTea, looking
into these and providing the option of building against them instead.
Whether they'd ever be accepted upstream, I don't know.

For example, the codebase doesn't check for Gtk+, but instead has chunks
of its headers, which in this case, are mixed in with the JDK code
rather than being cleanly separated like this Xrandr case. PCSC is
another example. Generally, the whole codebase is designed around
keeping the binary dependencies minimal to increase system
compatibility, so anything optional is searched for at runtime.

You may remember that your Xcomposite patch was altered to do a runtime
lookup before it was approved.

On the OpenJDK side, new build requirements mean new dependencies. I've
had complaints in the past from Gentoo users that they have to install
cups to build OpenJDK, because those headers *aren't* included.

So changing this kind of thing has quite a wide impact.

>> I think such cases would be covered by JDK-8213944 more appropriately,
>> rather than fallback at runtime.

I'm not sure what you mean here. 8213944 adds #ifdefs to the code so
that AIX doesn't need the header. If AIX does ever gain Xrandr, that
will need to be changed again. 8u builds will just start working.

That works for AIX because AIX has never had Xrandr, so AIX = no Xrandr
can currently assumed. To do this generally, you'd have to change the
Xrandr detection in configure to add a define, that can then be used in
the code rather than AIX. Having Xrandr.h would then again be optional.

That's something that would need to be pursued in jdk/jdk first, then
backported. The obvious issue that comes to mind is that you then assume
that no Xrandr on the build machine means no Xrandr on the target
machine, which may not be true. Just as now, it also means that Xrandr
on the build machine doesn't mean the code will run on the target.

> 
> I didn't answer your question. I don't mind not pushing this patch or
> holding it, the only reason why I did the backport is that is for
> consistency with the Oracle JDK and because it has the redhat-interest
> label, if the patch isn't necessary I suggest to remove the label.

I didn't add it to begin with, not sure who did. I assume it was just
out of a desire to sync with 11u.

> 
> Cheers,
> Mario
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew