[packages/rpm-pld-macros] 2.058; try to get stable java environment (javadoc binaries etc)

[Jan Palus]

On 20.04.2026 12:33, Arkadiusz Miśkiewicz via pld-devel-en wrote:
> On 20/04/2026 12:17, Jan Palus wrote:
> 
> > > diff --git a/macros.java b/macros.java
> > > index 2c2ef21..80f1bca 100644
> > > --- a/macros.java
> > > +++ b/macros.java
> > > @@ -66,9 +66,10 @@
> > >   %use_default_jdk()		%{expand:%%global use_jdk %{default_jdk %{?*}}}
> > >   # expands to the value with right jdk for BuildRequires header
> > > -# 'jdk' if %%use_jdk is not defined,  jdk(%%use_jdk) otherwise
> > > -# The requirement will not replace current 'default' JDK
> > > -%required_jdk	jdk%{?use_jdk:(%{use_jdk})}
> > > +# When %%use_jdk is set, require full JDK package (with /usr/bin/javac etc.)
> > > +# to ensure correct JDK tools are in PATH when multiple JDK -base packages
> > > +# are co-installed.
> > > +%required_jdk	%{?use_jdk:%{use_jdk}-jdk}%{!?use_jdk:jdk}
> > 
> > Please don't. This was specifically designed not to rely on PATH for any
> > java stuff but to use non-conflicting *-base-* packages and JAVA_HOME
> > instead.
> > 
> > This change is the reason java-xalan failed today.
> > 
> > If there is an issue with some package I'm even willing to help with
> > packaging rather then going back to "BuildRequires: jdk" and packages
> > having all sorts of kinky ClassDataVersion because one time jdk11 was
> > required for libreoffice and another time jdk23 for eclipse-jdt.
> 
> What's the correct approach?
> 
> Don't remember which but some package called javadoc binary in build process
> and despite %use_default_jdk 8 it used javadoc from some openjdk 2X (as all
> openjdkXX were installed)
> 
> How to make sure that desired paths are set and correct tools are used
> without having to audit every call in build system of such package?
> 
> (some of these could be building fine but still using incorrect binaries (vs
> use_default_jdk setting)).

It would be best if you could provide some example but in short java
world settled on using JAVA_HOME and invoking tools from $JAVA_HOME/bin
so ie $JAVA_HOME/bin/javadoc. There might outliers of course but I'm
happy to look at those cases even if I don't care about the package
myself (like I already did on many occasions).

In terms of packaging it usually boils down to 3 parts:
1. %{use_default_jdk} macro which sets preferred jdk version
2. %buildrequires_jdk macro which effectively puts a BR on one of
non-conflicting openjdkX-jdk-base packages
3. Passing down %{java_home} in %build in package dependant way. Sometimes
it's "export JAVA_HOME=%{java_home}", sometimes "%configure
--with-java-home=%{java_home}" and sometimes it's passing direct paths
to binaries "%configure JAVAC=%{java_home}/bin/javac"

To be completely honest I would even prefer if all of
openjdkX-(jdk|jre)$ packages were forbidden on buuilders.