Hi! Mikolaj!
On 12/15/20 11:08 AM, Mikolaj Izdebski wrote:
On Mon, Dec 7, 2020 at 11:26 AM Jiri Vanek <jvanek(a)redhat.com>
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
source/target/release values. What values do you propose to set them
to? 11?
No, 8.
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)
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.
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.
So compiling with oldest possible source/target still seems to be rigt to me.
--
Mikolaj Izdebski
Tahxn 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(a)redhat.com M: +420775390109
> _______________________________________________
> java-devel mailing list -- java-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to java-devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/java-devel@lists.fedoraproj...
_______________________________________________
java-devel mailing list -- java-devel(a)lists.fedoraproject.org
To unsubscribe send an email to java-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/java-devel@lists.fedoraproj...
--
Jiri Vanek
Senior QE engineer, OpenJDK QE lead, Mgr.
Red Hat Czech
jvanek(a)redhat.com M: +420775390109