You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by Julian Hyde <jh...@apache.org> on 2021/12/21 23:37:37 UTC

[DISCUSS] Java 16 and 17 support

Does Calcite now support Java 16 and 17? If think it probably does,
because of these three commits:
* https://github.com/apache/calcite/commit/6d51d277b158ff7073f29ada4a96a7a74c0b46fc
* https://github.com/apache/calcite/commit/dff775d24ae6f8b2e0f3b68fd727ef16fc9cb428
* https://github.com/apache/calcite/commit/a8a6569e6ba75efe9d5725c49338a7f181d3ab5c
/ https://issues.apache.org/jira/browse/CALCITE-4829

However, as of 1.29 RC0 the release notes still say 'This release is
tested on Linux, macOS, Microsoft Windows; using JDK/OpenJDK versions
8 to 15' [1].

The Gradle wrapper uses version 7.3 but the HOWTO still says to use
Gradle 7.2. I don't know whether Vladimir simply forgot to update
howto.md when he made commit 6d51d277 or deliberately did not, because
(in his words [2]) "Manual updates of the version in howto.md is one
of the worst ways to spend time on Calcite."

Anticipating that Vladimir would fail to update howto.md, I added the
instructions "Check that site/_docs/howto.md has the correct Gradle
version" [3] but Rui failed to follow those instructions when making
1.29 RC 0.

If Calcite does indeed support JDK 16 and 17, then the following tasks
need to be done:
 * Update the Gradle version in howto.md
 * Add JDK 16 and 17 to history.md
 * Ensure there are sufficient CI tests for JDK 16 and 17
 * Change the subject of
https://issues.apache.org/jira/browse/CALCITE-4547 to "Support Java 16
and 17", mark it fixed in release 1.29, and retrospectively add it to
1.29's release notes.

Any volunteers to do some or all of these tasks?

Julian

[1] https://github.com/apache/calcite/blob/calcite-1.29.0-rc0/site/_docs/history.md

[2] https://issues.apache.org/jira/browse/CALCITE-4575?focusedCommentId=17340363&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17340363

[3] https://github.com/apache/calcite/blob/master/site/_docs/howto.md#making-a-release-candidate

Re: [DISCUSS] Java 16 and 17 support

Posted by Julian Hyde <jh...@apache.org>.
Thank you! To ensure that JDK 16 and 17 are tested I believe you
should edit either
https://github.com/apache/calcite/blob/master/.github/workflows/main.yml
or https://github.com/apache/calcite/blob/master/.travis.yml.

On Tue, Dec 21, 2021 at 3:45 PM Zhe Hu <il...@163.com> wrote:
>
> Hi, Julian.
> I’m happy to do those tasks.
> Just one question, where or how can I ensure CI tests for JDK16 and JDK17.
>
>
> Best,
>
> |
> Zhe Hu
> |
> ---- Replied Message ----
> | From | Julian Hyde<jh...@apache.org> |
> | Date | 12/22/2021 07:37 |
> | To | dev@calcite.apache.org<de...@calcite.apache.org> |
> | Subject | [DISCUSS] Java 16 and 17 support |
> Does Calcite now support Java 16 and 17? If think it probably does,
> because of these three commits:
> * https://github.com/apache/calcite/commit/6d51d277b158ff7073f29ada4a96a7a74c0b46fc
> * https://github.com/apache/calcite/commit/dff775d24ae6f8b2e0f3b68fd727ef16fc9cb428
> * https://github.com/apache/calcite/commit/a8a6569e6ba75efe9d5725c49338a7f181d3ab5c
> / https://issues.apache.org/jira/browse/CALCITE-4829
>
> However, as of 1.29 RC0 the release notes still say 'This release is
> tested on Linux, macOS, Microsoft Windows; using JDK/OpenJDK versions
> 8 to 15' [1].
>
> The Gradle wrapper uses version 7.3 but the HOWTO still says to use
> Gradle 7.2. I don't know whether Vladimir simply forgot to update
> howto.md when he made commit 6d51d277 or deliberately did not, because
> (in his words [2]) "Manual updates of the version in howto.md is one
> of the worst ways to spend time on Calcite."
>
> Anticipating that Vladimir would fail to update howto.md, I added the
> instructions "Check that site/_docs/howto.md has the correct Gradle
> version" [3] but Rui failed to follow those instructions when making
> 1.29 RC 0.
>
> If Calcite does indeed support JDK 16 and 17, then the following tasks
> need to be done:
> * Update the Gradle version in howto.md
> * Add JDK 16 and 17 to history.md
> * Ensure there are sufficient CI tests for JDK 16 and 17
> * Change the subject of
> https://issues.apache.org/jira/browse/CALCITE-4547 to "Support Java 16
> and 17", mark it fixed in release 1.29, and retrospectively add it to
> 1.29's release notes.
>
> Any volunteers to do some or all of these tasks?
>
> Julian
>
> [1] https://github.com/apache/calcite/blob/calcite-1.29.0-rc0/site/_docs/history.md
>
> [2] https://issues.apache.org/jira/browse/CALCITE-4575?focusedCommentId=17340363&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17340363
>
> [3] https://github.com/apache/calcite/blob/master/site/_docs/howto.md#making-a-release-candidate
>
>

Re: [DISCUSS] Java 16 and 17 support

Posted by Zhe Hu <il...@163.com>.
Hi, Julian.
I’m happy to do those tasks.
Just one question, where or how can I ensure CI tests for JDK16 and JDK17.


Best,

|
Zhe Hu
|
---- Replied Message ----
| From | Julian Hyde<jh...@apache.org> |
| Date | 12/22/2021 07:37 |
| To | dev@calcite.apache.org<de...@calcite.apache.org> |
| Subject | [DISCUSS] Java 16 and 17 support |
Does Calcite now support Java 16 and 17? If think it probably does,
because of these three commits:
* https://github.com/apache/calcite/commit/6d51d277b158ff7073f29ada4a96a7a74c0b46fc
* https://github.com/apache/calcite/commit/dff775d24ae6f8b2e0f3b68fd727ef16fc9cb428
* https://github.com/apache/calcite/commit/a8a6569e6ba75efe9d5725c49338a7f181d3ab5c
/ https://issues.apache.org/jira/browse/CALCITE-4829

However, as of 1.29 RC0 the release notes still say 'This release is
tested on Linux, macOS, Microsoft Windows; using JDK/OpenJDK versions
8 to 15' [1].

The Gradle wrapper uses version 7.3 but the HOWTO still says to use
Gradle 7.2. I don't know whether Vladimir simply forgot to update
howto.md when he made commit 6d51d277 or deliberately did not, because
(in his words [2]) "Manual updates of the version in howto.md is one
of the worst ways to spend time on Calcite."

Anticipating that Vladimir would fail to update howto.md, I added the
instructions "Check that site/_docs/howto.md has the correct Gradle
version" [3] but Rui failed to follow those instructions when making
1.29 RC 0.

If Calcite does indeed support JDK 16 and 17, then the following tasks
need to be done:
* Update the Gradle version in howto.md
* Add JDK 16 and 17 to history.md
* Ensure there are sufficient CI tests for JDK 16 and 17
* Change the subject of
https://issues.apache.org/jira/browse/CALCITE-4547 to "Support Java 16
and 17", mark it fixed in release 1.29, and retrospectively add it to
1.29's release notes.

Any volunteers to do some or all of these tasks?

Julian

[1] https://github.com/apache/calcite/blob/calcite-1.29.0-rc0/site/_docs/history.md

[2] https://issues.apache.org/jira/browse/CALCITE-4575?focusedCommentId=17340363&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17340363

[3] https://github.com/apache/calcite/blob/master/site/_docs/howto.md#making-a-release-candidate



Re: [DISCUSS] Java 16 and 17 support

Posted by Vladimir Sitnikov <si...@gmail.com>.
Julian,

Please refrain from insisting that others should follow the
manual procedures you create.
If you want to have certain manual steps for your own safety, that is fine.
However, don't expect the others will be following all the manual steps you
invent.

I suggest we gather a meetup to discuss exactly that.
I believe it hurts the community A LOT when people object without providing
better alternatives.
I believe it hurts the community when people try solving **non-existing**
issues (see [3]).
I believe it hurts the community when people keep saying "why change, it
works for me" and ignore all the justifications.
I believe it hurts the community when people object over a triviality.

Please, take it seriously.
I do not really want to see the story of "key committers leaving the
project as it happened in log4j 1.x, Mina, etc"

Do you want to see "latest tested Java at the Calcite website"?
Nice. Why don't you make the version appear automatically on all the pages
that need it?
If you lack time, why don't you ask somebody to volunteer on that?

What is the point of asking people doing manual steps and blaming me and
Rui for
inaccurate following the steps you created?

----

We followed your suggestions, and we are here: I forgot editing howto, and
Rui missed it as well.
Could you please understand adding manual steps NEVER really solves the
"documentation being stale" issue?

Julian>you were not prepared to accept simple solutions

Your suggestion regarding howto.md is not a solution, so I am not prepared
to accept non-solutions.

I suggested multiple trivial (!) proposals to keep the documentation
**always** up to date.
You can ignore them, yet, please don't create obscure manual procedures for
others to follow.

A solution in [1]:
Replace "Prerequisite is ... Gradle (version 7.2) on your path"
with "Prerequisite is ... Gradle (see version in
gradle/wrapper/gradle-wrapper.properties) on your path"
^^ single line change yielding always up-to-date documentation, and it
works for ALL Calcite versions, including the past ones.

Note: there's no harm in keeping gradle-wrapper.properties in the source
release, so

A solution in [2]:
Replace "Prerequisite is ... Gradle (version 7.2) on your path"
with "Prerequisite is ... Gradle {% gradle_version_from_wrapper_properties
%}"

The value should be replaced automatically when building the site.
It might look slightly better on a website, however, it would be slightly
misleading.
If someone tries building a slightly old Calcite version, they would need
to use
a different Java/Gradle version.

---

In the ideal world, the thing should be buildable automatically, or
there should be a small README that explains which tools do you need to be
installed.

I do not really expect people to use howto.md for building from the source
archive.

[1]
https://issues.apache.org/jira/browse/CALCITE-4575?focusedCommentId=17339990&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17339990
[2] https://lists.apache.org/thread/mdxdosofclqbp9p5osflwtor264757m4
[3]
https://issues.apache.org/jira/browse/CALCITE-4575?focusedCommentId=17340320&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17340320

Vladimir

Re: [DISCUSS] Java 16 and 17 support

Posted by Julian Hyde <jh...@gmail.com>.
Vladimir,

Apparently there *is* a need to raise mail threads. Your comments in https://issues.apache.org/jira/browse/CALCITE-4575 <https://issues.apache.org/jira/browse/CALCITE-4575> indicated that you were not prepared to accept simple solutions:

> If you absolutely want `howto` page to reflect the exact versions and links,
> then make a script that auto-generates `howto.md` based on the repository
> contents.
>
> Manual updates of the version in howto.md is one of the worst ways to
> spend time on Calcite.

And so here we are.

Julian


> On Dec 22, 2021, at 12:45 AM, Vladimir Sitnikov <si...@gmail.com> wrote:
> 
>> For Gradle upgrades, there’s only one place to modify.
> 
> Juilan,
> Are you willing to keep the place updated?
> If so, there's no need to raise mail threads, please just update it.
> 
> Vladimir


Re: [DISCUSS] Java 16 and 17 support

Posted by Vladimir Sitnikov <si...@gmail.com>.
>For Gradle upgrades, there’s only one place to modify.

Juilan,
Are you willing to keep the place updated?
If so, there's no need to raise mail threads, please just update it.

Vladimir

Re: [DISCUSS] Java 16 and 17 support

Posted by Julian Hyde <jh...@gmail.com>.
For Gradle upgrades, there’s only one place to modify. Add a comment in gradle/wrapper/gradle-wrapper.properties reminding people to also howto.md.

For Java upgrades, there aren’t many places to modify. But supporting a new Java version warrants a Jira case (whose headline is the Java upgrade) and review. That should suffice.

Julian
 

> On Dec 21, 2021, at 11:21 PM, Vladimir Sitnikov <si...@gmail.com> wrote:
> 
> Julian, I know it might be tough, yet:
> 1) I would like you to believe me I just forgot howto and the other places
> hard-code Java versions.
> Of course, "we support Java 17" is a notable change, and it does deserve to
> be in the release notes,
> however, the typical current process is to "file JIRA for notable changes",
> so I did just that, and created
> CALCITE-4829 Bump Gradle to 7.2 and test with Java 17 at GitHub Actions.
> 
> I agree it is unclear how the release manager could deduce they should add
> "Calcite X.Y supports Java 17 now" to the release notes.
> However, I am sure that could have happened with ANY change.
> The release manager often is not in a position to judge which changes are
> notable for the release.
> 
> 2) I previously suggested we should automate the replacement of "the
> maximum supported Java".
> I believe the current failure highlights that once again.
> We can never expect contributors to remember all the places Java versions
> can be mentioned.
> 
> -----
> 
> Julian>then the following tasks need to be done:
> Julian>Update the Gradle version in howto.md...
> 
> I am afraid it does not solve the root cause, so we should do something
> different.
> New Java and Gradle versions would appear, and we would keep forgetting to
> update all the places.
> 
> I suggest we add a variable like max_tested_java_version somewhere
> (gradle.properties? somewhere else?)
> Then we use the variable for building the website and we would check CI
> does test with the given version.
> 
> ^^^ this suggestion will stop those discussions once and forever.
> That is basically the same thing I suggested in CALCITE-4575.
> 
>> Does Calcite now support Java 16 and 17?
> 
> 17 is available, so there's no point in mentioning "Java 16 is supported".
> 
> Current text:
> 
>> Building from a source distribution
>> Prerequisite is Java (JDK 8, 9, 10, 11, 12, 13, 14 or 15) and Gradle
> (version 7.2) on your path
> 
> I would suggest:
> 
>> Building from a source distribution
>> Prerequisite is Java 8 to ${max_tested_java_version} and Gradle (version
> ${gradle_version_from_wrapper}) on your path
> 
> Julian>Change the subject of
> Julian>https://issues.apache.org/jira/browse/CALCITE-4547 to "Support Java
> 16
> Julian>and 17",
> 
> -0.97 for mentioning "support Java 16"
> We do not support that version, we do not test with Java 16, and we do not
> want to add
> Java 16 tests as it would significantly increase test times.
> We just hope it would work.
> 
> Of course, most likely Calcite would work with Java 16 since Calcite works
> with 11 and 17.
> However, please, Julian, please, let us stop mentioning that we support
> irrelevant versions?
> None of Java vendors provide LTS for 16.
> 
> Vladimir


Re: [DISCUSS] Java 16 and 17 support

Posted by Vladimir Sitnikov <si...@gmail.com>.
Julian, I know it might be tough, yet:
1) I would like you to believe me I just forgot howto and the other places
hard-code Java versions.
Of course, "we support Java 17" is a notable change, and it does deserve to
be in the release notes,
however, the typical current process is to "file JIRA for notable changes",
so I did just that, and created
CALCITE-4829 Bump Gradle to 7.2 and test with Java 17 at GitHub Actions.

I agree it is unclear how the release manager could deduce they should add
"Calcite X.Y supports Java 17 now" to the release notes.
However, I am sure that could have happened with ANY change.
The release manager often is not in a position to judge which changes are
notable for the release.

2) I previously suggested we should automate the replacement of "the
maximum supported Java".
I believe the current failure highlights that once again.
We can never expect contributors to remember all the places Java versions
can be mentioned.

-----

Julian>then the following tasks need to be done:
Julian>Update the Gradle version in howto.md...

I am afraid it does not solve the root cause, so we should do something
different.
New Java and Gradle versions would appear, and we would keep forgetting to
update all the places.

I suggest we add a variable like max_tested_java_version somewhere
(gradle.properties? somewhere else?)
Then we use the variable for building the website and we would check CI
does test with the given version.

^^^ this suggestion will stop those discussions once and forever.
That is basically the same thing I suggested in CALCITE-4575.

>Does Calcite now support Java 16 and 17?

17 is available, so there's no point in mentioning "Java 16 is supported".

Current text:

>Building from a source distribution
>Prerequisite is Java (JDK 8, 9, 10, 11, 12, 13, 14 or 15) and Gradle
(version 7.2) on your path

I would suggest:

>Building from a source distribution
>Prerequisite is Java 8 to ${max_tested_java_version} and Gradle (version
${gradle_version_from_wrapper}) on your path

Julian>Change the subject of
Julian>https://issues.apache.org/jira/browse/CALCITE-4547 to "Support Java
16
Julian>and 17",

-0.97 for mentioning "support Java 16"
We do not support that version, we do not test with Java 16, and we do not
want to add
Java 16 tests as it would significantly increase test times.
We just hope it would work.

Of course, most likely Calcite would work with Java 16 since Calcite works
with 11 and 17.
However, please, Julian, please, let us stop mentioning that we support
irrelevant versions?
None of Java vendors provide LTS for 16.

Vladimir