Re: Macros controlling the source/target/release level flags for javac

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


I have a feeling that there is a misunderstanding about what the
problem is, so I'll elaborate what I think about setting
source/release/target different from upstream.

Let's distinguish 3 distinct cases:
1. Upstream build calls Java compiler passing neither source/target
nor release arguments
2. Upstream build calls Java compiler with source/target that don't
work with Java compiler being used
3. Upstream build calls Java compiler with source/target that do work
with Java compiler being used

In case 1. the lack of source/target is an issue that threatens build
reproducibility and should be brought to upstream. Fedora packages can
carry temporary downstream patches fixing the issue (setting
source/target) until upstream accepts the change. Once the change is
accepted, this case reduces to 2. or 3.

In case 2. source/target need to be fixed downstream. For builds done
with Maven and Ant this can be easily automated with no changes to
individual spec files. Maven and Ant can detect cases in which
source/target specified in build configuration (pom.xml or build.xml)
has no chances of working with JDK being used and adjust them to
lowest values supported by the compiler. For packages using other
build systems, or calling javac directly, this can be done by patching
upstream code.

In case 3. downstream build should work and there should be no reason
to change source/target set by upstream. Any deviation from upstream
choices of source/target is a risk of introducing hidden bugs or other
subtle differences from upstream builds. Package maintainers can still
override source/target chosen by upstream, at their discretion - there
should be no system-wide setting overriding upstream choices unless

To summarize: First of all, packages should stay as close to upstream
as possible, which means using the same source/release target as
upstream, as long as this is possible, deviating upstream choices only
when necessary. Secondly, spec file should not be cluttered with
source/release settings - whenever possible the logic to adjust
source/target should be moved to build systems that are responsible
for calling Java compiler.

On Tue, Dec 15, 2020 at 1:02 PM Jiri Vanek <jvanek@xxxxxxxxxx> wrote:
> On 12/15/20 12:01 PM, Mikolaj Izdebski wrote:
> > On Tue, Dec 15, 2020 at 11:39 AM Jiri Vanek <jvanek@xxxxxxxxxx> wrote:
> >>
> >> Hi! Mikolaj!
> >>
> >> On 12/15/20 11:08 AM, Mikolaj Izdebski wrote:
> >>> On Mon, Dec 7, 2020 at 11:26 AM Jiri Vanek <jvanek@xxxxxxxxxx> wrote:
> >>>> The idea is, to provide rpm macros, keeping the default source/target eventually - for jdk11 and up -the release - numbers for javac to use.
> >>>> Then to provide tooling, which will help packagers to use them - for ant and maven it should be simple. For others, probably nothing to do on our side, each packager will be able to patch/sed theirs builds as necessary (Still it will help  a lot for future).
> >>>
> >>> You seem to be implying that there should be a distro-wide default for
> >>
> >> Correct
> >
> > And do you propose to always override these values set by upstreams
> > with distro-specific values, or provide defaults only in case
> > upstreams don't set explicit source/release/target?
> I propose to have macros, suggesting system wide default, so anybody can use javac -source %_javac_source - target %_javac_target or sed s;<source>5</source>;<source>%_javac_source</source>/g and similarly, instead of during each system jdk bump, adjust those manually.
> In addition, I propose that xmvn does use those by default.
> Both macros and xmvn must remain to be configurable to ignore them and/or to re-set them.
> >
> >>> source/target/release values. What values do you propose to set them
> >>> to? 11?
> >>
> >> No, 8.
> >
> > So even if upstream builds with --source 11 --target 11, in Fedora you
> > want to override their decision and build the software with --source 8
> > --target 8 ?
> Not forcibly, but yes.
> >
> >> Once we move to jdk17 as system JDK, the value will be enforced to rise to 11.
> >>>
> >>> Historically we always tried to stay close to upstream and follow
> >>> their choices for source/target/release whenever possible, changing
> >>
> >> There is no upstream of source/target/release. Javac always by default compile for its current version. javac8 would default to source/target of 8, java11 to 11 and so on.
> >> The usptream we can speak about, is oldest supported version of javac. Now, for jdk 11  it is 6. For jdk17 it will be 11. So in this, we are keeping perfectly aligned with uptream. And there is absolutey no wish to bend this (eg patch javac of jdk17 to eat source/target 8)
> >
> > What I meant is that most of upstream projects do pass source/target
> > to javac. Projects built with Maven always do that. For upstreams that
> > don't set these values I consider this as a bug and try to contact
> > them to fix the issue.
> Ok. I misinterpreted the usptream. I had in mind OpenJDK, where you care about generic java project.
> I partially agree you. And it is one of the reasons  i consult this proposal before doing any rsh steps.
> Yes, xmvn will have to step into this - if we agree on xmvn direct support.
> if not, then at least %pom_set_source %pom_set_target %pom_set_release  should be created.
> Where you think in forward positive, I think more backward positive, and to bump the 100 source/target calls from 1.5 or 1.4 to 1.6 or 1.8 was really somthing I do not want to repeat.
> >
> >>> them only when necessary. A common case was upstreams targeting very
> >>> old Java releases that are no longer supported by current Java
> >>> compilers. Therefore IMHO it makes most sense to force *minimal*
> >>
> >> Right, the limit was set to 5 versions to past.
> >> On contrary, i think it have snese to have default od oldest supported.
> >> New projects usually built on older libreries. And it is library set where this change is primarily targetting. If old library is built by old source/target, is still usbale by newer source/target project and remains usable for older projects too.
> >>
> >>
> >> Anyway toolchain shold be aware of  %_javac_source, %_javac_target, and %_javac_release being %nil, and default to defaults in that state.
> >
> > Maybe I don't understand what these macros are supposed to mean
> > exactly. Can you explain what you mean by them?
> They will keep the default suggested bytecode/java-api version of given dsitribution.
> Right now, it would be
> %_javac_source 8
> %_javac_target 8
> %_javac_release %nil
> For system jdk of 17, it will be
> %_javac_source 11
> %_javac_target 11
> %_javac_release 11
> Note, that I hesitate a bit with the last - release - one.  As it is much more restricting then source/target. And although much more safe in runtime, a bit tricky, maybe enforcing unnecessary patching,  in compile time.
> Those macros shoudl be used by packager in way I summe dup a bit more up.
> >
> >>
> >>> source/target/release values, or change combinations that are known
> >>> not to work for sure. But overriding these values across the whole
> >>> distro is not a good idea in my opinion only, it only introduces
> >>> unnecessary deviation from upstreams, and potentially introduces bugs.
> >>
> >> Maybe. Although I doubt it a lot. The release switch is much more tricky one. But is only 9+. So for source/target of 8 we do not need to worry about it.
> >> During bump of system jdk  to jd11 pretty common use-case raised - where we tried to compile all by defaults, then all was suddenly source/target 11. So all packages, wihch have to remain on jdk8 (less then 10%) suddenly couldnot use theirs dependencies and so they rebuilt  depndencies with source/target 8 anyway, or used embedded ones or created comapct legacy pakcages. From those three, the first is smallest evil.
> >
> > I think that upstream projects not setting explicit
> > source/target/release should be fixed individually, fixes should be
> > forwarded upstream.
> >
> >> So compiling with oldest possible source/target still seems to be rigt to me.
> >
> > I disagree. Most projects won't build if you set source/target to
> Hmm. If you are right, then the proposal will die in very early stage. But I don't think so.  Where I agree with statement that project should have its jdk hardcoded project should be also asl multi-jdk as possible.
> And many are keeping it and onloy set minimal viable JDK - which is usually reflected in source/targer, or in newer release.
> > values lower than upstream. Besides that there are cases in which
> > newer bytecode introduces very significant performance gains (one
> Again, yo uare thinking abot future, where I'm in past. And there is few haundred packages which insits on ebing 1.6 or later comaptible. And those are my primary target audience.
> The macros should es defautl as possible and as optional as possible (however idiotic this sounds)
> > example I remember is the use of Invokedynamic in Groovy). Compiling
> > for older releases would introduce performance regressions when
> > compared to upstream builds.
> Hmm. The performance boost is in 99& from JVM. not from bytecode itself.
> >
> >>>
> >>> --
> >>> Mikolaj Izdebski
> >>
>  Thaxn a lot!
> >>>
> >>>> I do not know how to provide them as default (except hardcoding in xmvn, and only allow to disable them on demand).
> >>>>
> >>>> This will smooth the bump to jdk17 in f36 really a lot.
> >>>>
> >>>>
> >>>> Thoughts?
> >>>>   J.
> >>>> --
> >>>> Jiri Vanek
> >>>> Senior QE engineer, OpenJDK QE lead, Mgr.
> >>>> Red Hat Czech
> >>>> jvanek@xxxxxxxxxx    M: +420775390109
> >>>> _______________________________________________
> >>>> java-devel mailing list -- java-devel@xxxxxxxxxxxxxxxxxxxxxxx
> >>>> To unsubscribe send an email to java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> >>>> Fedora Code of Conduct:
> >>>> List Guidelines:
> >>>> List Archives:
> >>> _______________________________________________
> >>> java-devel mailing list -- java-devel@xxxxxxxxxxxxxxxxxxxxxxx
> >>> To unsubscribe send an email to java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> >>> Fedora Code of Conduct:
> >>> List Guidelines:
> >>> List Archives:
> >>>
> >>
> >>
> >> --
> >> Jiri Vanek
> >> Senior QE engineer, OpenJDK QE lead, Mgr.
> >> Red Hat Czech
> >> jvanek@xxxxxxxxxx    M: +420775390109
> >>
> >
> --
> Jiri Vanek
> Senior QE engineer, OpenJDK QE lead, Mgr.
> Red Hat Czech
> jvanek@xxxxxxxxxx    M: +420775390109
java-devel mailing list -- java-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to java-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct:
List Guidelines:
List Archives:

[Index of Archives]     [Red Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux