Hi!
I had risen this topic during jdk11 bump. but it somehow get lost.
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). 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.
Hello Jiri,
I am not a packager for Fedora, but I am a user (of Fedora) who develops in Java at times. I assume you are referring to a replacement for alternatives (which doesn't work on Silverblue or Fedora CoreOS). The ability to switch between different JDK versions is a must for anyone doing Java programming for different organizations. So anything to make that a smoother operating workflow IMHO is welcome.
Stephen Snow
On Mon, Dec 7, 2020 at 11:23, Jiri Vanek jvanek@redhat.com wrote:
Hi!
I had risen this topic during jdk11 bump. but it somehow get lost.
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). 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@redhat.com mailto:jvanek@redhat.com M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org mailto:java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@lists.fedoraproject.org mailto:java-devel-leave@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.fedoraproject.org
On 12/7/20 5:12 PM, Stephen Snow wrote:
Hello Jiri,
I am not a packager for Fedora, but I am a user (of Fedora) who develops in Java at times. I assume you are referring to a replacement for alternatives (which doesn't work on Silverblue or Fedora CoreOS). The ability to switch between different JDK
No! Not At all!
Alternatives are remaining same. This change is solemnly for build-time only. When we were bumping jdk form 8 to 11. 50% of chanes was to edit source/target flags of javac. I would like to avoid it in future...
versions is a must for anyone doing Java programming for different organizations. So anything to make that a smoother operating workflow IMHO is welcome.
Hm. How come alternatives do not work for SilverBlue and CoreOs?
Stephen Snow
On Mon, Dec 7, 2020 at 11:23, Jiri Vanek jvanek@redhat.com wrote:
Hi! I had risen this topic during jdk11 bump. but it somehow get lost. 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). 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@redhat.com mailto:jvanek@redhat.com M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org mailto:java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@lists.fedoraproject.org mailto:java-devel-leave@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.fedoraproject...
That sounds reasonable, I watched the probelms last time from afar, and didn't envy you. As for alternatives not working in SB or FCOS, I filed a bug against SB, which was closed since there was an upstream bug tracking it. AFAIK, it will be tackled at a later release. Though I am uncertain what later release is the intended target. In the meantime, I am embracing the container workflow more, this includes with my jdk dev projects. As I learn this way more, it does become easier. I guess I should expect a learning curve when I want to use near bleeding edge stuff. Also, the maturing of things like flatpaks, podman, etc... is happening constantly and thus things integrate better. Plus, platforms like Quarkus have gone a long way to making this container based workflow an easier transition than it would be without. Regards, Stephen
On Mon, Dec 7, 2020 at 17:15, Jiri Vanek jvanek@redhat.com wrote:
On 12/7/20 5:12 PM, Stephen Snow wrote:
Hello Jiri,
I am not a packager for Fedora, but I am a user (of Fedora) who develops in Java at times. I assume you are referring to a replacement for alternatives (which doesn't work on Silverblue or Fedora CoreOS). The ability to switch between different JDK
No! Not At all!
Alternatives are remaining same. This change is solemnly for build-time only. When we were bumping jdk form 8 to 11. 50% of chanes was to edit source/target flags of javac. I would like to avoid it in future...
versions is a must for anyone doing Java programming for different organizations. So anything to make that a smoother operating workflow IMHO is welcome.
Hm. How come alternatives do not work for SilverBlue and CoreOs?
Stephen Snow
On Mon, Dec 7, 2020 at 11:23, Jiri Vanek <jvanek@redhat.com mailto:jvanek@redhat.com> wrote:
Hi! I had risen this topic during jdk11 bump. but it somehow get lost. 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). 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@redhat.com mailto:jvanek@redhat.com <mailto:jvanek@redhat.com> M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org mailto:java-devel@lists.fedoraproject.org <mailto:java-devel@lists.fedoraproject.org> To unsubscribe send an email to java-devel-leave@lists.fedoraproject.org mailto:java-devel-leave@lists.fedoraproject.org <mailto:java-devel-leave@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.fedoraproject.org
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com mailto:jvanek@redhat.com M: +420775390109
On 12/7/20 5:29 PM, Stephen Snow wrote:
That sounds reasonable, I watched the probelms last time from afar, and didn't envy you.
90% of most terrible work was done by Fabio. All kudos to him!-)
As for alternatives not working in SB or FCOS, I filed a bug against SB, which was closed since there was an upstream bug tracking it. AFAIK, it will be tackled at a later release. Though I am uncertain what later release is the intended target. In the
I see. Definitely not in next jdk version. Although I recall this issue a bit do you ave the bug id handy?
meantime, I am embracing the container workflow more, this includes with my jdk dev projects. As I learn this way more, it does become easier. I guess I should expect a learning curve when I want to use near bleeding edge stuff. Also, the maturing of things like flatpaks, podman, etc... is happening constantly and thus things integrate better. Plus, platforms like Quarkus have gone a long way to making this container based workflow an easier transition than it would be without.
You are right. Quarkus is fresh air in this area. Jdk packaging as is now is not exactly healthy for container/flatpak world. The only reasonable way is to have base images per JDK:(
Thanx a lto for ideas! J.
Regards, Stephen
On Mon, Dec 7, 2020 at 17:15, Jiri Vanek jvanek@redhat.com wrote:
On 12/7/20 5:12 PM, Stephen Snow wrote:
Hello Jiri, I am not a packager for Fedora, but I am a user (of Fedora) who develops in Java at times. I assume you are referring to a replacement for alternatives (which doesn't work on Silverblue or Fedora CoreOS). The ability to switch between different JDK
No! Not At all! Alternatives are remaining same. This change is solemnly for build-time only. When we were bumping jdk form 8 to 11. 50% of chanes was to edit source/target flags of javac. I would like to avoid it in future... versions is a must for anyone doing Java programming for different organizations. So anything to make that a smoother operating workflow IMHO is welcome. Hm. How come alternatives do not work for SilverBlue and CoreOs?
Stephen Snow On Mon, Dec 7, 2020 at 11:23, Jiri Vanek <jvanek@redhat.com <mailto:jvanek@redhat.com>> wrote: Hi! I had risen this topic during jdk11 bump. but it somehow get lost. 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). 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@redhat.com <mailto:jvanek@redhat.com> <mailto:jvanek@redhat.com> M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org <mailto:java-devel@lists.fedoraproject.org> <mailto:java-devel@lists.fedoraproject.org> To unsubscribe send an email to java-devel-leave@lists.fedoraproject.org <mailto:java-devel-leave@lists.fedoraproject.org> <mailto:java-devel-leave@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.fedoraproject.org
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com mailto:jvanek@redhat.com M: +420775390109
Sorry, I don't seem to be able to locate it now. I'll keep searching and update you later once I find or don't find anything.
On Mon, Dec 7, 2020 at 17:51, Jiri Vanek jvanek@redhat.com wrote:
On 12/7/20 5:29 PM, Stephen Snow wrote:
That sounds reasonable, I watched the probelms last time from afar, and didn't envy you.
90% of most terrible work was done by Fabio. All kudos to him!-)
As for alternatives not working in SB or FCOS, I filed a bug against SB, which was closed since there was an upstream bug tracking it. AFAIK, it will be tackled at a later release. Though I am uncertain what later release is the intended target. In the
I see. Definitely not in next jdk version. Although I recall this issue a bit do you ave the bug id handy?
meantime, I am embracing the container workflow more, this includes with my jdk dev projects. As I learn this way more, it does become easier. I guess I should expect a learning curve when I want to use near bleeding edge stuff. Also, the maturing of things like flatpaks, podman, etc... is happening constantly and thus things integrate better. Plus, platforms like Quarkus have gone a long way to making this container based workflow an easier transition than it would be without.
You are right. Quarkus is fresh air in this area. Jdk packaging as is now is not exactly healthy for container/flatpak world. The only reasonable way is to have base images per JDK:(
Thanx a lto for ideas! J.
Regards, Stephen
On Mon, Dec 7, 2020 at 17:15, Jiri Vanek <jvanek@redhat.com mailto:jvanek@redhat.com> wrote:
On 12/7/20 5:12 PM, Stephen Snow wrote:
Hello Jiri, I am not a packager for Fedora, but I am a user
(of Fedora) who develops in Java at times. I assume you are referring to a replacement for alternatives (which doesn't work on Silverblue or Fedora CoreOS). The ability to switch between different JDK
No! Not At all! Alternatives are remaining same. This change is solemnly for build-time only. When we were bumping jdk form 8 to 11. 50% of chanes was to edit source/target flags of javac. I would like to avoid it in future... versions is a must for anyone doing Java programming for different organizations. So anything to make that a smoother operating workflow IMHO is welcome. Hm. How come alternatives do not work for SilverBlue and CoreOs?
Stephen Snow On Mon, Dec 7, 2020 at 11:23, Jiri Vanek
<jvanek@redhat.com mailto:jvanek@redhat.com <mailto:jvanek@redhat.com>> wrote:
Hi! I had risen this topic during jdk11 bump. but it
somehow get lost. 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). 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@redhat.com mailto:jvanek@redhat.com <mailto:jvanek@redhat.com> <mailto:jvanek@redhat.com> M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org mailto:java-devel@lists.fedoraproject.org <mailto:java-devel@lists.fedoraproject.org> <mailto:java-devel@lists.fedoraproject.org> To unsubscribe send an email to java-devel-leave@lists.fedoraproject.org mailto:java-devel-leave@lists.fedoraproject.org <mailto:java-devel-leave@lists.fedoraproject.org> <mailto:java-devel-leave@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.fedoraproject.org
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com mailto:jvanek@redhat.com <mailto:jvanek@redhat.com> M: +420775390109
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com mailto:jvanek@redhat.com M: +420775390109
Hello, I think this is the pertinent upstream issue https://github.com/fedora-sysv/chkconfig/issues/9
On Mon, Dec 7, 2020 at 12:03, Stephen Snow s40w5s@gmail.com wrote:
Sorry, I don't seem to be able to locate it now. I'll keep searching and update you later once I find or don't find anything.
On Mon, Dec 7, 2020 at 17:51, Jiri Vanek jvanek@redhat.com wrote:
On 12/7/20 5:29 PM, Stephen Snow wrote:
That sounds reasonable, I watched the probelms last time from afar, and didn't envy you.
90% of most terrible work was done by Fabio. All kudos to him!-)
As for alternatives not working in SB or FCOS, I filed a bug against SB, which was closed since there was an upstream bug tracking it. AFAIK, it will be tackled at a later release. Though I am uncertain what later release is the intended target. In the
I see. Definitely not in next jdk version. Although I recall this issue a bit do you ave the bug id handy?
meantime, I am embracing the container workflow more, this includes with my jdk dev projects. As I learn this way more, it does become easier. I guess I should expect a learning curve when I want to use near bleeding edge stuff. Also, the maturing of things like flatpaks, podman, etc... is happening constantly and thus things integrate better. Plus, platforms like Quarkus have gone a long way to making this container based workflow an easier transition than it would be without.
You are right. Quarkus is fresh air in this area. Jdk packaging as is now is not exactly healthy for container/flatpak world. The only reasonable way is to have base images per JDK:(
Thanx a lto for ideas! J.
Regards, Stephen
On Mon, Dec 7, 2020 at 17:15, Jiri Vanek <jvanek@redhat.com mailto:jvanek@redhat.com> wrote:
On 12/7/20 5:12 PM, Stephen Snow wrote:
Hello Jiri, I am not a packager for Fedora, but I am a user
(of Fedora) who develops in Java at times. I assume you are referring to a replacement for alternatives (which doesn't work on Silverblue or Fedora CoreOS). The ability to switch between different JDK
No! Not At all! Alternatives are remaining same. This change is solemnly for build-time only. When we were bumping jdk form 8 to 11. 50% of chanes was to edit source/target flags of javac. I would like to avoid it in future.. versions is a must for anyone doing Java programming for different organizations. So anything to make that a smoother operating workflow IMHO is welcome. Hm. How come alternatives do not work for SilverBlue and CoreOs?
Stephen Snow On Mon, Dec 7, 2020 at 11:23, Jiri Vanek
<jvanek@redhat.com mailto:jvanek@redhat.com <mailto:jvanek@redhat.com>> wrote:
Hi! I had risen this topic during jdk11 bump. but it
somehow get lost. 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). 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@redhat.com mailto:jvanek@redhat.com <mailto:jvanek@redhat.com> <mailto:jvanek@redhat.com> M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org mailto:java-devel@lists.fedoraproject.org <mailto:java-devel@lists.fedoraproject.org> <mailto:java-devel@lists.fedoraproject.org> To unsubscribe send an email to java-devel-leave@lists.fedoraproject.org mailto:java-devel-leave@lists.fedoraproject.org <mailto:java-devel-leave@lists.fedoraproject.org> <mailto:java-devel-leave@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.fedoraproject.org
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com mailto:jvanek@redhat.com <mailto:jvanek@redhat.com> M: +420775390109
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com mailto:jvanek@redhat.com M: +420775390109
Thanx!
I was not aware of this effort.
Thank you a lot for sharing! J.
On 12/7/20 6:29 PM, Stephen Snow wrote:
Hello, I think this is the pertinent upstream issue https://github.com/fedora-sysv/chkconfig/issues/9
On Mon, Dec 7, 2020 at 12:03, Stephen Snow s40w5s@gmail.com wrote:
Sorry, I don't seem to be able to locate it now. I'll keep searching and update you later once I find or don't find anything.
On Mon, Dec 7, 2020 at 17:51, Jiri Vanek jvanek@redhat.com wrote:
On 12/7/20 5:29 PM, Stephen Snow wrote:
That sounds reasonable, I watched the probelms last time from afar, and didn't envy you.
90% of most terrible work was done by Fabio. All kudos to him!-)
As for alternatives not working in SB or FCOS, I filed a bug against SB, which was closed since there was an upstream bug tracking it. AFAIK, it will be tackled at a later release. Though I am uncertain what later release is the intended target. In the
I see. Definitely not in next jdk version. Although I recall this issue a bit do you ave the bug id handy? meantime, I am embracing the container workflow more, this includes with my jdk dev projects. As I learn this way more, it does become easier. I guess I should expect a learning curve when I want to use near bleeding edge stuff. Also, the maturing of things like flatpaks, podman, etc... is happening constantly and thus things integrate better. Plus, platforms like Quarkus have gone a long way to making this container based workflow an easier transition than it would be without. You are right. Quarkus is fresh air in this area. Jdk packaging as is now is not exactly healthy for container/flatpak world. The only reasonable way is to have base images per JDK:( Thanx a lto for ideas! J.
Regards, Stephen On Mon, Dec 7, 2020 at 17:15, Jiri Vanek <jvanek@redhat.com <mailto:jvanek@redhat.com>> wrote: On 12/7/20 5:12 PM, Stephen Snow wrote: Hello Jiri, I am not a packager for Fedora, but I am a user (of Fedora) who develops in Java at times. I assume you are referring to a replacement for alternatives (which doesn't work on Silverblue or Fedora CoreOS). The ability to switch between different JDK No! Not At all! Alternatives are remaining same. This change is solemnly for build-time only. When we were bumping jdk form 8 to 11. 50% of chanes was to edit source/target flags of javac. I would like to avoid it in future.. versions is a must for anyone doing Java programming for different organizations. So anything to make that a smoother operating workflow IMHO is welcome. Hm. How come alternatives do not work for SilverBlue and CoreOs? Stephen Snow On Mon, Dec 7, 2020 at 11:23, Jiri Vanek <jvanek@redhat.com <mailto:jvanek@redhat.com> <mailto:jvanek@redhat.com>> wrote: Hi! I had risen this topic during jdk11 bump. but it somehow get lost. 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). 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@redhat.com <mailto:jvanek@redhat.com> <mailto:jvanek@redhat.com> <mailto:jvanek@redhat.com> M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org <mailto:java-devel@lists.fedoraproject.org> <mailto:java-devel@lists.fedoraproject.org> <mailto:java-devel@lists.fedoraproject.org> To unsubscribe send an email to java-devel-leave@lists.fedoraproject.org <mailto:java-devel-leave@lists.fedoraproject.org> <mailto:java-devel-leave@lists.fedoraproject.org> <mailto:java-devel-leave@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.fedoraproject.org -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com <mailto:jvanek@redhat.com> <mailto:jvanek@redhat.com> M: +420775390109
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com mailto:jvanek@redhat.com M: +420775390109
You are most certainly welcome.
Stephen Snow
On Tue, Dec 8, 2020 at 10:55, Jiri Vanek jvanek@redhat.com wrote:
Thanx!
I was not aware of this effort.
Thank you a lot for sharing! J.
On 12/7/20 6:29 PM, Stephen Snow wrote:
Hello, I think this is the pertinent upstream issue https://github.com/fedora-sysv/chkconfig/issues/9
On Mon, Dec 7, 2020 at 12:03, Stephen Snow <s40w5s@gmail.com mailto:s40w5s@gmail.com> wrote:
Sorry, I don't seem to be able to locate it now. I'll keep searching and update you later once I find or don't find anything.
On Mon, Dec 7, 2020 at 17:51, Jiri Vanek <jvanek@redhat.com mailto:jvanek@redhat.com> wrote:
On 12/7/20 5:29 PM, Stephen Snow wrote:
That sounds reasonable, I watched the probelms last time from
afar, and didn't envy you.
90% of most terrible work was done by Fabio. All kudos to him!-)
As for alternatives not working in SB or FCOS, I filed a bug
against SB, which was closed since there was an upstream bug tracking it. AFAIK, it will be tackled at a later release. Though I am uncertain what later release is the intended target. In the
I see. Definitely not in next jdk version. Although I recall this issue a bit do you ave the bug id handy? meantime, I am embracing the container workflow more, this includes with my jdk dev projects. As I learn this way more, it does become easier. I guess I should expect a learning curve when I want to use near bleeding edge stuff. Also, the maturing of things like flatpaks, podman, etc... is happening constantly and thus things integrate better. Plus, platforms like Quarkus have gone a long way to making this container based workflow an easier transition than it would be without. You are right. Quarkus is fresh air in this area. Jdk packaging as is now is not exactly healthy for container/flatpak world. The only reasonable way is to have base images per JDK:( Thanx a lto for ideas! J.
Regards, Stephen On Mon, Dec 7, 2020 at 17:15, Jiri Vanek
<jvanek@redhat.com mailto:jvanek@redhat.com <mailto:jvanek@redhat.com>> wrote:
On 12/7/20 5:12 PM, Stephen Snow wrote: Hello Jiri, I am
not a packager for Fedora, but I am a user (of Fedora) who develops in Java at times. I assume you are referring to a replacement for alternatives (which doesn't work on Silverblue or Fedora CoreOS). The ability to switch between different JDK No! Not At all! Alternatives are remaining same. This change is solemnly for build-time only. When we were bumping jdk form 8 to 11. 50% of chanes was to edit source/target flags of javac. I would like to avoid it in future.. versions is a must for anyone doing Java programming for different organizations. So anything to make that a smoother operating workflow IMHO is welcome. Hm. How come alternatives do not work for SilverBlue and CoreOs? Stephen Snow On Mon, Dec 7, 2020 at 11:23, Jiri Vanek <jvanek@redhat.com mailto:jvanek@redhat.com <mailto:jvanek@redhat.com> <mailto:jvanek@redhat.com>> wrote: Hi! I had risen this topic during jdk11 bump. but it somehow get lost. 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). 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@redhat.com mailto:jvanek@redhat.com <mailto:jvanek@redhat.com> <mailto:jvanek@redhat.com> <mailto:jvanek@redhat.com> M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org mailto:java-devel@lists.fedoraproject.org <mailto:java-devel@lists.fedoraproject.org> <mailto:java-devel@lists.fedoraproject.org> <mailto:java-devel@lists.fedoraproject.org> To unsubscribe send an email to java-devel-leave@lists.fedoraproject.org mailto:java-devel-leave@lists.fedoraproject.org <mailto:java-devel-leave@lists.fedoraproject.org> <mailto:java-devel-leave@lists.fedoraproject.org> <mailto:java-devel-leave@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.fedoraproject.org -- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com mailto:jvanek@redhat.com <mailto:jvanek@redhat.com> <mailto:jvanek@redhat.com> M: +420775390109
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com mailto:jvanek@redhat.com <mailto:jvanek@redhat.com> M: +420775390109
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com mailto:jvanek@redhat.com M: +420775390109
Ping?
Fabio,Severin, Mikolaj? Any thoughts? On 12/7/20 11:23 AM, Jiri Vanek wrote:
Hi!
I had risen this topic during jdk11 bump. but it somehow get lost.
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). 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.
On Thu, Dec 10, 2020 at 11:54 AM Jiri Vanek jvanek@redhat.com wrote:
Ping?
Fabio,Severin, Mikolaj? Any thoughts? On 12/7/20 11:23 AM, Jiri Vanek wrote:
Hi!
I had risen this topic during jdk11 bump. but it somehow get lost.
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). 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.
Sorry for being quiet so far. I have been thinking about a solution for this that's based on macros, but I hadn't written it down yet.
My solution would look something like this: - introduce %_javac_source, %_javac_target, and %_javac_release macros - use those macros in %mvn_build (not sure if there's an ant equivalent, those build.xmls are all incompatibly different ...) - define default values for those macros (possibly set them to "8" for now, and bump to something higher later, as necessary) - if necessary, users can override those values in their .spec files, by doing something like "%global _javac_target 9"
Fabio
On 12/10/20 11:59 AM, Fabio Valentini wrote:
On Thu, Dec 10, 2020 at 11:54 AM Jiri Vanek jvanek@redhat.com wrote:
Ping?
Fabio,Severin, Mikolaj? Any thoughts? On 12/7/20 11:23 AM, Jiri Vanek wrote:
Hi!
I had risen this topic during jdk11 bump. but it somehow get lost.
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). 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.
Sorry for being quiet so far. I have been thinking about a solution for this that's based on macros, but I hadn't written it down yet.
Thank you very much. You are one step ahead.
My solution would look something like this:
- introduce %_javac_source, %_javac_target, and %_javac_release macros
- use those macros in %mvn_build (not sure if there's an ant
equivalent, those build.xmls are all incompatibly different ...)
- define default values for those macros (possibly set them to "8" for
now, and bump to something higher later, as necessary)
- if necessary, users can override those values in their .spec files,
by doing something like "%global _javac_target 9"
Right. Your ideas are 100% aligned with mine. For ant, sed-like approach may be enough. To make it in simialr way as are %pom_remove_artifact or friens, may be enough.
For jdk17, they will need to grow from 8 to 11 I'm afraid.
Correct, overwriting is is necessary to e allowed.
Thanx a lot for shsring the ideas.
J.
Fabio _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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.fedoraproject...
On Mon, Dec 7, 2020 at 11:26 AM Jiri Vanek jvanek@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 source/target/release values. What values do you propose to set them to? 11?
Historically we always tried to stay close to upstream and follow their choices for source/target/release whenever possible, changing 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* 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.
-- Mikolaj Izdebski
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@redhat.com M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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.fedoraproject...
On Tue, 2020-12-15 at 11:08 +0100, Mikolaj Izdebski wrote:
Therefore IMHO it makes most sense to force *minimal* source/target/release values, or change combinations that are known not to work for sure.
Agreed. Changing only the lower bound makes sense. However, I'm not sure how feasible this is to implement correctly.
Thanks, Severin
Hi! Mikolaj!
On 12/15/20 11:08 AM, Mikolaj Izdebski wrote:
On Mon, Dec 7, 2020 at 11:26 AM Jiri Vanek jvanek@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@redhat.com M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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.fedoraproject...
java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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.fedoraproject...
On Tue, Dec 15, 2020 at 11:39 AM Jiri Vanek jvanek@redhat.com 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@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
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?
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 ?
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.
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?
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 values lower than upstream. Besides that there are cases in which newer bytecode introduces very significant performance gains (one example I remember is the use of Invokedynamic in Groovy). Compiling for older releases would introduce performance regressions when compared to upstream builds.
-- 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@redhat.com M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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.fedoraproject...
java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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.fedoraproject...
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com M: +420775390109
On 12/15/20 12:01 PM, Mikolaj Izdebski wrote:
On Tue, Dec 15, 2020 at 11:39 AM Jiri Vanek jvanek@redhat.com 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@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
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@redhat.com M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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.fedoraproject...
java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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.fedoraproject...
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com M: +420775390109
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 necessary.
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@redhat.com wrote:
On 12/15/20 12:01 PM, Mikolaj Izdebski wrote:
On Tue, Dec 15, 2020 at 11:39 AM Jiri Vanek jvanek@redhat.com 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@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
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@redhat.com M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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.fedoraproject...
java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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.fedoraproject...
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com M: +420775390109
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com M: +420775390109
On 12/15/20 1:55 PM, Mikolaj Izdebski wrote:
I have a feeling that there is a misunderstanding about what the
Nope:) We have just very different points of view on it. Thank you for yours.
problem is, so I'll elaborate what I think about setting source/release/target different from upstream.
Let's distinguish 3 distinct cases:
- 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
reproducibility yes, but should not threaten stability of build. Anyway, for both cases the fedora support for this would be an improvement.
carry temporary downstream patches fixing the issue (setting
...and actually reducing the amount of local patches.
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
Well, half of the packages have now source/target to old, and second half have source/target to new. So this adjust is already heavily happening. Not having the macros leads to to wide bytecode diversity and multipling of comapct packages.
with Maven and Ant this can be easily automated with no changes to
Can you please elaborate here? I'm not sure If I understand how to do this automation correctly.
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.
Still the patch is needed. With macros, the packager will be at least aware of suggested level of bytecode, and not spawning random values and causing libraries - unnecessary - incompatibility.
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
No. Considering stability of java and java api, specially after jdk9, there should be minimal, or none at all, risk of hidden bug.
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 necessary.
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
I can not disagree with this. Maybe the solution can be, that the logic of macros will be more complex, and will apply only if the used source/target(/release) would be lower then lowest supported? In that moment it would save some work during the jdk17 bump, but will not unify the bytecode level of distro. (which is not possile anyway, as there will always be also newest packages, which will require newest bytecode, ut at least majority of libraries will be aligned)
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.
Which is what I'mt trying to do? To do it in xmvn/xant and to adjust specfile only if you need to get out of distro defaults? Of course out of ant/maven world, the packager would need to adjust specfile if he will wish to use the macros.
On Tue, Dec 15, 2020 at 1:02 PM Jiri Vanek jvanek@redhat.com wrote:
On 12/15/20 12:01 PM, Mikolaj Izdebski wrote:
On Tue, Dec 15, 2020 at 11:39 AM Jiri Vanek jvanek@redhat.com 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@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
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@redhat.com M: +420775390109 _______________________________________________ java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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.fedoraproject...
java-devel mailing list -- java-devel@lists.fedoraproject.org To unsubscribe send an email to java-devel-leave@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.fedoraproject...
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com M: +420775390109
-- Jiri Vanek Senior QE engineer, OpenJDK QE lead, Mgr. Red Hat Czech jvanek@redhat.com M: +420775390109
Hi!
I gave this few thoughts over Christmas, and my opinion remains. It is better to have default distro bytecode version then to stick on upstream for 100%. If the change of projects source/target would kill the project, then it is always easy to turn back to it. As it seems, Fabio is already more fat then me, then I condemn myself to helping hand only.
It may be that I'm just to scared of boring source/target amending when jdk17 arrives.
J. On 12/7/20 11:23 AM, Jiri Vanek wrote:
Hi!
I had risen this topic during jdk11 bump. but it somehow get lost.
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). 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.
java-devel@lists.fedoraproject.org